Integration map
Proof21 composes with existing agent frameworks, payment rails, and blockchain data sources. The mappings below define protocol roles; implementation status identifies released adapters. Project names do not imply endorsement.
| Surface | Role | P21 boundary |
|---|---|---|
| Bitcoin / DMT / TAP | Data, element rules, indexed asset state | Source-specific evidence and derivation |
| EVM and later other chains | Financial execution | Supported action profiles and finality policy |
| x402 | Service payment and discovery | Charge for hosted work; preserve commercial artifacts |
| MCP | Tool invocation | A thin wrapper around supported P21 operations |
| A2A | Agent service communication | Add only with a conforming service implementation |
| ERC-8004 | Agent identity/reputation/validation interfaces | Reference identity, do not replace it |
| AP2 and wallet policies | Authorization evidence and controls | Consume supported evidence, never bypass controls |
| PEAC and other receipt formats | Signed interaction evidence | Preserve originals; add explicit evaluation findings |
| Trac / OpenMayhem | Agent communication and service evidence | Partner-defined adapter rather than duplicate network |
Discovery catalogs and commerce adapters
The distribution model covers Binance B402 Bazaar, Coinbase CDP Bazaar, the MCP Registry, PayAI, and Virtuals ACP. Each adapter carries the same capability definition with provider-specific payment, permission, and lifecycle semantics. The distribution matrix records the source contracts and release gates.
Cross-chain without a bridge
An agent can call a P21 service on ordinary HTTPS and receive Bitcoin-related evidence without moving its assets. Service interoperability and evidence interoperability do not imply cross-chain settlement security.
Use CAIP-2 for chain identifiers where applicable. It identifies a network; it does not verify that network's consensus. Version every adapter and document whether it supplies assertions, observations, inclusion proofs, or independently validated state.
<!-- p21-source-payment-v08 -->
DMT resolution without minting
Proof21 uses DMT as a versioned source-interpretation profile, not as Bitcoin consensus or a universal truth engine. A DMT operation references an accepted element definition, identifies a Bitcoin block by hash and height, evaluates the supported field or pattern, and carries those inputs into a reproducible process receipt. No DMT token, mint, or per-receipt Bitcoin write is required. Bitcoin-only operations remain a separate explicit source profile.
The P21 source element is to be announced. No registration payload, chosen field/pattern, reserved name, or element inscription ID is announced here. Reusing an existing valid element is legitimate; a new branded inscription is not a prerequisite for the protocol.
Trac's standalone ord-tap supplies reusable indexing. Its pinned element parser accepts fields 4, 10 and 11, checks protocol activation, normalizes names, validates patterns and rejects duplicate names and duplicate field/pattern signatures. A new name alone does not make an already registered whole-field definition available. The reviewed parser contains no manual team-approval step; valid registration still depends on historical rule evaluation, not merely Bitcoin inclusion. Hosted provider access and service terms are separate. [1][2][6]
Initial payments: native NAT and USDC
Native NAT is a required initial commercial-launch payment method, alongside USDC on the validated x402 rail. It is not relegated to a later optional integration. The evidence protocol remains payment-agnostic: a customer chooses a supported method and independent receipt verification never requires buying NAT or a P21 token.
The native NAT profile identifies Bitcoin mainnet, TAP, the original NAT deployment inscription and its normalized fungible ticker. A token with the same symbol on another chain is a different asset unless a separately reviewed profile identifies it explicitly. Transferring a UNAT mint inscription does not transfer its fungible NAT balance. [3][4]
NAT invoices and prepaid service-credit top-ups are asynchronous: confirm an executed fungible transfer under the pinned TAP rules, then credit usage once. Subsequent small jobs consume internal non-transferable service credits; they do not each create a NAT transfer or inscription. Those credits are a service accounting record, not a P21 token, yield product or claim of trustless custody. Direct larger-job invoices can use the same settlement checks.
NAT support does not require an automatic DEX conversion. Quote fixed NAT amounts for a defined service package, or use a separately approved price policy with quote expiry and rounding. Publish network fees, minimum top-up, late/partial/overpayment, cancellation and refund rules before accepting money. No exchange rate or minimum is invented by this specification.
[1] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/digital-elements/.element-registry
[2] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/src/index/updater/inscription_updater/tap/ops/dmt_element.rs
[3] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/nat-use-cases/usdnat-method-1-live
[4] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/non-arbitrary-tokens-nats/nat-token-transfer
[5] https://docs.x402.org/core-concepts/network-and-token-support
[6] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/README.md
[7] https://arxiv.org/abs/1605.04559