Research sources and boundaries

Reviewed for this foundation on 2026-09-06. Documentation and implementations change; pin revisions when implementing. This is a source review, not an audit or a measurement of production demand. Some GitBook pages did not fully render in the research browser; indexed excerpts were cross-checked against TAP documentation and code. No usage, revenue, or capacity benchmark is asserted by these files.

Bitcoin, DMT, and TAP

DMT introduction: https://digital-matter-theory.gitbook.io/digital-matter-theory — conceptual data-derived elements/assets.
NAT deployment format: https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/non-arbitrary-tokens-nats/nat-deployment-format — references an element; not a general agent runtime.
TAP specification: https://github.com/Trac-Systems/tap-protocol-specs — supported DMT fields/operations and metaprotocol rules. Distinguish protocol rules from deployment maturity.
ord-tap element implementation: https://github.com/Trac-Systems/ord-tap/blob/main/src/index/updater/inscription_updater/tap/ops/dmt_element.rs — reviewed blob SHA 8f56fb65dca57332941be3718a499f9606f85ffc; field acceptance, pattern handling, and uniqueness checks.
Bitcoin block header reference: https://developer.bitcoin.org/reference/block_chain.html — nonce, target encoding, and header structure.
Bitcoin confirmation caveats: https://bitcoin.org/en/you-need-to-know — approximate cadence, variable delays, and confirmations.
Ordinal inscriptions: https://docs.ordinals.com/inscriptions.html — publication/content mechanism; no automatic truth of embedded statements.
OpenTimestamps: https://opentimestamps.org/ — independently verifiable Bitcoin timestamping and public calendars; not correctness or data-availability certification.
Bitcoin Beacon research: https://arxiv.org/abs/1605.04559 — conditional security of Bitcoin-based randomness; not a guarantee that arbitrary block-field extraction is unbiased.

Interoperability and agent commerce

CAIP-2: https://standards.chainagnostic.org/CAIPs/caip-2 — chain identification, not cross-chain consensus verification.
x402 Bazaar: https://docs.x402.org/extensions/bazaar — machine-readable paid-service discovery; listing does not guarantee use.
x402 signed offers/receipts: https://docs.x402.org/extensions/offer-receipt — commercial artifacts, not independently established correctness of arbitrary work.
x402 schemes: https://docs.x402.org/schemes/overview — separate fixed-price, usage-based, and batching semantics; implementation/network support must be checked.
PEAC: https://www.peacprotocol.org/ — existing signed record/evidence interoperability; a compatibility target rather than a reason to duplicate its envelope.
MCP Registry: https://modelcontextprotocol.io/registry/about — discovery metadata and distribution scope.
A2A discovery: https://a2a-protocol.org/latest/topics/agent-discovery/ — advertise a real conforming service, not only a placeholder card.
Venice token launch: https://venice.ai/blog/introducing-the-venice-token-vvv — historical product-before-token example; not evidence that Proof21 needs identical issuance or allocations.

Build and documentation

Codex project instructions: https://developers.openai.com/codex/agent-configuration/agents-md — repository-local guidance.
Codex sandboxing: https://developers.openai.com/codex/sandboxing — permissions/approval boundaries; fast code generation is not a security audit.
GitBook organization MCP: https://gitbook.com/docs/docs-as-code/gitbook-mcp — authenticated organization content actions.
GitBook published docs MCP: https://gitbook.com/docs/ai-for-your-readers/mcp-servers-for-published-docs — read-only docs retrieval, separate from editing or P21 runtime tools.
GitBook GitHub Sync: https://gitbook.com/docs/docs-as-code/git-sync/enabling-github-sync — repository-to-docs workflow; inspect permissions before publication.

Typography sources

Inter: https://rsms.me/inter/
IBM Plex: https://www.ibm.com/plex/
Doto: https://fonts.google.com/specimen/Doto

Font choices are a proposed implementation of the selected visual direction. They are not a verified identification of the reference photograph's typography. No font binaries or the reference photograph are redistributed in this repository.

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]

[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

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