BRC-20 常被一句话概括：在比特币上刻一段 JSON 当记账凭证。概括没错，却低估了它的苛刻程度。按 Layer1 基础基金会对外的索引规范，那段 JSON 必须逐条满足一串具体格式规定，任何一条不合规，索引器把整条铭文视为无效——不报错、不提示，当作它不存在。大量“链上明明有我这笔交易，钱包却没有余额”的困惑，根源就在这串门槛上。
第一条：数值字段必须是字符串。max、lim、amt、dec 这些看起来是数字的字段，在合规铭文里必须写成带引号的字符串，例如 "amt": "1000"；写成数字字面量 1000 反而不合规，规范明确不接受数值类型。这条规定谈不上优雅，但识别规则只认字符串，写错类型的字段一律忽略。
第二条：操作名与字段名全小写。op 的取值只有 deploy、mint、transfer 三个小写词有效，字段名也必须小写。刻写工具如果顺手把首字母大写成 Mint，这条铭文当场作废，且没有任何链上反馈告诉你原因。
第三条：代号长度有边界。tick 必须是四到五个字节宽（接受 UTF-8 编码），超出即不被接纳。同一代号的定义以最先被索引到的有效 deploy 为准，这也是同名代币争议里“先到先得”规则的出处之一。
第四条：缺省值有明文。dec（小数位）没写时按 18 计；lim（单次铸造上限）没写时按 max 处理。这解释了一个常见误读：同一份 deploy，不同人读出的“单次能铸多少”不一样，因为有人看到的是缺省规则生效后的宽松值，而不是项目方写下的限制。数值字段的上限则是 64 位无符号整数的最大值，越界同样落空。
第五条：超限静默作废，没有部分成功。mint 的 amt 大于 lim，这条 mint 被忽略而不是截断到上限；transfer 金额大于该地址当时可用余额，同样整条忽略。规范还处理了一个更隐蔽的边角：如果铭文的输出被当作手续费付给了矿工，这条记录要按规则作废或回冲——首次转移被作费时，数额要立即回补给发送方。对用户的意思很直白：链上有你的钱在动，不等于索引账本上你的余额在变。
把这些规则连起来看，BRC-20 的状态其实存在两本账里：比特币链上只有刻写记录，代币余额完全是索引器按上述规则重放出来的结果。两本账之间没有共识做担保，只有格式约定。所以“我的余额对不对”，取决于两件事：你的每条铭文是否逐字合规，以及你使用的索引器实现的是哪一套规则。
余额对不上时的合理排查顺序是：先回到具体那条 mint 或 transfer 铭文，取原始 JSON 逐字段对照——引号、大小写、tick 长度、amt 是否超过 lim；再检查它有没有踩上“输出作费”的作废条款；确认都合规之后，再换另一个索引器查同一地址做口径比对。跳过第一步就直接找客服、换钱包，通常只是把问题挪了个地方。
规范里还有一处容易看漏的对照：核心字段严到苛刻，附加字段却完全放开——不在规定范围内的额外字段可以是任何类型、随意添加。这个松紧并存的设计说明索引器的立场：它只承诺按自己认识的字段记账，不认识的一律不参与计算。对用户，这有两层实际含义。一层是自由：想给代币加展示信息、加防重放盐值，可以塞自定义字段而不破坏合规性。另一层是陷阱：你附加的字段没有跨索引器的保证，A 家按你的 lim 记账、可能也按你的附加字段做了风控，B 家可能整个忽略它们——同一份铭文在不同索引器眼里“功能”并不相同。把 BRC-20 的能力想象成由最严格那家索引器定义，是新手最常见的另一半误解。
最后把边界说清楚：BRC-20 是一份社区约定，没有官方权威机构；不同实现存在细节差异，本文列的是 Layer1 基金会公开规范的口径。凡涉及金额、规则边角，都应以你实际所用工具遵循的那份文本为准，而不是记住本文结论。本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。