# Welcome to Proof21 **Verifiable choices. Checkable actions. Bitcoin-native foundations.** Proof21 connects Bitcoin’s public block history with verifiable choices, portable evidence, and policy-based checks between AI agents and platforms. Agents exchange evidence across chains without moving their applications, assets, or custody to Bitcoin. > **Protocol specification.** These pages define the architecture and interface contracts. [Implementation status](https://proof21.xyz/docs/start/status/) distinguishes released software from the protocol specification. ## The product in one minute | Capability | Intended value | Status | | --- | --- | --- | | Choice / Sample | Reproduce selection and audit sampling from committed inputs | Experimental design | | Check | Compare a defined financial action with an agreed instruction | Alpha scope | | Elements | Resolve supported DMT rules and reproduce derivations | Alpha scope | | Verify / Accept | Verify evidence and apply the recipient's policy | Required foundation | | Commit | Optionally timestamp evidence batches | Asynchronous extension | P21 is not a new blockchain, wallet, bridge, general-purpose AI judge, or replacement for spending limits. A signature proves who signed a statement under the applicable key assumptions; it does not make the statement true. ## Try a working example The [offline demo](https://proof21.xyz/docs/start/offline-demo/) needs no wallet, package installation, or network connection. It checks signatures and compares fictional payment evidence with a local instruction. A matching sample does not approve a real payment. ## Choose a path **Builders:** start with the quickstart, evidence model, and test matrix. **Agent operators:** read the consumer verification path and integration boundaries. **Blockchain partners:** bring one real workflow to the pilot playbook. **Researchers:** start with Choice / Sample and the security model. **Proof21 / P21** · `proof21.xyz` ## 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 ## 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](https://developers.binance.com/en/docs/products/onchainpay-x402/basics/9.supported-payment-methods) · [Binance integration](https://developers.binance.com/en/docs/products/onchainpay-x402/introduction) · [Coinbase facilitator](https://docs.cdp.coinbase.com/x402/seller/facilitator) · [PayAI assets](https://docs.payai.network/x402/reference) · [Virtuals ACP](https://os.virtuals.io/acp/concepts) · [NAT Ethereum listing](https://www.bitmart.com/en-US/support/articles/7923014477723/360001026214/49446319153179) · [NAT Solana record](https://solscan.io/token/FbKRaqBzupLry3V7QujpNghwrHgxutB4MY11M8aeyVa1) · [NAT BNB Chain contract](https://bscscan.com/token/0x600e3b55d5368c32a94f9372563318adb6a3f882) ## Action-bound authorization and counterparty accountability P21 now specifies an optional execution-gated mode in addition to evidence-only verification. Protected actions can require a fresh authorization bound to the exact action digest, request, policy, network, nonce and expiry. A receiving agent's signed `ACCEPT`, `REJECT` or `REVIEW` decision cannot rewrite independent proof, evaluation or settlement state; deterministic contradictions and incompatible signed decisions can be preserved as separate evidence. These are protocol specifications and draft schemas, not a released wallet controller or policy signer. The unannounced DMT element remains private until registration is confirmed.