BRC-20 为什么两家工具余额不一样：索引器账本的规则分歧

一、链上没有 BRC-20 余额

BRC-20 是 2023 年出现的实验性标准：它不在比特币账本上建代币账本，也不改动共识，而是把一段段小 JSON 以铭文的形式写进交易，再由链下的索引器按规则重读这些 JSON、还原出谁有多少。也就是说，主网的验证节点根本不认识 BRC-20——它们只看到一笔笔带数据的普通交易。理解了这一层，很多困惑就有了共同的根：余额不是链上事实，是索引器对链上铭文序列的推导结果。

原始 JSON 长什么样，三类操作各一条就够：部署声明写 p 为 brc-20、op 为 deploy，外加 tick、max 等字段；铸造写 op 为 mint 与 amt；转移写 op 为 transfer 与 amt。字段值必须是字符串，数字直接写会不被承认。转账分两步：先给自己铸一张转移凭据铭文，再把这张铭文发给对方——接收者收到凭据铭文，索引器才把余额挪过去。

二、有效性规则：索引器的判卷标准

哪些铭文算数，有一套细则：内容必须是合法 JSON，尾随逗号就废；p、op、tick 必须齐备且小写；tick 为四或五字节、不区分大小写；dec 缺省按十八位小数；数值字段上限约 uint64，多余的字符、科学计数、正负号都不收；被规则判为诅咒的铭文不计入。还有一条历史注脚：铭文定义在 2024 年中经历过一次切换，按旧定义铸造的铭文在新定义下的计数方式随之改变——早期事件的账，新旧索引器可以名正言顺地算出不同结果。

这些规则不是共识，是约定。约定写在对所有索引器一致的部分里，但谁来执行约定、执行到哪条版本，没有任何链上机制强制。于是出现了这个标准真正的软肋：同一串铭文，两个索引器可以合法地给出两份余额。

三、余额分歧从哪来

分歧的典型来源值得逐条点名。第一是定义切换：协议文档把铭文识别绑定到某个客户端版本的定义上，而各家索引器跟进的时间不同，切换窗口前后的事件排序可以不同。第二是排序规则：同一区块内的铭文谁先谁后、跨区块如何合并，各家实现存在差异，先到先得的铸造尤其吃排序。第三是历史事件的回滚与重放：遇到重组，索引器回滚与重放的范围和顺序不同，瞬时归属可以错位。第四是版本漂移：有的索引器还在跑旧规则，新版本文档的规则已经改了，同一事件一边算有效一边算无效。

对用户而言，检验方法朴素而有效：用至少两个独立索引器查同一地址，再核对关键铭文在浏览器里的原始 JSON 与确认状态。工具意见一致不代表链担保了什么，只代表这些工具此刻恰好算得一样；意见分裂时，能回到原始 JSON 逐条对规则的，才是可信的那一份。

四、它和彩色币、Runes 的分界

把 BRC-20 放回比特币代币实验的谱系里更看得清：彩色币在一聪聪比特币本体上挂属性，币就是载体；Counterparty 另建一层记账规则；BRC-20 则把状态完全外包给链下索引器，链上只留 JSON 凭证；Runes 又换了一条路，用更紧凑的编码在 UTXO 层面组织代币账本。共同点是全部依赖链下解释层，区别只是解释层离共识多近。

这决定了它的风险清单：转账发到不支持铭文的地址形态、或者对方钱包把凭据铭文与普通币混在一起归并，都可能让索引器算错归属；用代铸服务时，凭据可能先铸在服务方地址上，链条中间多了一个信任点。它省掉了独立链的成本，换来的是把账本一致性交给一群自愿同步规则的软件。

风险提示：本文仅为协议机制科普，BRC-20 为实验性标准，不构成任何投资建议。