同名 BRC-20 怎么分真假：tick 长度、命名空间与索引器口径

搜索一个 BRC-20 代币出现十几个同名结果，持有人不知道该按哪个 deploy 交易核验余额。根源在于 BRC-20 的名字只是一段 JSON 文本，没有全局注册表。本文解释名字冲突如何产生、索引器怎么裁定，以及用户该按什么顺序核对。

名字只是 JSON 里的一个字段

deploy 铭文的 JSON 里，tick 字段声明币种名。BRC-20 没有名字注册机制：tick 就是一段纯文本，比特币节点不裁决重名；协议文档对 4 字节 tick 的约定很简短，各索引器对大小写与重复 deploy 的处理是各自实现层面的规则，两条只差大小写的 deploy、或先后刻下的多条同名 deploy，在不同工具里可能被当成两个币种、也可能被当成同屏竞争。谁先把格式合法的 deploy 铭文排进区块，文本就在链上了——链上只保证存在性，不保证唯一性。

谁来裁定哪条 deploy 有效

同名 deploy 可以共存，就必须有人回答“哪个地址持有多少枚”的账本问题。答案是索引器：各家索引器按自己的规则（典型做法是按区块内揭示顺序取最早的同名 deploy 为有效，其余同名 deploy 的铸造记录被忽略）推定余额。规则大体相似、实现却各走各家，于是同名 tick 在不同面板上的持有人分布与供应量可以完全不同。这不是谁显示错了，而是两本账本按不同口径在记。

更长 tick 的现实含义

社区后来提出用更长的 tick（如 6 字节命名空间）缓解 4 字节空间的枯竭与混淆，扩展的启用与历史数据的解释仍依赖索引器版本。对用户的直接含义：一个只写了 tick 的名字，在不同索引器版本下可能对应不同的账本历史，跨工具查数据时先确认双方用的是同一套 tick 规则与口径。

核对代币身份的实操顺序

第一顺位是 deploy 交易哈希：锁定你打算认可的 deploy 铭文 ID，查它的 tick 原文、供应量上限 max、单笔限额 lim 和持有者分布，这是唯一不随展示端变化的锚点。第二，确认你所用钱包与交易平台索引的就是这条 deploy，平台上线某 BRC-20 时通常公告对应铭文 ID，比对公告即可。第三，用至少两个独立索引器交叉查同一地址余额，口径一致的结论才可信。第四，凡只给名字、给不出 deploy ID 的同款代币，按新资产单独核验。

安全建议

不要把同名当同物：转币前查收款地址在目标 deploy 下的历史余额；不要凭截图确认收款：截图里的名字没有身份含义；对同名升级版保持警惕：协议层面不存在官方改名机制，要求迁移到新 tick 的说法都值得多问一句。

交易所在这件事上的角色

中心化交易平台上线 BRC-20 时，通常会公布其索引的 deploy 铭文 ID 作为充提依据。对用户来说，平台公告是最低成本的口径锚点：把自己的钱包指向同一 deploy，充值地址校验才不会出现“到账但不可提”的错位。若发现钱包显示的资产与平台无法对账，第一件事不是提工单，而是核对双方的 deploy ID 是否一致，多数乌龙在核对后自动消失。 对做数据分析的读者，同名问题还提醒我们尊重口径：引用某索引器的供应量或持有人数据时，应同时注明索引器与其对同名 deploy 的处理规则，否则同一张图换一家数据源就自相矛盾，这是公开讨论里最常见的争论来源之一。

风险提示：本文为防混淆的安全提示内容，不构成任何投资建议或代币价值鉴定意见。