Proof21
EN
Menu
Browse documentation
Protocol specification

Verify, evaluate, accept

Read Markdown

The receiving agent makes three independent decisions: artifact integrity, evidence evaluation, and policy acceptance.

Stage Question Result
Verify Is the artifact intact and bound to the expected issuer/context? VALID / INVALID / UNRESOLVED
Evaluate Does sufficient evidence satisfy the specific predicates? PASS / FAIL / INDETERMINATE
Accept Is this sufficient under the consumer's own policy? ACCEPT / REJECT / REVIEW

Required consumer behavior

Bind the expected operation, instruction, profile/version, asset/network, issuer or trusted key, and freshness requirements. Evaluate the required finality state and reject replayed or mismatched context. Unknown critical fields, missing evidence, unavailable keys, and unsupported profiles must not become success.

A correctly signed FAIL is a valid artifact but an unsuccessful evaluation. A PASS may still require REVIEW if the issuer is not accepted, the evidence is stale, or the consumer requires independent observations not present in the bundle.

Local verification

Original evidence, accepted keys, and the matching profile implementation allow a consumer to reproduce supported checks locally. Offline verification covers the supplied snapshot. Current revocation, freshness, canonicality, and finality can require additional online evidence.

Authorization remains outside the verdict

The SDK must not call a wallet or release escrow merely because a report contains PASS. Existing permissions and transactional controls remain active. Recheck state-dependent conditions immediately before an action where applicable; a preflight report can become stale between checking and execution.

Alpha integrations operate in shadow mode. The receiver records what it would accept without giving P21 unilateral control over funds.

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

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

Acceptance cannot rewrite proof or settlement

Keep independent state dimensions. A receiver can legitimately produce:

artifact_integrity:   VALID
evaluation:           PASS
settlement:           CONFIRMED
consumer_decision:    REJECT

The REJECT does not turn the artifact into INVALID, the evaluation into FAIL, or a confirmed network settlement into an unconfirmed one. A receiving agent is not an oracle of ledger truth.

Policy precommitment and signed decisions

When a workflow wants objective counterparty-accountability, the receiver commits to the applicable acceptance policy before the other party takes the protected action. The quote/request context binds the acceptance-policy digest, version and validity window. Afterward, the receiver signs a P21 consumer decision receipt.

If the committed policy is deterministic and all required evidence is available, an independent verifier can derive decision_consistency = CONTRADICTORY when the signed decision conflicts with that policy. If the policy legitimately depends on private or unavailable inputs, the result is UNRESOLVED, not an accusation.

Two incompatible signed decisions for the same proof, policy and decision context form machine-checkable equivocation evidence.

Optional execution gate

For protected actions, evidence can be upgraded into an action-bound authorization. The gate checks the exact action digest, policy digest, request, nonce, network, asset where applicable and expiry immediately before using the protected capability. The LLM/agent must not possess a bypass path around that capability. This is a specification target; current Alpha behavior remains non-custodial/shadow mode.

Local search · No prompts or queries sent to an AI provider

Privacy & preferences

Essential

Website delivery and security; a local record of your privacy choice for up to 180 days. No advertising identifier.

Save your motion preference on this browser. Optional; off unless you choose it.

Use static illustrations. Your device setting takes priority. No storage permission is needed.

Analytics & advertising

Currently off. Future cookies, pixels, or analytics will be disclosed and require a new choice where applicable. These buttons do not authorize future tracking.

Privacy · Cookies