刻完就作废：BRC-20 的 transfer 铭文为什么是一次性凭证

用比特币浏览器数过 BRC-20 相关铭文的人，多半见过一屏“看起来还在、用起来没用”的记录：一串 transfer 铭文安静地躺在地址名下，协议却不再承认它们。做比特币钱包与索引服务的 Secret Key Labs 在 Xverse API 文档里给这类对象一个正式名称：void inscription（作废铭文）。其定义页写得很清楚——指 BRC-20 或 TAP 协议中已不再有效的铭文：transfer（转账）类铭文在第一次被用于转账后即失效，mint（铸造）等其他类型的铭文则在刻写完成后立即失效。

先理解 BRC-20 的记账为什么需要“用完作废”。BRC-20 没有账户余额字段，一切状态由铭文按出现顺序被索引器重放得出：先数 deploy 与 mint 确定发行量与持有量，再把每条 transfer 铭文当作一笔“从刻写者转给接收者”的指令执行。一条 transfer 完成使命后，如果不作处理，重放时会被重复计入，因此索引协议必须规定每条转账指令只生效一次。void 状态不是比特币链上发生了销毁——那笔交易、那段 JSON 数据原样躺在区块链上，任何全节点都能重新取到——它记录的是索引层的判断：这条指令的会计效果已经消耗。

这就带出 BRC-20 世界里最常见的一类“对不上账”。浏览器按铭文计数：你的地址名下有五十条铭文记录；钱包按协议余额显示：可用代币折合若干。两个数字天然不等，差额里就有已作废的 transfer 与 mint。反过来，如果有人拿“链上有我地址的 N 条 transfer 铭文”主张持有量，正确的回应是查这些铭文是否已被消费——同一条铭文被重复主张，正是早期索引器实现分歧制造的混乱之一。

把 void 概念查明白的实用价值有三处。第一，读接口：各家浏览器与 API 对“作废铭文”的字段命名不一，理解 Xverse 文档这类明确定义后，看到 void、spent、invalid 等标记都能对上同一件事。第二，估算费用与体积：作废铭文仍是占着 UTXO 的实体数据，整理钱包、合并输出时它们是可动的普通聪来源，但移动它们的交易费由当前持有者付。第三，防误购：二手市场上有人按“铭文条数”宣传持仓，条数里混着多少已作废的一次性凭证，直接决定这个持仓说法的实际含量。

还有一层操作含义涉及“销毁”与“作废”的区别，两者经常被混用。作废是索引层的会计状态，原件数据还在、还占你的输出；链上烧毁则是把承载铭文的聪转进可证明不可再花的去向（如 OP_RETURN 输出），是主动花一次交易费做的清理动作。有人为了减体积选择烧毁作废铭文，有人留着不理会——两条路的成本差在“整理费谁出”：留着，未来的交易挑选输入时仍可能被卷进这些 UTXO 的体积账单；烧毁，则现在就付一笔费换干净。无论哪种，都不改变协议余额，这是两类操作共同的底线。

TAP 被文档与 BRC-20 并列，说明“一次性指令铭文”不是 BRC-20 独有设计，而是这一类指令式协议的共同结构：指令生效一次，之后原件保留、效力消耗。对读者来说，这个抽象比记某个协议的细节更耐用——未来遇到任何“用铭文当指令”的比特币协议，先问三个问题：指令是否只生效一次、作废状态由哪个索引器判定、判定规则写在哪份文档里。三问有答案，余额与铭文条数的差异就都是可以对账的口径差，而不是玄学。

最后一条边界：协议层没有任何机制能把 void 铭文“恢复生效”，也没有全网统一的作废登记——每个索引器按自己的规则重放历史，作废是重放结果的属性。主流索引器对 BRC-20 生命周期的处理高度一致，所以日常查询很少遇到分歧；但在分叉实现、边缘用例（重复刻写、嵌套引用）上，不同索引器仍可能给出不同余额，这也是 BRC-20 类资产核对时值得同时查询两个独立索引服务的原因。本文只描述机制与口径，不构成对任何协议设计优劣或资产价值的评价。

本文为机制说明，不构成任何投资建议。