Bitcoin foundations. Agentic coordination.

Version 0.6 · Protocol specification

Abstract

Proof21 is a Bitcoin-native protocol for verifiable choices and checkable actions between autonomous agents. Its producer/consumer model binds evidence, policy evaluation, and independent acceptance. Financial action checks, Bitcoin/DMT derivations, batched commitments, and audit sampling share one architecture.

The protocol serves agent infrastructure: wallets, marketplaces, exchanges, DEX interfaces, and payment systems. This paper defines the protocol; implementation status records software availability.

1. Working payments are only part of a workflow

A settled payment answers an important question: did the network record the specified transfer? It does not necessarily bind every term of an off-chain service request to the deliverable or establish the quality of that deliverable. An operator may need to reconcile an instruction, a paid API interaction, an executed action, and a counterparty's acceptance requirements.

x402 carries payment and commercial evidence. Wallets and smart contracts enforce permissions and execution limits. Proof21 connects these existing controls to portable evaluation records, keeping service payment separate from the action being evaluated. [1]

2. A common verification path

An issuer or adapter collects evidence about a supported action. The P21 core evaluates the named policy against that evidence and produces specific findings. A separate consumer verifies the artifact, reproduces applicable checks, and applies its own acceptance requirements.

A valid signature may authenticate an incorrect claim. A passing evaluation cannot make an inadequate policy sufficient. A receiver must never interpret descriptive text inside a report as authority to bypass its wallet controls, install software, or move funds.

3. One core, complementary capabilities

Choice and Sample make a selection procedure inspectable. Commit an eligible set and rule, identify a source, apply a specified mapping, and let a counterparty reproduce the output. Historical reproducibility and future unpredictability are different modes. Bitcoin-based future selection remains experimental until its threat model and implementation are independently reviewed.

Check binds a financial instruction to evidence of a supported payment or payout. The profile includes network, exact asset, recipient, integer amount, operation, policy version, evidence, and finality. The fee for hiring a service is separate from the payout that service executes.

Elements resolves supported Bitcoin/DMT inputs and reproduces data-derived rules. A reproduced derivation does not automatically establish valid registration, minting, or ownership. Reports must say which claims were checked and which were not.

Verify and Accept are the consuming side. Suitable bundled historical evidence can be checked locally. Current revocation, freshness, or chain status may require network access under explicit source assumptions.

Commit optionally timestamps evidence digests or batches using an established system such as OpenTimestamps. A Bitcoin block hash written inside a report is not itself an anchor. A timestamp establishes prior existence under its verification model, not truth, completeness, privacy, or future availability. [2]

4. Bitcoin and Digital Matter Theory

DMT is a framework for defining elements and asset rules using Bitcoin data. TAP provides metaprotocol semantics for its supported DMT assets; those semantics matter whenever P21 checks a TAP-DMT claim. Reusing a conforming indexer avoids creating another asset-state engine. [3]

Bitcoin is not an oracle for arbitrary off-chain truth. Its history provides reusable source data and an external commitment substrate. Height is predictable; bits encodes the proof-of-work target; known block values do not become fresh entropy merely because they are hashed. Research on Bitcoin randomness explicitly models adversarial influence. [4]

Bitcoin/DMT is a first-class source, not a mandatory dependency of every check. An agent on another execution chain consumes relevant evidence without bridging assets or buying a Bitcoin-native token.

5. Selection without quiet rerolls

A future-source selection workflow must fix the candidate set, order, weights, sample size, policy, request identifier, source, and confirmation conditions before the outcome is revealed. The commitment itself needs verifiable timing or ordering evidence. A signed timestamp asserted by the party choosing the outcome is not sufficient on its own.

The design must address retries, withholding, cancellations, omissions, reorganizations, and aggregate incentives to influence a seed shared by many jobs. Source expansion does not manufacture additional independent entropy. Sampling a committed batch does not prove that the operator included every eligible job, and selecting an evaluator does not prove that evaluator is honest.

The Bitcoin selection profile exposes source conditions and derivation evidence, rather than replacing them with a generic fairness score.

6. Interoperability by composition

The service interface, evidence model, and payment adapter are separate. Preserve original signed artifacts; normalize fields for computation without discarding the signed source. A provider assertion, RPC observation, inclusion proof, and independently validated state must remain distinguishable.

Chain identifiers such as CAIP-2 identify networks; they do not prove another network's consensus. A common interface must retain chain-specific finality, asset behavior, and provenance requirements. [5]

Binance B402 Bazaar, Coinbase Bazaar, the MCP Registry, and Virtuals ACP are proposed integration/distribution surfaces. They are not current P21 listings or partnerships. A conforming MCP or A2A service must actually exist before a manifest claims one. [6]

7. Scale without one transaction per report

Ordinary checks run off-chain using cached or fetched evidence. Bitcoin data is reusable across jobs; consumers verify reports independently. Optional timestamps aggregate report digests into batches instead of requiring a fresh inscription or mint for every action.

This reduces on-chain overhead, not compute, source access, storage, bandwidth, security, or availability costs. Fresh Bitcoin-dependent assurance has variable latency and cannot honestly be described as instant finality. No P21 throughput or latency benchmark has been published.

8. Economics and a later token

Local verification should remain usable without a token or P21-operated server when the required evidence and accepted keys are supplied. Hosted services may charge for evidence collection, workflow execution, monitoring, and maintained integrations. Pricing must account for source, settlement, storage, and operational costs. Free calls and subsidized experiments are not organic revenue.

Token ownership is not a requirement for verification. No token issuance, allocation, eligibility, return, or launch date is offered by this paper. Any incentive mechanism requires separate technical, economic, and legal review.

9. Validation before high-value reliance

Begin in shadow mode: produce findings beside existing controls without moving customer funds. Require positive and negative fixtures, bounded parsing and fetching, explicit unsupported cases, and tests for tampering, replay, stale evidence, wrong assets/networks/recipients, failed transactions, and unavailable sources.

The first meaningful milestone is a complete request-to-independent-verification loop. A second process should reproduce supported findings and reject misleading evidence. Customer validation comes from independent counterparties using the result because it saves work or catches a meaningful issue—not from a website listing numerous future capabilities.

References

1. x402 signed offers and receipts
2. OpenTimestamps
3. TAP specification
4. Bitcoin block headers and Bitcoin Beacon research
5. CAIP-2
6. Agent distribution targets

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

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.

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.

Separate service fees, checked actions and treasury trades

Keep the service payment, the financial action being checked and any later treasury conversion as three separate records. Treasury conversion is optional and separately authorized after revenue settles, preferably batched. Approved routes require an executable quote, minimum output, slippage and fee limits, exact asset identities and explicit bridge/custody assumptions. A failed treasury trade does not erase a settled customer payment, duplicate the charge or alter a proof result.

USDC uses a validated x402 scheme and facilitator path; the standard's ability to express an asset does not establish production settlement. Native TAP-NAT is a separate payment adapter, not an unsupported claim of stock x402 compatibility. Neither an arbitrary wrapped token nor a generic DEX API substitutes for native NAT acceptance. [5]

[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-ecosystem-payments-v09 -->

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

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

From evidence to enforceable authorization

Proof21 keeps evidence mode and enforcement mode distinct. Evidence mode lets agents exchange and independently verify reports while existing wallet controls remain authoritative. Enforcement mode adds an execution gate in front of a protected signer, wallet or API capability. The agent proposes an action; the gate verifies a fresh P21 authorization and recomputes the exact action digest immediately before execution. The agent must not possess a second unrestricted authority path.

An authorization binds the request, policy, exact action, action profile, network, nonce and validity window, plus asset/recipient/amount where the profile requires them. A proof for action A cannot be replayed to authorize action B. State-dependent conditions are rechecked at execution time to address time-of-check/time-of-use drift.

Acceptance remains a separate dimension. A receiver signs a consumer decision receipt referencing the proof, request/action, committed acceptance-policy digest/version, decision, reason codes, evidence snapshot and time. REJECT never rewrites VALID, PASS or independently confirmed settlement. An independent evaluator—not the receiver—derives whether the decision is CONSISTENT, CONTRADICTORY or UNRESOLVED. Two incompatible valid decisions under the same proof/policy/context can form equivocation evidence.

For TAP-native actions, the reviewed TAP specification provides an especially direct optional enforcement adapter: 2-of-2 authority+policy signing requires both signers, while higher threshold patterns permit redundant policy signers. The same specification documents locks, conditional obligations and HTLC/escrow-style paths activated with the current authority feature set. P21 does not claim these integrations are deployed. https://github.com/Trac-Systems/tap-protocol-specs/blob/0ba25b37d51e41e8b8958b0eb4a2c420a84a6361/README.md

The DMT element-registration procedure is also promoted to a near-term operational task: privately choose the exact candidate, verify historical name and field/pattern uniqueness under the pinned rules, inscribe, confirm/index, independently verify, and only then announce it. No candidate details are disclosed here.

Registry scope and disclosure

The DMT registry's field catalogue is broader than the reviewed TAP parser's supported subset. A documented field is not automatically an implemented P21 profile. Use pinned interpretation rules and return INDETERMINATE for unsupported semantics. A supported, available whole-field definition can be registered without issuing a token; registration does not require a manual P21 or team approval. DMT registry

Private candidate selection and preparation are not private Bitcoin settlement. The Ordinals reveal transaction exposes inscription content, which can be visible to transaction observers before confirmation. Delaying our announcement does not prevent copying, guarantee ordering or reserve a name. Recheck competing registrations and canonical index state after confirmation; a conflict or reorganization prevents claiming successful registration until resolved. Ordinals commit/reveal

The P21 source element remains to be announced. Registry recognition, token deployment and service payments are distinct operations. Neither registration nor a new name makes public Bitcoin source data exclusive or creates independent entropy.