Settlement is not the whole workflow.

Design note · 7 September 2026

Consider an agent that hires a service to make a financial payout. There are at least two payments in this story: the fee for hiring the service, and the payout the service was instructed to execute. A receipt for the first is not automatically evidence that the second succeeded.

That distinction is the starting point for Proof21's financial-checking profile. It is not a claim that blockchains need another layer to tell them whether a native transfer exists. The proposed value is connecting evidence across a complete, agreed workflow.

Three different questions

What was requested? The instruction identifies the operation, network, exact asset, intended recipient, amount, and relevant constraints. Its authenticity and applicable authority must be established by the surrounding system; a P21 report must not invent either.

What was paid for? Commercial evidence identifies the service interaction and the payment used to hire the provider. x402's signed-offer and receipt extension is one source of such evidence. Its own verification rules still apply. [1]

What actually executed? The underlying transaction must be evaluated in the correct chain context. A failed transaction, an identical symbol on a different token contract, a wrong recipient, or insufficient finality cannot quietly become success.

The same wallet might appear in several records. That does not make the records equivalent or prove that they refer to the same operation.

A useful report is specific

The proposed P21 result does not say “this agent is safe.” It says whether the supplied evidence supports a particular claim under a named checking profile. The report should expose the original evidence, expected bindings, evaluation version, and source assumptions.

A signature can authenticate a report containing a failure. A provider's RPC observation is not the same thing as independently validating a chain. A missing input should remain indeterminate rather than being filled in by an LLM.

These distinctions are useful even when a workflow never touches Bitcoin. Bitcoin/DMT support is a first-class capability of Proof21, not a compulsory detour for every caller.

Start beside existing controls

The first pilot should run in shadow mode. Existing wallet limits, signing rules, and settlement controls remain in place. P21 produces a finding alongside them, and an independent consumer reproduces the supported checks.

A pilot succeeds if this catches a meaningful mismatch, reduces reconciliation work, or produces evidence a counterparty can use. It does not succeed merely because a new JSON object was signed.

The planned first fixture set includes wrong networks, incorrect assets and recipients, altered instructions, replayed evidence, failed transactions, stale observations, and unavailable data. These are implementation requirements; the website does not claim that a released verifier already passes them.

A worked binding example

Imagine a synthetic instruction to transfer 100 demonstration units to Supplier A. With six decimal places, the expected amount is the integer string 100000000. The provider also charges a separate service fee. These are illustrative accounting values, not a real token, network transaction, or price quotation.

Now suppose the provider returns an authentic receipt for its fee and a transaction record for 100 units sent to Supplier B. The service interaction may be genuine while the payout predicate fails. If the record instead names Supplier A but describes a different asset with the same display symbol, the predicate still fails. Human-readable similarity is not a substitute for exact binding. Chain identifiers and asset identifiers address different parts of this naming problem; CAIP-2 and CAIP-19 are useful primary references, not verification engines. [2][3]

A proposed checking profile should bind an operation identifier, instruction digest, expected network, exact asset, recipient, integer amount, execution outcome, observation point, and policy version. It should separately retain the commercial receipt and the underlying execution evidence. An agent explanation can help a person understand the mismatch, but it must not manufacture a missing transaction or silently repair an unauthorized recipient.

Failure and missing evidence need different paths

A supported, sufficiently established record showing the wrong recipient supports FAIL. An unavailable record normally supports INDETERMINATE, not a conclusion that a payment never occurred. The distinction matters operationally: automatically retrying a payment after a timeout can create a duplicate payout. A checking service should return its evidence boundary, while a separate authorized controller decides whether to wait, investigate, or retry under the application's idempotency policy.

Freshness is part of the question rather than a cosmetic timestamp. A record observed before the relevant event cannot establish its later completion. Likewise, a transaction that met a confirmation policy at one observation point may need re-evaluation after a detected reorganization. Preserve both observations and their reasons; do not overwrite the earlier finding with an unexplained green badge.

What an independent consumer should reproduce

A useful pilot gives the consumer the original instruction, the selected profile version, the exact evidence bytes or authorized retrieval references, and the producer's findings. The consumer first establishes which bytes and issuer it is evaluating, then reproduces supported comparisons, then applies its own acceptance rules. It should be possible to disagree about acceptance without pretending the producer's signature is broken.

The pilot's test pack should vary one binding at a time and record the expected reason. Start with a known matching synthetic case; change the recipient, then the asset, then the network, then the amount. Separately test stale data, a failed execution, a replayed operation, and a missing evidence source. Include an authentic signed failure, because rejecting every negative report would defeat the purpose of the system. Record which checks were actually executed and which remain design requirements.

Measure the work saved, not merely the number of receipts generated. A useful measurement is whether another operator can locate the relevant evidence and explain a mismatch without asking the original agent to retell its story. Do not count a synthetic fixture as customer revenue or a successful real payment. Proof21's downloadable offline demo illustrates a narrow subset of these distinctions; it is not the proposed production financial adapter.

Frequently asked questions

Does a valid service receipt prove the requested payout succeeded?

No. It can support the service interaction under its own signing and verification rules. The requested payout is a separate claim that needs execution evidence bound to the instruction. Preserve both artifacts rather than expanding one receipt's meaning.

Should an indeterminate result automatically trigger another payment?

No. Missing evidence and failed execution are different situations. Any retry belongs to an explicitly authorized controller with duplicate-payment protections, not to an LLM inferring that a timeout means nothing happened.

Does every check require Bitcoin or a new token?

No. The financial-checking design can evaluate a supported workflow without a fresh Bitcoin write. Optional commitment and Bitcoin/DMT capabilities have separate roles. P21 is a project shorthand here, not an available payment token.

Additional primary references

• 2: CAIP-2 — Blockchain ID Specification
• 3: CAIP-19 — Asset Type and Asset ID Specification

<!-- p21-ecosystem-payments-v09 -->

Stablecoins matched to each integration

The initial core requires native NAT and USDC on Base. Each additional commerce integration launches with an explicit asset/network/method allowlist, rather than assuming every ecosystem uses the same stablecoin. Provider documentation reviewed on 9 September 2026 establishes the following implementation targets; it does not establish that P21 already operates them.

Binance's published BSC mainnet entries use 18 decimals, including its USDC and USDT contracts. Base USDC uses a different contract and 6 decimals. Never copy decimal assumptions between networks or confuse testnet assets with mainnet assets. Do not add FDUSD or another coin merely because it is associated with an exchange; verify the specific payment product.

Before advertising an available method, intersect the owner's allowlist with the configured provider's current supported capabilities. Pin the network, token, decimals, payment method and recipient; validate permitted spender/signer addresses and preserve required authorization metadata. Refresh capability data without letting it silently expand the allowlist. B402 production access requires provider onboarding. All P21 routes remain disabled until implementation, settlement tests and approval are complete.

Binance assets and methods · Binance integration · Coinbase facilitator · PayAI assets · Virtuals ACP · NAT Ethereum listing · NAT Solana record · NAT BNB Chain contract

<!-- p21-enforcement-v10 -->

Update · Signed rejection does not rewrite settlement

A receiving agent's REJECT is not a ledger verdict. Proof21 now models integrity, deterministic evaluation, settlement and consumer decision as separate dimensions. A valid transaction can remain CONFIRMED while a consumer signs REJECT under its own policy.

For workflows that need objective accountability, the receiver commits to its acceptance-policy digest/version before the protected action and later signs a consumer decision receipt. If that deterministic committed policy evaluates PASS from complete evidence but the receiver signs a contradictory decision, an independent P21 evaluator can preserve that contradiction. If the policy depends on unavailable private inputs, the correct consistency result is UNRESOLVED.

Higher-assurance workflows can also put a P21 execution gate in front of the protected signer so a model cannot simply ignore a failed authorization and send a substituted transaction.

Read further

• P21 financial-checking design
• Verify, evaluate, accept
• Partner pilot playbook
• 1: x402 signed offers and receipts