- Q+5Positive
Quack AI (@QuackAI_AI)
Trust Receipts: what is inside a verifiable receipt for an agent payment The Q402 docs use a one-line prompt to demo Trust Receipts: “Send 0.10 USDT to alice on BNB via Q402, then verify the receipt.” Read it as a human and the second half looks redundant. The agent sent the money, so what is left to verify? Read it as the developer who has to reconcile that payment next week, and the second half is the part that matters. An agent did something with real funds. Somebody, or more likely some other program, will need to confirm that it happened, that it went to the right address for the right amount, and that the system which was supposed to hear about it did. People have used receipts for this for a long time. The difference with agents is the reader. A person glances at a receipt and trusts the letterhead. An agent’s receipt gets read by another program, so it has to carry something a program can check without trusting the page it came from. What is on a Trust Receipt The docs describe a Trust Receipt as “a verifiable proof page for every Q402 settlement,” signed by the relayer EOA and “recoverable in any browser.” Each receipt carries four groups of data: Settlement facts: payer, recipient, amount, chain, EIP method. On-chain proof: tx hash, block, sponsored gas, explorer link. Signature: an EIP-191 ECDSA signature over the canonical hash, which you can recover locally in your browser. Delivery trace: webhook state, retry count, last response code. Who signs: the Q402 relayer EOA. Where to look it up: three places. A receipt has a public page at q402.quackai.ai/receipt/rct_…, a JSON endpoint at /api/receipt/rct_…, and, if you use the dashboard, a Trust Receipts tab under Activity (labeled “Verifiable receipts”) that lists settlements with a receipt attached. The receipt id is unguessable, 12 random bytes, so the docs point out that the URL “doubles as a shareable audit link.” You can send it to a counterparty or an auditor without giving them access to your dashboard. Why a tx hash is not enough A tx hash proves that a transaction exists on a chain. That is useful, and a Trust Receipt includes it along with the block and an explorer link. On its own, though, a hash is a pointer. To get anything out of it, a program has to fetch the transaction, decode it, and work out which payment in your system it corresponds to. A Trust Receipt starts at the other end. It records the payment as your system understood it (who paid whom, how much, on which chain, by which method), links that record to the on-chain proof, and signs it with a key you can check. The delivery trace adds what a block explorer can never tell you: whether your own app was notified, how many retries it took, and what your endpoint returned. So the tx hash answers “did a transfer land?” The receipt answers “did the payment my agent made land, and did the rest of my stack find out?” An agent auditing another agent needs the second question answered. How developers get one From the relay response. /api/relay responses include receiptId and receiptUrl next to the txHash. The docs’ architecture flow has you “call pay() from the SDK or MCP,” and that call goes through /api/relay. The browser SDK returns that relay JSON as is (the bundle at q402.quackai.ai/q402-sdk.js does return data after the relay call), so the same two fields come back from pay() even though its documented result shape lists just the tx hash and amount. From the webhook. Every relay can fire an HMAC-signed relay.success webhook, and the receipt fields are “mirrored in the webhook payload,” so your backend does not need a second lookup. From the JSON endpoint. Any service holding a receipt id can fetch the record directly: curl https://q402.quackai.ai/api/receipt/rct_afa5f50bc49a65ebba3b28ab The endpoint is rate limited to 120 requests per minute per IP. From an MCP client. The @quackai/q402-mcp server has a q402_receipt tool that fetches a Trust Receipt by its rct_… id and verifies it locally with ECDSA recovery against the relayer EOA. If you have not installed it yet: claude mcp add q402 -- npx -y @quackai/q402-mcp Then the prompt from the top of this post does both halves in one turn. The docs show the trace: q402_pay settles and returns an rct_ id, then q402_receipt returns verified: true along with the signing address. The verification step in that flow is local signature recovery, not an “is this real?” request to a Q402 endpoint. That is the property that makes the receipt useful to a second program: it checks the math against a known signer, not the issuer’s word. Closing Payments between agents will keep raising a question that payments between people mostly settled long ago: how do you prove what happened to someone who was not there? My answer is a receipt that a program can check for itself. You can open the one linked from the docs and verify it yourself.