Key takeaways
- A cryptographic proof of payment is bound to the transaction at execution, so there is no separate record to reconcile or reconstruct later.
- In Qatom, each holding is a TODA file whose Proof of Provenance travels with it and can be verified locally and offline.
- The proof establishes integrity: what was paid and settled, by whom, under which authorization, and that the history was not altered.
- It does not prove an agent's decision was correct, that the agent stayed within its intended policy, or that the underlying data was accurate.
- Proof complements operational controls such as budgets, approvals, key management and role-based access; it does not replace them.
What is cryptographic proof of payment?
Cryptographic proof of payment is evidence that a payment happened, created by the payment itself and protected so that any change can be detected. The test that matters to a risk or audit team is simple: can someone outside the paying organization check it, without trusting that organization?
Much conventional payment evidence does not meet that test. A bank statement, a processor dashboard or an application log is a statement made by one institution about its own activity. It can be accurate. But a counterparty, insurer or court has to take the institution's word for it, or demand access to its systems.
The stronger form binds the proof to the transaction and its settlement at the moment of execution. Qatom uses this model. In the words of the TODAQ Press essay Settlement Without Proof, "Settlement and verifiable record become the same operation rather than two operations that must be reconciled."
Three terms recur in this guide:
- Integrity: the record shows what happened and has not been altered.
- Non-equivocation: no conflicting version of the history was produced.
- Independently verifiable: a third party can check the proof with no intermediary.
Why isn't a receipt or log the same as proof of transaction?
A receipt and a proof of transaction answer different questions. A receipt says what the seller or platform recorded. A proof says what can be shown to anyone, whatever any party now claims.
TODAQ Press argues that the gap widens when AI agents act. Its essay When The Transaction Becomes The Record puts it this way: "a record generated separately from an action, and stored separately from an action, can always be questioned." The same essay frames the difference as "the difference between evidence and testimony."
The argument is about evidentiary weight, and logs still have a job. Operational logs remain the main source for debugging and for explaining why a system acted. The point is narrower: when the record's own author is a party to a dispute, a self-kept record carries less weight than one the other side can verify.
Agent commerce makes this concrete. Agents buy many small items from many sellers, often with no human watching each purchase. The Invisible Shelf essay calls such transactions "inherently unwitnessed." If each purchase carries its own proof, the missing witness matters less.
How is the proof bound to settlement?
Qatom is built on the TODA file protocol. Money inside Qatom is USD-TDN, a US-dollar token (1 USD-TDN = 1 USD). Each holding sits in a "twin," a small secure wallet app, and each holding is a self-verifying TODA file. RBC holds the reserve funds backing USD inside Qatom.
The mechanism has four parts. Its primary specifications are the Rigging Specifications and the Abject Specification:
- Proof of Provenance. Each TODA file carries a Proof of Provenance built from "rigs," which the essays describe as "an unbroken, verifiable chain of custody from creation onward."
- Non-equivocation. A rig proves that no conflicting version of the asset's history was produced.
- Double-spend prevention. This is a proved theorem, shown by structural induction in Simple Rigs Hold Fast (Coward and Toliver).
- Authorization in the file. Each update must carry a satisfaction of the previous step's requirements, such as specific signatures or weighted multi-signature lists.
Because the payment and its proof are one object, the record exists the instant settlement does. Settlement between twins takes under one second. TODAQ Press describes the result as a record that "cannot be reconstructed after the fact, because it was never separate to begin with."
TODA is not a blockchain. There is no global consensus, no shared ledger and no gas. Dann Toliver, Qatom's CSO, co-authored the Rigging Specifications and Simple Rigs Hold Fast; see About us for the team and research heritage.
What makes tamper-evident transaction records different?
A tamper-evident record is one where any alteration can be detected by whoever checks it. That is the accurate claim, and it is the one to hold any vendor to, including this one.
With TODA files, the proof travels inside the file, so verification is local and can run offline. The Invisible Shelf essay describes it as verification "with no network call, no consensus round, and no external validator." The verifier does not need the originating system to be online or cooperative.
TODAQ Press summarizes what this guarantees in When The Transaction Becomes The Record: "the execution history cannot be retroactively altered, selectively reconstructed, or institutionally withheld." For an auditor, the practical meaning is chain of custody that survives the loss of cooperation from the party that produced it.
What does non-repudiation for payments mean here?
Non-repudiation for payments means a party cannot credibly deny a transfer it authorized. In card systems this rests on network rules and the issuer's records. In TODA, it rests on the file: each step must satisfy the authorization requirements set by the step before it.
In Qatom, those requirements sit beside product controls. An agent spends from its own agent wallet with its own budget (A3, A8). Purchases above an auto-approve limit need the owner's approval by passkey or phone app (A9, A14), and the owner checks the item, seller and price before approving (A31).
What does the proof show, and what does it not?
This table is the one to show your audit committee. The limits come from the TODAQ Press essays themselves.
| Proves | Does not prove |
|---|---|
| That a specific transfer was executed and settled | That the agent's decision to buy was correct |
| Which twin paid, which received, and the amount | That the agent acted within its intended policy scope |
| Under which authorization the transfer was released | That the original data or judgment behind it was accurate ("Verification does not equal truth") |
| That the history was not altered or substituted, and no conflicting version exists | A system-wide view for macro-prudential monitoring; there is no built-in global view |
| That any party can check it offline, without trusting the originator | That regulators accept such records; regulators have not formally opined on them, and supervisors are not yet familiar with rigging trees |
When The Transaction Becomes The Record states the first limit directly: "It cannot guarantee that an autonomous decision was correct, or that the agent acted within its intended policy scope." What the proof guarantees is integrity. Judgment and policy remain your controls.
How do verifiable receipts for AI agents work in Qatom?
Every Qatom purchase returns a transaction id and an emailed receipt with proof of purchase (A15, A17). Behind the receipt sits the TODA file, which carries the proof. The Qatom Console (console.todaq.net) shows TODA files, provenance and verification for each twin.
A counterparty or auditor can check a payment like this:
- Get the transaction id from the agent's receipt or the emailed proof of purchase.
- Open the twin in the Console and inspect the note's minting info and provenance history (C7).
- Verify the file's integrity and download the .toda file (C8).
- Share the file with the reviewer, who verifies it locally. The protocol has an open-source JavaScript implementation.
- Reconcile with the books by exporting the twin's ledger as CSV (C9).
Sellers use the same id in the request path. They verify each fulfillment call with the X-Qatom-Transaction-Id header, so each sale is served once (B20).
Which risks does cryptographic proof of payment address?
Cryptographic proof of payment covers integrity risks. Operational risks need operational controls, several of which Qatom provides in the product.
| Risk | Evidence or control |
|---|---|
| A party disputes that a payment happened | Transaction id, emailed proof of purchase, downloadable .toda file (A15, A17, C8) |
| A record is altered or rewritten after the fact | Proof of Provenance and non-equivocation in the TODA file |
| The same funds are spent twice | Double-spend prevention proved in Simple Rigs Hold Fast |
| A retried call charges twice | Retries are new charges; check the receipt before retrying (A28) |
| A forged or replayed fulfillment call | X-Qatom-Transaction-Id check and a secret header on paid endpoints (B20, B12) |
| An agent overspends | Separate agent wallet with its own budget; approval above the auto-approve limit (A3, A8, A9, A14) |
| Credentials leak or staff overreach | Key rotation, revocable API keys, role-based access to who can see or move funds (B24, B29, C29) |
| Evidence is locked in one party's systems | Exportable ledger and .toda files (C8, C9) |
For a fuller control set, see agentic payments risk controls.
How can anyone verify it without exposing private data?
Using cryptographic proof of payment does not mean making payment data public. The trusted system can anchor a proof without seeing the data, a technique the essays call "shielding." The Missing Middle essay states the principle: "Privacy is the default; visibility is conferred by consent."
A counterparty or regulator can be given the full record while others see nothing. The essays call an exportable record a "Transaction Binder," which can be shared with a regulator or audit firm and verified offline. Who receives it is your decision, and what disclosure your obligations require is a question to confirm with your counsel.
How does this compare with other agent payment approaches?
Other approaches solve different parts of the problem. x402, created by Coinbase and now governed by the x402 Foundation, revives HTTP 402: a facilitator verifies the payment and settles onchain in stablecoins. Google's AP2 records consent in signed intent and cart mandates. The Agentic Commerce Protocol, from Stripe and OpenAI, passes the merchant a scoped, logged payment token. Visa Intelligent Commerce and Mastercard Agent Pay focus on agent identity and agent-bound tokens on card rails.
TODAQ Press argues that protocols such as x402, AP2 and ACP were not designed to carry proof across institutional boundaries: "Evidentiary portability is outside their stated scope." That describes their scope and is no criticism of how well they do their own jobs. These approaches can complement each other. See agent payment protocols compared for the detail.
Further reading
- TODAQ Press, Settlement Without Proof (19 May 2026)
- TODAQ Press, When The Transaction Becomes The Record (20 May 2026)
- TODAQ Press, The Agentic Economy's Missing Middle (7 Aug 2026)
- Coward and Toliver, Simple Rigs Hold Fast, and the Rigging Specifications
Next steps
- Read the overview for risk, security and compliance teams: Qatom assurance.
- See verification, approvals and record export on your own transactions: book an enterprise demo.
- Learn how proof fits into agent oversight: AI agent audit trail.