# 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.

```mermaid
%%{init: {"theme":"base","themeVariables":{"primaryColor":"#F7F6F2","primaryTextColor":"#181A18","primaryBorderColor":"#D4D6D1","lineColor":"#666A65","tertiaryColor":"#FFFFFF"}}}%%
flowchart TD
  A[Requester: instruction and policy] --> B[Evidence adapters]
  B --> C[P21 deterministic core]
  C --> D[Findings and evidence bundle]
  D --> E[Consumer verifies]
  E --> F[Local acceptance policy]
  D -. optional .-> G[Asynchronous Bitcoin commitment]
  H[Bitcoin / DMT / TAP] --> B
  I[EVM / signed service artifacts] --> B
```

## 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.

<!-- p21-source-payment-v08 -->

## 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

<!-- p21-enforcement-v10 -->

## 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.

```mermaid
flowchart TD
  A[Agent proposes exact action] --> B[P21 verification and evaluation]
  B --> C[P21 action-bound authorization]
  C --> D[Execution gate]
  D --> E[Protected signer / wallet / API capability]
  E --> F[Execution]
  F --> G[Settlement evidence]
  G --> H[Consumer decision receipt]
  H --> I[Consistency / equivocation checks]
```

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.