Protocol architecture

P21 combines a deterministic core, source-specific evidence adapters, and thin delivery interfaces. Bitcoin’s block history and optional commitments form the shared public reference; each agent retains its own acceptance policy.

Components

Adapters resolve original evidence and preserve its type, provenance, network, source version, and observation time. They must not upgrade an RPC observation into a consensus proof.

Core validates structure and binding, executes supported policies, and produces explicit findings. The LLM may interpret a request or explain a result; it does not decide cryptographic validity or execute arbitrary instructions from an artifact.

Producer interfaces assemble evidence and reports. Consumer interfaces verify them, reproduce checks, and apply local acceptance requirements. Both use one versioned interpretation.

Hosted workers may fetch evidence, manage jobs, and deliver callbacks. They have no authority over customer funds in Alpha.

Scope boundaries

A report is not custody, a settlement engine, an identity registry, a guarantee of investment quality, or a general proof of model execution. Choosing a neutral audit sample is distinct from proving job completeness and distinct again from correctly evaluating the sampled work.

The source transport, payment rail, and execution chain may differ. Each retains its own trust and finality assumptions.

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.

[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

From evidence to optional enforcement

Proof21 separates evidence mode from an optional execution-gated mode. Evidence mode produces and verifies reports without controlling a wallet. In execution-gated mode, a protected signer, wallet, API capability or other authority is reachable only through a policy gate. A model response is never the final spending authority.

The gate recomputes the exact action digest immediately before execution and checks the authorization's request, policy, network, asset where applicable, nonce and expiry. A valid authorization for action A cannot authorize action B. Current release artifacts specify this contract only; no production P21 policy signer or custody path is released.

A consumer's later ACCEPT, REJECT or REVIEW decision is a separate signed artifact. It never rewrites artifact integrity, deterministic evaluation or independently established settlement.