# TAP, Trac, and Ordinals Bitcoin supplies the public block history. DMT profiles interpret registered source material; Trac’s ord-tap provides reusable indexing. TAP asset-state rules govern native NAT payments and other TAP asset claims. P21 preserves these distinct roles without requiring a mint for each proof. ## TAP TAP defines the supported token and DMT interpretation rules. A P21 report claiming compatibility with TAP-DMT assets must follow those rules and activation behavior. A standalone indexer removes a networking dependency, not the asset's interpretation requirements. ## ord-tap ord-tap is a standalone TAP indexer based on `ord`, exposing indexed current and historical state through REST. The adapter records its version, sync coverage, and reorganization behavior. Reference fixtures validate interpretation; an API response remains an observation unless independently verified. ## Trac and OpenMayhem Intercom supplies peer-to-peer communication and replicated-state infrastructure. OpenMayhem defines signed service receipts and evidence, consent, and dispute rules. The P21 integration boundary is portable evaluation of those original artifacts, not a replacement communication network. ## Ordinals Inscriptions can publish content and references. They do not make arbitrary content true. Use optional policy/specification references where provenance is useful; do not inscribe each ordinary P21 report. ## Dependency decision Native DMT interpretation follows TAP-compatible rules. Trac networking is optional. External agents use ordinary service interfaces; the protocol does not require each agent to operate the entire Bitcoin stack. References: [TAP](https://github.com/Trac-Systems/tap-protocol-specs), [ord-tap](https://github.com/Trac-Systems/ord-tap), [Intercom](https://github.com/Trac-Systems/intercom), [OpenMayhem rules](https://github.com/Trac-Systems/openmayhem/blob/main/RULES.md), [Ordinals](https://docs.ordinals.com/inscriptions.html). ## 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] ## Resolution, registration and ownership are separate Receipts distinguish source extraction, element registration, deterministic derivation, token deployment/mint validity, and current ownership or balance. Verification of one never implies the others. Checking first-valid registration requires the relevant historical index and activation rules; an inscription inclusion proof alone does not prove that no earlier conflicting element exists. Pin the inscription's content digest, source profile, upstream revision, network, source block hash and height, canonical encoding, operation, parameters, input commitment and output. Include evidence scope and limitations. A missing source or unsupported pattern is INDETERMINATE, not a fabricated valid result. Indexer observations remain distinct from independently replayed protocol state. A raw Bitcoin-field fallback cannot silently satisfy an unperformed DMT registry check. ## 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 ## NAT across networks NAT has cross-chain representations; it is not confined to a Bitcoin-only user interface. The reviewed records identify an Ethereum representation, a Solana asset labeled dmt-nat (Wormhole), and a BNB Smart Chain bridge-token contract. This broadens the routes through which the NAT community can access services. These records establish identifiable representations, not a P21 audit of bridge backing, origin mapping, redemption or current bridge availability. Native Bitcoin TAP-NAT remains a required initial method. Cross-chain NAT is a first-class adapter target, with each network and contract or mint approved separately. A representation must preserve its exact origin/deployment reference, bridge route and version, destination identity, decimals, finality and pause/redemption assumptions. A ticker match is never sufficient; neither is an exchange listing alone. An approved representation can pay on its destination network without making each P21 job perform a bridge or treasury swap. The representation review does not change DMT source resolution: Bitcoin remains the source of a Bitcoin/DMT claim even when its service fee arrives elsewhere. The P21 source element remains to be announced. No NAT bridge is activated by this publication. [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) ## Optional P21 TAP enforcement profile TAP can serve as one enforcement adapter for TAP-native actions; it is not a mandatory dependency of every P21 receipt. The reviewed current TAP specification supports threshold delegation patterns including **2-of-2 authority key + policy key**, where both signers must approve, and 2-of-3 or higher configurations. That maps naturally to an agent authority key plus an independent P21 policy signer, while preserving the requirement that no alternate unrestricted authority bypass the gate. [Pinned TAP specification](https://github.com/Trac-Systems/tap-protocol-specs/blob/0ba25b37d51e41e8b8958b0eb4a2c420a84a6361/README.md) The same reviewed specification lists token locks, delegated locks, certified control and conditional obligations at activation block **952317**, and documents HTLC/escrow-style conditional settlement and refund paths. These primitives can support higher-value workflows where settlement should remain conditional rather than immediately irreversible. [Pinned TAP specification](https://github.com/Trac-Systems/tap-protocol-specs/blob/0ba25b37d51e41e8b8958b0eb4a2c420a84a6361/README.md) P21 does **not** claim that a production policy signer, threshold wallet or escrow service is deployed. Other execution environments may use smart accounts, MPC, HSM/KMS policy, wallet plugins or API capability proxies while preserving the same action-bound authorization invariants.