# Capabilities One evidence pipeline. Five complementary protocol capabilities. [Implementation status](https://proof21.xyz/docs/start/status/) records the available releases. ## Choice / Sample Choice / Sample produces a reproducible selection from a committed candidate set, rule, and named source. Bitcoin future-source selection is an experimental profile with explicit confirmation and source policies. ## Check Check compares a supported financial action with its instruction. Payment and payout profiles bind exact assets, recipients, amounts, execution outcomes, and finality. ## Elements Elements reproduces supported Bitcoin/DMT derivations. Calculation, registration, mint validity, and ownership remain separate findings. ## Verify / Accept Verify / Accept separates artifact integrity, predicate evaluation, and the receiving system’s acceptance policy. Supplied evidence and accepted keys support independent local verification. ## Commit Commit adds optional Bitcoin timestamps to report digests and batches. Commitment state remains independent of evaluation results. ## Packaging principle These capabilities are profiles around a common core. Cross-chain access does not require a Bitcoin wallet, asset bridge, or token purchase. Bitcoin/DMT is a first-class source without becoming a dependency of unrelated checks. ## 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