Proof21
EN
Menu
Browse documentation
Protocol specification

Security and trust boundaries

Read Markdown

Pre-alpha threat model. No audit has been completed. Do not entrust meaningful funds to the current documentation or examples.

Threat coverage

Forged or tampered artifacts; incorrect issuer/key binding; replay; cross-chain or cross-asset confusion; stale observations; chain reorganizations; missing evidence; compromised RPC/indexer responses; unsupported token behavior; and inconsistent policy versions.

Receipt URLs, API responses, inscriptions, and agent messages can contain malicious instructions or trigger SSRF. Fetching must have allowlisted schemes, private-network and metadata-address protection, bounded redirects, timeouts, byte limits, and no ambient credentials. Parser and regex behavior must be bounded.

Threats a receipt does not solve

A valid signature does not prove truth. An honest calculation over false inputs can be wrong about reality. An operator can omit work before committing a batch. Random evaluator assignment does not remove collusion. A timestamp does not prove exclusive ordering, confidentiality, or availability. A policy can be incorrectly designed even when its predicates pass.

Key and agent separation

Production signing, treasury, deployment credentials, and research agents are separate trust domains. Research workers have no wallet authority. Development changes pass review before modifying accepted keys or releases. GitHub and public documentation exclude seed phrases, private keys, API secrets, and sensitive customer evidence.

Operational requirements

Pin dependencies, review supply-chain changes, use least privilege, redact logs, constrain data retention, and document outages. Evidence unavailability returns INDETERMINATE. Do not change failure behavior to make a demo pass.

The repository's SECURITY.md defines the disclosure route. Until a verified public security contact is configured, use an existing private collaboration channel and do not publish exploit details or real customer data in public issues.

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

Reproducibility is not unbiased randomness

A public nonce is not a private or uniform randomness source. Hashing a nonce, or adding the block hash, does not remove miner influence or create independent entropy. Different request contexts produce different deterministic outputs, not newly independent randomness. [7]

For future-source selection, bind the eligible set, ordering, weights, request ID, context, algorithm, source profile, exact future-block rule and confirmation policy before the source is known. Preserve externally checkable evidence of that commitment's timing; a hash created afterward cannot prove precommitment. Define one accepted request, retries, cancellations, withheld outcomes, late publication and reorganization recovery so an operator cannot choose among rerolls. Assess aggregate value across jobs sharing a source. Historical replay and future-source selection must not share the same assurance label.

Payment evidence and exactly-once accounting

An invoice binds caller, request digest, idempotency key, exact network and asset identity, merchant recipient, integer atomic amount, service-credit entitlement, expiry and settlement policy. A payment adapter checks an executed transfer event and its destination, amount, deployment identity, canonical block, confirmations, index coverage and supported rule revision. A transaction ID, mempool observation, inscription creation or wallet balance screenshot is not payment settlement.

Store event uniqueness using network, asset deployment, transaction and operation/inscription identity. Bind invoice ownership to the caller through the invoice contract rather than accepting any submitted transaction hash. Use atomic ledger transactions and unique constraints for settlement crediting, job reservation, consumption and release. Network retries and webhook replay never create another credit or charge. Missing evidence, lagging/conflicting indexers and reorganizations remain pending or require review. Define a compensating journal and operator-loss policy for a deep reorganization; do not silently debit another customer payment.

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

Malicious-agent and false-denial threat model

A report cannot force an unconstrained agent to obey it. High-assurance execution therefore requires capability separation: the model may propose an action, but a protected signer or API authority is available only through an execution gate that verifies a fresh action-bound P21 authorization. If the model retains another signing key, unrestricted RPC credential or alternate spending path, the gate is bypassable and the protection claim is false.

Bind authorizations to the exact canonical action, request, policy, network, asset/recipient/amount where relevant, nonce and expiry. Recompute the action digest immediately before signing to address substitution and time-of-check/time-of-use risk. Recheck state-dependent predicates at that point.

A malicious receiver cannot overwrite independent facts by saying DENIED. Its ACCEPT | REJECT | REVIEW is a signed consumer decision. Settlement and deterministic evaluation remain separate. Contradiction can be reported only when the receiver previously committed to a deterministic policy and the necessary evidence is available; otherwise return UNRESOLVED.

Store incompatible signed decisions rather than replacing one with the other. Two valid incompatible decisions under the same proof/policy/context can constitute equivocation evidence. This does not automatically define a universal reputation score or penalty.

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