# Digital matter is a rule, not a verdict. **Research note · 7 September 2026 · Proof21 Elements remains a proposed capability.** A creator can use Bitcoin data to define an object whose properties other people can reproduce. That is an interesting design space without pretending that a block field can answer every question about the object. Did a calculation reproduce? Was an element registered correctly? Was a deployment valid? Who owns an asset now? These questions require different evidence. Proof21's Elements proposal treats Digital Matter Theory as a first-class rule and data profile. It does not treat DMT as an agent runtime, a universal oracle, or an excuse to build a second incompatible token indexer. The intended contribution is portable, explicit evidence about supported derivations, alongside clearly labeled dependencies on existing ecosystem state. ## Start with the rule and the original source The DMT element registry describes names, optional patterns, and references to fields. A NAT deployment can reference an element inscription. The TAP specification describes its supported DMT operations and recognizes fields 4, 10, and 11 for height, nonce, and bits. These are related specifications, not interchangeable documents. [1][2][3] For a proposed derivation request, preserve the element inscription identifier and original bytes, the source block hash and height, the claimed field, the interpretation profile, and the expected output. Record which upstream revision the implementation follows. A field number without its namespace and rules is not a complete instruction. Height is an index in the chain context, not a separately serialized field of the Bitcoin block header. The nonce and compact target encoding have their own roles. Do not call every value “entropy,” especially when it is historical or predictable. The Bitcoin developer reference is the appropriate starting point for the header structure. [4] ## Make replay boring and exact Consider a synthetic creative project that assigns a visual trait from a supported historical source value. A producer reports the source, the rule version, and the computed trait. A second implementation should reach the same result without asking the producer which appearance it preferred. The example concerns deterministic derivation, not a newly minted asset or a claim that the trait has market value. Representation matters. A rule over hexadecimal text is not automatically a rule over a decimal number. Leading zeros, case handling, pattern semantics, byte order, and integer boundaries can change the outcome. Preserve the exact interpretation rather than translating the rule into a superficially similar regular expression. Unknown patterns should be reported as unsupported, not guessed into a successful result. Useful test vectors therefore include both ordinary values and boundary cases. Keep the original input bytes beside the expected interpretation. Test malformed inscriptions, unsupported fields, wrong block hashes, altered rule versions, ambiguous encodings, and a claimed output that does not reproduce. A simple favorable example is not sufficient evidence of compatibility. ## A calculation is not a historical state machine Even a perfectly reproduced trait does not establish that the associated element or mint was accepted under the relevant historical rules. A stateful claim may depend on activation conditions, prior registrations, deployment references, ordering, earlier mints, and subsequent transfers. The implementation must identify the applicable rules at the relevant point in history rather than apply today's behavior indiscriminately to old data. [2][3] Current ownership is a further question. The DMT transfer documentation specifically distinguishes a UNAT inscription from fungible NAT balances; transferring one must not be casually described as transferring everything associated with the project. A proposed P21 report should name the exact asset and evidence scope. [5] This distinction makes the interface more useful, not less. An application can display “derivation reproduced; ownership not evaluated” instead of a broad green “verified.” A collector can then obtain the separate state evidence needed for the actual decision. An agent should not fill the gap with a plausible story about who owns what. ## Reuse an indexer without hiding the dependency Where TAP-compatible indexers already implement the relevant rules, the first engineering question is how to reuse and test their output. Record the indexer identity, software or rule revision, indexed height, observation time, and reorganization behavior. Retain disagreement between sources rather than silently choosing whichever answer completes the task. An indexer's API response is an observation from that service. It is not automatically independent full validation of Bitcoin consensus and the entire metaprotocol history. A report can be valuable while stating that limit. The proposed consumer should be able to require stronger evidence for a higher-stakes decision and return `INDETERMINATE` when that evidence is unavailable. The original inscription must also be treated as untrusted data. A string claiming to contain “agent instructions” has no authority to run a shell command, download executable code, or request wallet access. Reading a rule is different from executing arbitrary content. The same separation applies to external URLs embedded in creative assets. ## A narrow pilot with an honest finish line A useful first pilot would select a small, documented set of supported element profiles and immutable source fixtures. Two independent processes would reproduce the results, reject altered inputs, and identify unsupported cases consistently. Where a stateful indexer is required, the pilot would record that dependency and test stale or conflicting responses. The finish line is not “all digital matter verified.” It is a bounded, repeatable claim with a clear list of checks performed and checks not performed. No P21 token, new Bitcoin write, or custody of user funds is required to evaluate that product hypothesis. The existing offline demo remains educational; it is not a production TAP indexer or a released Elements API. ## Frequently asked questions ### Does reproducing a trait prove ownership of a token? No. Reproduction checks a derivation. Ownership requires evidence about the exact asset and its applicable state history. A report should say explicitly when ownership was not evaluated. ### Must Proof21 replace TAP to support DMT? No. The proposed approach reuses compatible rules and infrastructure where appropriate, records their versions and limitations, and adds a portable evidence interface. Compatibility must be demonstrated with tests rather than asserted from a shared name. ### Can an element inscription safely instruct an agent to execute code? Not by itself. Inscription content is untrusted input, not authorization. Execution, network access, and wallet permissions require separate controls; a derivation profile should accept only its supported bounded inputs. ## Primary references and next reading - [1: DMT element registry](https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/digital-elements/.element-registry) - [2: DMT NAT deployment format](https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/non-arbitrary-tokens-nats/nat-deployment-format) - [3: TAP protocol specification](https://github.com/Trac-Systems/tap-protocol-specs) - [4: Bitcoin block header reference](https://developer.bitcoin.org/reference/block_chain.html) - [5: DMT token transfer and the UNAT distinction](https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/non-arbitrary-tokens-nats/nat-token-transfer) - [Proof21 Elements scope](https://proof21.xyz/docs/capabilities/elements/) ## 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] ## NAT across networks NAT has cross-chain representations; it is not confined to a Bitcoin-only user interface. The reviewed records identify an Ethereum representation, a Solana asset labeled dmt-nat (Wormhole), and a BNB Smart Chain bridge-token contract. This broadens the routes through which the NAT community can access services. These records establish identifiable representations, not a P21 audit of bridge backing, origin mapping, redemption or current bridge availability. Native Bitcoin TAP-NAT remains a required initial method. Cross-chain NAT is a first-class adapter target, with each network and contract or mint approved separately. A representation must preserve its exact origin/deployment reference, bridge route and version, destination identity, decimals, finality and pause/redemption assumptions. A ticker match is never sufficient; neither is an exchange listing alone. An approved representation can pay on its destination network without making each P21 job perform a bridge or treasury swap. The representation review does not change DMT source resolution: Bitcoin remains the source of a Bitcoin/DMT claim even when its service fee arrives elsewhere. The P21 source element remains to be announced. No NAT bridge is activated by this publication. [Binance assets and methods](https://developers.binance.com/en/docs/products/onchainpay-x402/basics/9.supported-payment-methods) · [Binance integration](https://developers.binance.com/en/docs/products/onchainpay-x402/introduction) · [Coinbase facilitator](https://docs.cdp.coinbase.com/x402/seller/facilitator) · [PayAI assets](https://docs.payai.network/x402/reference) · [Virtuals ACP](https://os.virtuals.io/acp/concepts) · [NAT Ethereum listing](https://www.bitmart.com/en-US/support/articles/7923014477723/360001026214/49446319153179) · [NAT Solana record](https://solscan.io/token/FbKRaqBzupLry3V7QujpNghwrHgxutB4MY11M8aeyVa1) · [NAT BNB Chain contract](https://bscscan.com/token/0x600e3b55d5368c32a94f9372563318adb6a3f882) ## Update · Register privately, announce after confirmation The element registry is permissionless, but valid registration still depends on the historical rules. P21 therefore treats element registration as a private operational sequence: choose the exact candidate, check both name and field/pattern availability against a sufficiently complete registry, inscribe, confirm, verify indexing independently, then announce. This avoids publishing a candidate before first-valid registration while also avoiding the mistake of assuming an already claimed whole-field definition can simply be renamed. The P21 element remains to be announced; this note intentionally discloses no candidate pattern or field. ## 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 ## 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](https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/digital-elements/.element-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](https://docs.ordinals.com/inscriptions.html) 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.