Proof21 foundation and build plan

Proof21’s protocol specification connects Bitcoin-native data and commitments with independent agent verification. Implementation status records release availability.

Product direction

One producer/consumer model covers verifiable choices, audit sampling, financial checks, and Bitcoin/DMT evidence. TAP-compatible interpretation governs native DMT semantics. Trac networking is optional; cross-chain evidence access does not require a token bridge.

Choice / Sample remains prominent but experimental. Check and Elements provide concrete initial evaluation profiles. Verify / Accept separates artifact integrity, predicate evaluation, and the recipient's policy. Commit adds optional asynchronous Bitcoin timestamps without one L1 transaction per request.

Implementation map

Build sequence

The reference architecture uses one deterministic TypeScript core with thin CLI, HTTP, and MCP interfaces. Source adapters, request bindings, negative fixtures, and commitment handling share the same versioned interpretation.

Release availability follows tested implementations, not a calendar estimate.

Publication and operations

The website provides readable documentation, full-text research, source diagrams, and structured resources. Product status is stated separately from website availability. Read-only access does not require an account or wallet.

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.

Commercial activation and implementation status

NAT and USDC are both required for the initial commercial-launch acceptance test. Public documentation, source code and policy fixtures are not live payment endpoints. The static payment-policy resource lists required launch methods with enabled: false, no recipient and no live endpoint until each rail passes end-to-end settlement, accounting, failure/reorganization, security and owner-approval gates. Do not advertise a USDC-only release as the completed initial payment scope.

No token has been issued, no source element is announced, and no mainnet inscription, customer charge, treasury swap or wallet authorization is performed by this release. Production service availability remains separate from website publication. No Trac partnership, hosted SLA or independent cryptographic audit is implied.

[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