地址标签：把身份归属与链上观察分开
地址标签是一项需要证据支持的身份主张，不是区块链转账自带的属性。链上可以观察某地址在某网络发生了什么；把它连接到公司、个人、交易所或金库，则需要另一条身份论证。这条论证可能过时，也可能一直存在不确定性。
Ethereum 账户文档解释账户结构和技术属性，但这些属性不会自动揭示受益所有人。研究数据库应把技术分类、操作角色和实体身份分成不同字段，不要因为识别出合约，就认为知道谁最终拥有资产。
使用归属证据阶梯
优先寻找经过身份确认的官方渠道发布的地址、可以检查的部署关系或直接所有权说明。逐字记录声明究竟覆盖什么。组织公布一个运营钱包，不等于宣称此后每个接收其转账的地址都属于自己。
随后记录第三方标签，附提供方、读取日期和已披露理由。没有解释的标签可以保留为线索，但不能自动获得与直接声明相同的证据地位。多个浏览器也可能复制同一来源，因此“大家都这样标”未必构成独立佐证。
| 字段 | 应记录的内容 |
|---|---|
| 网络与地址 | 具体链及完整标识 |
| 被归属主体 | 组织名称或运营角色 |
| 证据类型 | 直接声明、部署关系、启发式推断 |
| 适用范围 | 单地址、合约、服务或拟议地址簇 |
| 有效时间 | 首次观察时间与复核触发条件 |
| 未确定事项 | 替代解释、缺少的证明 |
这是一套研究分层规则，不是概率模型。没有校准数据时，不要凭感觉写出精确的可信度百分比。
假设案例：托管服务不是客户身份
假设虚构组织正式发布 A 为金库地址。A 向 B 转出代币，某数据服务把 B 标记为托管充值地址。直接可支持的事实是指定时间 A 向 B 发生转账。如果托管标签可靠，它进一步说明接收服务的角色。
但这仍不能确认托管机构给哪个客户记账、原组织是否保留受益所有权，或者是否发生现货出售。把 B 永久归入该组织的钱包集合，是扩大证据范围；再把 B 后续接触的所有地址都归入同一实体，扩大得更多。
如果组织后来宣布金库从 A 迁移到 C，应保留 A 的历史角色并注明结束时间或角色变化，而不是删除旧标签。历史查询与当前身份查询需要不同答案，这样后来者才不会无意中用今天的身份图解释过去的行为。
检验地址簇边界
研究确实需要合并地址时，先写合并规则，再算余额。官方声明覆盖的地址组成较窄集合，仅由交易模式联系起来的地址保留为拟议集合。分别计算含有和不含不确定成员的结果，观察结论是否依赖某个猜测。
同时寻找反对归属的证据。新的官方说明、托管迁移、合约管理变化或操作模式改变，都可能触发重新核查。持续有交易不保证身份持续不变；过去正确的标签，也未必适合今天的主张。
保留原始证据链接，而不只保存提供方当前展示的标签文字。截图可以证明某天界面显示什么，交易记录和正式声明则支持结论的不同部分。标签消失时记录变化，不要猜测删除原因。
边界与常见错误
该流程不能把未知地址去匿名化，也不能把启发式地址簇变成经过确认的法律实体。不要从薄弱模式推断个人身份。常见错误是把服务地址当成一个客户、沿所有转账无限传播标签、将转载标签视为独立佐证，以及混淆管理权限与受益所有权。
最终表述应包含范围和不确定性：依据什么来源，在什么日期，把哪个地址归入什么操作角色。不要暗示知道全部最终持有人或动机。
常见问题
多个浏览器标签一致能证明所有权吗？
仍要检查来源和范围。如果只是重复同一个无依据标签，界面数量不会创造独立证明。
没有标签的大额地址应该叫什么？
使用中性编号，描述可以观察的余额与活动。没有相关证据时，身份继续标为未知。