# TAP、Trac 与 Ordinals

Bitcoin 提供公开区块历史，TAP 定义元协议解释，Ordinals 承载铭文内容，Trac 提供可选通信层。P21 的适配器契约保留这些独立角色。

## TAP

TAP 定义受支持代币及 DMT 的解释规则。P21 报告若宣称兼容 TAP-DMT 资产，就必须遵守规则及激活行为。独立索引器消除了网络依赖，但不会消除资产规则解释要求。

## ord-tap

ord-tap 是基于 `ord` 的独立 TAP 索引器，通过 REST 提供当前与历史索引状态。适配器记录其版本、同步覆盖与重组行为。参考测试验证解释；除非经过独立验证，否则 API 响应仍属于观察。

## Trac 与 OpenMayhem

Intercom 提供点对点通信与复制状态基础设施。OpenMayhem 定义签名服务收据，以及证据、同意和争议规则。P21 的集成边界是对这些原始材料进行可携带评估，而非替代通信网络。

## Ordinals

铭文可发布内容和引用，但不会使任意内容变真。来源证明有用时，可增加策略／规范引用；不要把每份普通 P21 报告都写成铭文。

## 依赖决策

原生 DMT 解释遵循兼容 TAP 的规则。Trac 网络为可选项。外部智能体使用普通服务接口；协议不要求每个智能体运行完整 Bitcoin 技术栈。

参考：[TAP](https://github.com/Trac-Systems/tap-protocol-specs)、[ord-tap](https://github.com/Trac-Systems/ord-tap)、[Intercom](https://github.com/Trac-Systems/intercom)、[OpenMayhem 规则](https://github.com/Trac-Systems/openmayhem/blob/main/RULES.md)、[Ordinals](https://docs.ordinals.com/inscriptions.html)。

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

## 无需铸币的 DMT 解析

Proof21 将 DMT 用作版本化的数据源解释配置，而不是比特币共识或通用真理引擎。DMT 操作引用已认可的元素定义，以哈希和高度确定比特币区块，计算支持的字段或模式，并把输入纳入可重现的流程凭证。无需 DMT 代币、铸造或逐凭证写入比特币。仅使用比特币数据的操作采用独立、明确的数据源配置。

P21 数据源元素**待公布**。此处不公布注册载荷、选定的字段或模式、保留名称或元素铭文 ID。可以复用已有效注册的元素；协议不以新建品牌铭文为前提。

Trac 的独立 `ord-tap` 提供可复用的索引。固定版本的元素解析器支持字段 4、10、11，检查协议激活状态、规范化名称、验证模式，同时拒绝重复名称和重复的字段/模式签名。仅更换名称不能重新注册已有的整字段定义。已审查的解析器没有人工团队审批步骤；有效注册仍取决于历史规则验证，而不仅是比特币收录。托管服务的访问权限及条款另行确定。[1][2][6]


## 解析、注册与所有权必须分开

凭证区分源数据提取、元素注册、确定性推导、代币部署或铸造有效性，以及当前所有权或余额。验证其中一项不代表其余各项也成立。验证首个有效注册需要相关历史索引和激活规则；单份铭文包含证明不能证明之前不存在冲突元素。

固定铭文内容摘要、数据源配置、上游版本、网络、源区块哈希与高度、规范编码、操作、参数、输入承诺和输出。注明证据范围和限制。缺少数据源或不支持的模式应为 INDETERMINATE，而非伪造有效结果。索引器观测须与独立重放的协议状态区分。原始比特币字段回退不能悄悄代替未执行的 DMT 注册检查。


## 首发支付：原生 NAT 与 USDC

原生 NAT 是**初次商业发布的必备支付方式**，与经过验证的 x402 通道上的 USDC 并列，而不是留待后续的可选集成。证据协议保持支付中立：客户选择支持的方式，独立验证凭证从不要求购买 NAT 或 P21 代币。

原生 NAT 配置明确比特币主网、TAP、最初的 NAT 部署铭文和规范化同质化代币代码。其他链上同名代币属于不同资产，除非另有经审查的配置明确指定。转移 UNAT 铸造铭文并不会转移其同质化 NAT 余额。[3][4]

NAT 发票和预付服务额度充值异步处理：按固定 TAP 规则确认已执行的同质化转账，然后仅记入一次使用额度。后续小额任务消耗内部不可转让的服务额度，无需每次再转 NAT 或创建铭文。额度是服务会计记录，不是 P21 代币、收益产品或无信任托管承诺。较大任务的直接发票可使用相同结算检查。

接受 NAT 不要求自动 DEX 兑换。对明确的服务包报价固定 NAT 数量，或使用另行批准、包含期限和舍入规则的定价策略。收款前公开网络费用、最低充值、逾期、少付、多付、取消和退款规则。本规范不虚构汇率或最低金额。


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

## 跨网络的 NAT

NAT 存在跨链表示，并不局限于仅使用比特币的钱包界面。已审阅记录标识了以太坊表示、在 Solana 上标为 dmt-nat (Wormhole) 的资产，以及 BNB Smart Chain 的桥接代币合约。这扩大了 NAT 社区访问服务的路径。这些记录证明存在可识别的表示，并不代表 P21 已审计桥接储备、原始资产映射、赎回能力或当前桥接可用性。

原生比特币 TAP-NAT 仍是首发必备方式。跨链 NAT 是一等适配器目标，但每个网络及合约或 mint 必须分别批准。配置须保留准确的原始部署引用、桥接路径及版本、目标资产身份、精度、最终性和暂停／赎回假设。仅代码名称相同不够，仅交易所上线也不够。获批表示可以在目标网络支付，无需让每项 P21 任务都执行桥接或资金兑换。

这项表示审查不改变 DMT 数据源解析：即使服务费在其他链上支付，比特币仍是比特币／DMT 声明的数据源。P21 数据源元素仍待公布。本文发布不会启用任何 NAT 桥接。

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

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

## 可选 P21 TAP 执行配置

TAP 可以成为 TAP 原生操作的一种执行适配器，但不是所有 P21 凭证的依赖。当前审阅的 TAP 规范支持 2-of-2（authority key + policy key），要求两方都批准，也支持 2-of-3 或更高阈值。这可以映射为智能体 authority key + 独立 P21 policy signer，前提是不存在可绕过门控的另一条无限制权限路径。

同一规范把 token locks、delegated locks、certified control 与 conditional obligations 列在区块 952317 的激活集，并包含 HTLC／escrow 类条件结算与退款路径。P21 当前并未部署生产 policy signer、阈值钱包或托管服务。其他链可用 smart account、MPC、HSM/KMS 或 API capability proxy 保留同样的 action-binding 不变量。