A signature can prove where a payment came from. It takes a method to say what it means.
Most crypto tooling treats “on-chain” as a synonym for “true.” Accounting cannot afford that shortcut. This page is the method behind every x402ledger close — published in full, because evidence you can’t interrogate isn’t evidence.
Three rules that keep the labels honest.
Cryptography establishes source and integrity
It does not automatically establish identity, authority, delivery, or truth. A valid signature tells you which key signed — not who commanded it, whether the organization authorized it, or whether anything was delivered.
Absence of an alert is not evidence of absence
Detective controls surface indicators; they never establish that nothing occurred. A quiet monitoring feed is a quiet feed — not a clean bill of health.
Deterministic mechanisms detect; they do not dispose
Idempotent ingestion prevents processing the same delivery twice; period logic surfaces cutoff candidates consistently. But replay and economic-duplicate questions need scheme-specific and business-level correlation, and recognition remains governed by evidence and your accounting policy — not by a mechanism’s silence.
Every figure declares how much you can lean on it.
| Label | Mechanical definition |
|---|---|
| protocol-confirmed | Linked through cryptographically validated x402 artifacts or authenticated seller/facilitator records — including the signed payment payload and settlement evidence. Delivery confirmation requires a signed receipt or authenticated seller evidence. |
| settlement-pattern matched | On-chain behavior matches a supported mechanism or known facilitator pattern. |
| inferred x402 | Circumstantial wallet or counterparty evidence. |
| other | Classified non-x402 activity. |
| unresolved | Insufficient evidence. The mandatory default when classification fails — never a confident guess. |
One payment. Three different answers.
Labels apply per evidence leg. A single payment’s settlement can be chain-verified while its authorization is key-signed and its offer and delivery remain seller-attested. Collapsing those into one green checkmark is how tooling lies politely.
Within the authorization leg, we distinguish cryptographic authorization — the relevant key produced a valid protocol authorization — from mandated authorization: evidence linking that key’s act to delegated organizational authority. Key-level authorization never implies organizational authorization.
| Leg | Evidence | Assessment |
|---|---|---|
| Settlement | on-chain transfer, finalized block | chain-verified |
| Authorization | signed payment payload | key-signed |
| Delivery | seller record, no signed receipt | seller-attested |
What each artifact establishes — and what it doesn’t.
| Evidence | Establishes | Does not establish |
|---|---|---|
| Management representation | The entity asserts the wallet relationship — required in every case | Key control; domain control |
| Signed wallet challenge | Current wallet-key control | Legal ownership or entitlement |
| Domain verification | Control of the relevant domain | Wallet control |
| Timestamped payTo observation | The endpoint advertised this wallet at that moment | Entity controls wallet or domain |
None alone establishes legal ownership of, or entitlement to, the funds. Every packet distinguishes “activity observed at this address” from “activity belonging to this legal entity” — and states the evidence basis connecting them.
“Unresolved” is not a failure state. It is the product refusing to guess with your books.
When a customer’s materiality policy makes pattern-matched evidence sufficient, the packet says so plainly. When evidence is insufficient, the item stays in the exceptions queue until a human disposes of it. The packet reports its own evidence-label distribution honestly — that transparency is the deal.