The dispute is next quarter. The proof is now.

the three questions, months later

Every post-hoc conversation about an automated transaction is the same three questions, and a database row answers none of them to a stranger: which code decided, under which policy, and can I check that without taking your word for it. The third one is what makes the first two worth anything. A counterparty, an auditor, or your own risk desk in a bad week are all the same reader: they want arithmetic, not access.

what the receipt records

1. doc_sha256

   The digest of the document you chose to bind — the quote, the signed intent, the settlement record, whatever your dispute will be about. You keep the document; we never hold it. A changed document stops matching.

2. recorded_verdict

   pass or fail, with the reasons that produced it. A refusal is a receipt too, and it bills the same as an approval — a system that only keeps proof of its successes has not kept proof of anything.

3. measurements

   The attested fingerprints of the code that ran — the enclave registers, in the receipt, at decision time. This is the half nobody else brings: not that a policy existed, but that this build was the one in the loop. New to the idea? The academy teaches it from first principles.

4. env · iat

   Environment (live or test) and issue time, inside the signed body. A test receipt can never be produced later as production evidence, because the word is under the signature.

5. signature

   Ed25519 and ML-DSA-44 over the canonical body, against a key id in the published keyset. Two signatures because settlement records outlive cryptographic assumptions: the post-quantum half is there for the audit that happens in a decade.

Nothing in that list is your prompt, your counterparty, your amounts or your book. The receipt binds hashes and a verdict, which is why it can be handed to someone you do not trust.

the counterparty checks it without you

Verification is arithmetic against a public key, so it needs neither our permission nor our uptime. The keyset is public and unauthenticated; pin it once and every check afterwards runs offline. Someone who is not your customer, not our customer, and holds nothing but the receipt and the keyset can still tell whether it is real. That property is the product. The check below runs in this tab against a published specimen — same bytes /start and /verify check, signed by a test key, sealed for real.

Separately, and about ourselves rather than about you: PCRZERO seals its own usage ledger into a checkpoint every UTC day, signs it with ML-DSA-44 under anchor kid 403bcd73e051e602…, and anchors that seal on Solana mainnet. Each seal is published whole with a linkable transaction on the ledger — our own record-keeping, on the same terms we ask you to take. The anchor witnesses the commitment; what it contains is checked by you, from the published artifacts.

where it sits in an agent stack

1. from the agent

   The MCP server gives any MCP-speaking agent three native tools: issue a receipt, verify one, fetch the keyset. No SDK and no integration project — the agent that made the decision is the thing that records it.

2. from your service

   One authenticated call on the API for issue, one public call for the keyset. The receipt comes back with the response; store it beside the transaction, or hand it straight to the counterparty.

3. from anywhere, later

   Offline verification against the pinned keyset, in a browser or a terminal or an air-gapped review room. Watch real receipts arrive and verify in your own browser on the receipt feed.

what this is not

• Not custody, and not a payment rail. No money moves through us and we hold no keys of yours. We are beside the transaction, not inside it.
• Not a reader of your trade. The receipt binds the hash of a document you chose. It does not parse a quote, price a swap or understand a settlement, and it never claims to have checked that the number was fair — only that this decision, by this code, was made over that exact document.
• Not a compliance product. It produces evidence a reviewer can check. What your obligations are, and whether this satisfies them, is between you and your regulator.

free to verify, metered to issue

Verifying is free, needs no account, and stays free — including for people who will never be customers, which is the only way “your counterparty can check it” is a true sentence. Issuing is metered per receipt, and a fail bills exactly like a pass.

Every rate is on the pricing page, including the free tier and the two ways to pay. The key path works today: the MCP page carries the call that mints one, and the two free tools work before you have any key at all.