Capabilities

One evidence pipeline. Five complementary protocol capabilities. Implementation 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