# 术语与常见问题

**Artifact（证据文件）：**文档、签名记录、证明或其他原始证据。

**Observation（观察）：**已标识来源在指定时间报告的内容，不自动等于规范事实。

**Finding（检查结果）：**针对证据评估具名谓词的结果。

**Report（报告）：**某操作的检查结果、证据绑定、评估方／版本和局限。

**Verification（验证）：**在明确假设下检查完整性和指定绑定。

**Acceptance（接纳）：**接收应用在验证／评估后的自身决定。

**Commitment（承诺）：**对数据的密码学绑定，不证明内容为真。

**Entropy（熵）：**在明确威胁模型下来源的不确定性；扩展种子不产生独立熵。

**DMT：**数字物质理论，通过特定配置支持的数据推导元素／资产框架。

## 每个 P21 请求都需要比特币吗？

不需要。比特币／DMT 是核心支持能力，但无关金融检查不应等待新的比特币交易。未来来源选择和已确认承诺有独立的时间要求。

## P21 会替换钱包、AP2、x402 或防护措施吗？

不会。P21 协议使用兼容证据并定义特定检查。授权、支出限制、托管与结算保持独立。

## 任意智能体都能自动使用吗？

只有当它有兼容接口、获准的工具访问权限，以及付费服务所需的授权预算时才可以。目录条目不覆盖运营方权限。

## 有效报告足以释放资金吗？

不足以。报告必须匹配预期操作与策略、包含足够证据，并满足接收方接纳要求。Alpha 仅以影子模式运行。

## 代币上线了吗？

本阶段未推出任何代币。P21 是项目简称，不代表可交易资产。

<!-- 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 和 Base USDC 仍为初次商业发布的必备方式。NAT 在以太坊、Solana 和 BNB Smart Chain 也有可识别的表示。接受前分别批准准确合约或 mint 及桥接映射；跨链可用性不会消除数据源自身的信任假设。

Binance B402 集成范围包括 BNB Smart Chain 上的 USDT、USDC、USD1 和 U，使用每种资产支持的方法。PayAI 和 Coinbase 通道使用经测试的网络／资产组合；Virtuals ACP 保留 USDC 任务支付生命周期。MCP 与 A2A 不指定付款币种。付款选择和可选资金兑换与比特币／DMT 证据验证相互独立。这些是规范中的集成目标，不是已启用的支付服务。

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

## 执行与决策术语

**Execution Gate** — 位于受保护 signer、wallet 或 API capability 前的策略边界，在使用权限前验证新鲜 action-bound authorization 并重算精确 action digest。

**Action Authorization** — 绑定 request、policy、精确 action digest、action profile、network、nonce 与有效期的签名材料，不是通用 PASS 徽章。

**Consumer Decision Receipt** — 引用 proof/request/action 与已承诺接受策略的签名 `ACCEPT | REJECT | REVIEW` 决策，不能改写独立 proof、evaluation 或 settlement。

**Decision Consistency** — 由独立评估者推导的 `CONSISTENT | CONTRADICTORY | UNRESOLVED`，不是接收方自证。

**Equivocation Evidence** — 同一接收方在同一 proof/policy/context 下产生互相冲突且有效签名决策的证据；它不是通用信誉分数。