Protocol design note · 7 September 2026 · Compatibility targets are not implemented integrations.
A workflow may produce an invoice, a signed service offer, a receipt, a transaction observation, and a policy evaluation. Giving all of them the same envelope can make software easier to write. It can also make the evidence harder to understand if the envelope silently treats every item as an equivalent proof of success.
Proof21's interoperability goal should be the opposite: a consistent interface that preserves the meaning, provenance, and limitations of the original artifacts. Reuse existing formats where they fit. Add only the bindings and evaluation results that the workflow genuinely needs. A new name for a receipt is not a reason to replace a working ecosystem.
Name the claim before choosing the wrapper
x402's signed offer and receipt extension concerns commercial interaction artifacts. PEAC describes verifiable interaction records with issuer-reported evidence boundaries. These can be useful inputs or compatibility targets, but neither label should be stretched into independent proof that every requested downstream operation was performed correctly. [1][2]
A proposed adapter should state the exact claim it consumes. For example: this issuer signed these commercial terms; this service reported this interaction; this source returned this transaction observation; this evaluator compared these fields under this profile. The consumer can then combine those statements without pretending they have identical trust assumptions.
Start with one named version and one supported artifact shape. A claim of “compatible with everything” is less useful than a narrow profile with positive, negative, and unsupported-case test vectors. Describe whether the adapter parses an artifact, verifies its mechanism, evaluates a claim, or merely retains it for later inspection.
Preserve the original before normalizing
Suppose an adapter reads a signed JSON artifact and produces a convenient normalized view. That view can help a developer, but the adapter must not discard the original authenticated representation. If it rewrites types, removes fields, changes Unicode handling, or changes serialization, the resulting bytes may no longer be the message the issuer signed.
Retain the original artifact or an authorized, integrity-bound retrieval reference. Record the transformation version and which normalized fields were derived from which inputs. Distinguish an absent field from an explicitly empty value when the source format does. Unsupported fields should not quietly disappear if they affect the source's verification or claim semantics.
Canonicalization can solve a defined serialization problem, not every translation problem. RFC 8785 is a useful reference for a particular JSON canonicalization scheme. A profile must specify when that scheme applies and when the original format uses different rules. Never canonicalize an arbitrary signed object and assume the signature must verify over the new bytes. [3]
Keep identifiers exact across systems
Network and asset names are a common source of accidental equivalence. Two networks can display the same asset symbol. A test network and a production network can have similar-looking addresses. A local account identifier may have no meaning outside the system that assigned it. A normalized report must preserve namespaces and binding rules.
CAIP-2 and CAIP-19 provide primary specifications for chain and asset identification. They help name the thing being discussed; they do not prove that an external chain reached consensus or that a particular transfer occurred. A consumer still needs the relevant execution evidence and an acceptance policy. [4][5]
For a synthetic interoperability test, keep the displayed symbol fixed while changing the exact asset identifier. Then change the network while leaving the recipient's visible text similar. The adapter should expose those changes rather than merge the records. A helpful user interface can explain the mismatch without rewriting the underlying identifiers to make the workflow pass.
Separate transport success from semantic success
An HTTP success response means a request was handled according to the server's interface; it is not automatically a positive evaluation of the business claim. An authentic artifact can carry a negative finding. An unsupported profile should remain unsupported even when its JSON parses successfully. These distinctions belong in both the schema and the consumer's presentation.
The proposed P21 consumer should report artifact integrity, the result of each supported evaluation, and local acceptance separately. If a partner format contains only an issuer assertion, preserve that evidence class. Do not relabel it as independently validated state merely because it is now inside a P21 report.
Likewise, preserving a foreign signature does not establish whether the consumer accepts the issuer today. Key discovery, rotation, revocation, and organizational authorization have their own policies. An offline test against a supplied key demonstrates only its stated scope. A cross-format adapter should not imply that an identity or trust registry was consulted when it was not.
Build a compatibility contract that can fail honestly
For a first integration, document the input version, supported claims, required fields, authentication mechanism, output profile, preserved originals, and unresolved conditions. Publish fixtures that cover an intact artifact, tampering, a wrong operation identifier, an unknown version, an authentic negative result, and missing evidence. Have the producer and consumer run independently.
Round-trip tests can verify that the adapter retains what it promised to retain. Differential tests can reveal disagreements with an upstream implementation. Neither test style establishes a partnership or production readiness by itself. Record the upstream revision and test date so a later change does not silently invalidate an old compatibility statement.
A useful pilot outcome is an independent consumer explaining a result and locating the original evidence without asking the producer to reconstruct the story. The current Proof21 documentation names interoperability targets and boundaries. It does not claim released PEAC, x402, MCP, or A2A adapters, and the offline demo is not a conformance suite for those protocols.
Frequently asked questions
Should Proof21 replace every existing receipt format?
No. Reuse is the default where a format fits the required claim. A proposed adapter should preserve original evidence and add explicit workflow bindings or evaluations, not create a duplicate envelope merely for branding.
Does putting an RPC response in a signed report make it independently validated state?
No. The signature can authenticate what the report issuer signed. The RPC response remains an observation with its own provenance and limits unless additional validation is actually performed and documented.
Is parsing a partner format enough to claim full compatibility?
No. Compatibility must name a version and scope, cover required semantics, and be supported by tests. Parsing, signature verification, claim evaluation, and local acceptance are distinct capabilities.
<!-- p21-ecosystem-payments-v09 -->
Cross-chain access and ecosystem payments
Native NAT and Base USDC remain required initial commercial methods. NAT also has identifiable representations on Ethereum, Solana and BNB Smart Chain. Approve each representation's exact contract or mint and bridge mapping before accepting it; cross-chain availability does not erase source-specific trust assumptions.
The Binance B402 integration scope includes USDT, USDC, USD1 and U on BNB Smart Chain, using the methods supported for each asset. PayAI and Coinbase routes use their tested network/asset combinations; Virtuals ACP retains its USDC job-payment lifecycle. MCP and A2A do not mandate a payment currency. Payment choice and optional treasury conversion remain separate from Bitcoin/DMT evidence verification. These are specified integration targets, not enabled payment services.
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 · Interoperability needs authorization boundaries too
Portable evidence becomes more useful when execution authority is equally explicit. P21 now distinguishes evidence-only verification from optional execution-gated authorization. The same action-bound authorization can be adapted to a TAP threshold signer, smart account, MPC/HSM policy or API capability proxy without pretending those systems share one consensus model.
Consumer decisions are portable signed artifacts as well. A receiver can reject, but that rejection does not overwrite independent settlement or evaluation. Incompatible signed decisions can become equivocation evidence instead of being collapsed into a mutable reputation badge.