Glossary and FAQ

Artifact: a document, signed record, proof, or other original piece of evidence.

Observation: what an identified source reported at a specified time; not automatically canonical truth.

Finding: the result of a named predicate evaluated against evidence.

Report: the findings, evidence bindings, evaluator/version, and limitations for an operation.

Verification: checking integrity and specified bindings under stated assumptions.

Acceptance: the consuming application's own decision after verification/evaluation.

Commitment: a cryptographic binding to data; not proof that the content is true.

Entropy: uncertainty in a source under an explicit threat model; expanding a seed does not create independent entropy.

DMT: Digital Matter Theory, the data-derived element/asset framework supported here through specified profiles.

Does every P21 request need Bitcoin?

No. Bitcoin/DMT is first-class support, but unrelated financial checks should not wait for a fresh Bitcoin transaction. Future-source selection and confirmed commitments have separate timing requirements.

Does P21 replace wallets, AP2, x402, or guardrails?

No. P21’s protocol consumes compatible evidence and defines specific checks. Authorization, spending limits, custody, and settlement remain separate.

Can any agent use it automatically?

Only when it has a compatible interface, permitted tool access, and an authorized budget if the service is paid. A registry entry does not override operator permissions.

Is a valid report enough to release money?

No. It must match the expected operation and policy, contain sufficient evidence, and satisfy the consumer's acceptance requirements. Alpha is shadow-mode only.

Is the token live?

No token is launched by this foundation. P21 is the project shorthand, not evidence of a tradable asset.

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

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 · Binance integration · Coinbase facilitator · PayAI assets · Virtuals ACP · NAT Ethereum listing · NAT Solana record · NAT BNB Chain contract

Enforcement and decision terms

Execution Gate — a policy boundary in front of a protected signer, wallet or API capability. It verifies a fresh action-bound authorization and recomputes the exact action digest before use.

Action Authorization — a signed artifact binding a request, policy, exact action digest, action profile, network, nonce and validity window. It is not a generic PASS badge.

Consumer Decision Receipt — a signed ACCEPT | REJECT | REVIEW decision referencing the proof/request/action and committed acceptance policy. It cannot rewrite independent proof, evaluation or settlement.

Decision Consistency — an independently derived CONSISTENT | CONTRADICTORY | UNRESOLVED finding; the consumer does not self-certify it.

Equivocation Evidence — evidence that the same consumer produced incompatible valid signed decisions for the same proof/policy/decision context. It is evidence, not a universal reputation score.