ERC-4973 账号绑定代币：不能转、可以卸的链上徽章长什么样

“灵魂绑定代币”一词流行之后，很多项目把 NFT 的转账函数一禁了之，宣称这就是灵魂绑定。ERC-4973（2022 年 4 月 1 日创建，现状为 Review 阶段）走了另一条路：与其造一枚“不能动的 NFT”，不如承认这类凭证根本不适用 NFT 的转让模型，为它们另立一套不含 transfer 的接口。标准的动机讲了《魔兽世界》的典故——Thunderfury 这类传说装备拾取后永久绑定角色，它的价格不是市场出价，而是集齐材料、组满四十人团队的全部社交成本。账号绑定代币（ABT）想做到的，正是让链上凭证回到“ earned, not bought（挣来的，不是买来的）”的语义。

一套没有转账的接口

ERC-4973 对身份核验做了明确切割：实现合约必须支持 ERC-165 与 ERC-721 的元数据接口（name、symbol、tokenURI 一族的 0x5b5e139f），但必须不实现 ERC-721 本体的 0x80ac58cd——任何试图把它当普通 NFT 转走的调用都不该存在。接口自己提供四类动作：balanceOf 与 ownerOf 负责查询；give 与 take 负责发放和领取，两者都要求提交符合 EIP-712 结构化数据的签名，发放动作因此可以被预签、代发；unequip 则规定接收人任何时候都能把徽章从自己名下卸下，事件里 to 写成零地址。用一个词概括这套设计：可拒绝的荣誉。被人塞给你的成就代币，你总有权利公开说不。

与灵魂绑定谱系的关系

把它放进同族标准：ERC-5114 与 ERC-5192 是从 721 侧做减法——前者是最简 SBT 徽章思路，后者用 locked 判断锁定态；ERC-4973 干脆换了坐标系，账本以“绑定”而非“持有”为中心。工具兼容性是第一代价：不会读 4973 事件签名的钱包，可能在资产页里干脆不显示这类代币，但它在链上确实存在，unequip 也永远可用。所以排查“我的徽章去哪了”，在浏览器直接按接口标识 0xeb72bb7c 调 balanceOf 比刷新钱包更可靠。另一个易混点是 revoke 语义：标准本身没有独立的撤销函数，收回凭证由项目方合约的自定义逻辑完成，读清每个发放方的规则仍是功课。

使用与核验场景清单

签发方视角：签名发放意味着私钥即发证权，泄露等于批量伪造荣誉，宜用多签或签发服务隔离热密钥；接收方视角：先确认徽章符合 4973 声明（165 探测 0xeb72bb7c），再看 Transfer 事件里有没有你不认识的发放记录，有就按 unequip 处理，链上留一份明确拒绝的记录比沉默更干净。平台视角：把 4973 资产当作可信画像的一部分时，记得它防的是“买来的资历”，防不了“伪造的颁发者”，颁发者的地址身份才是信任源头。凭证类代币同样可能有交易所谓的“价值”，但标准的初衷是资格与声誉，不是可交易资产——评估时别把两者混为一谈。本文只做协议机制科普，不构成投资建议。

从领取到退出的完整生命周期

一枚 4973 代币的一生大致经历四段。第一段是预签发放：颁发方用 EIP-712 结构签好参数，领取者或中继把它上链，give 与 take 让“发”与“领”解耦，代付 Gas 也合规。第二段是展示与核验：服务方读 balanceOf、ownerOf 与 Transfer 事件，确认地址名下的徽章与编号历史。第三段是使用：徽章本身不执行逻辑，判定发生在读取它的合约里——哪枚编号对应什么权益，是项目方自己的映射表。第四段是退出：持有人任何时候 unequip，事件以零地址收尾，历史仍可查但关系已解除。把四段画出来后有个实用结论：某平台声称“撤销了你的成就”，正确姿势不是等它改数据库，而是自己上链看 Transfer 有没有发出——合约侧没有动作的“撤销”只是前端隐藏，你的 unequip 权利始终在线。

颁发者侧的安全分层

发放一枚 4973 徽章看似只是签个名，安全结构其实分四层。最上是政策层：哪些编号对应什么成就、谁有资格触发发放，这部分常在链下工单系统里，权限与日志都要留痕。其下是签名层：预签模式意味着私钥可批量造徽章，热钱包裸奔等于发证权外包给网络攻击面，多签加签发服务分层是现实解。再下是合约层：give、take 的签名校验逻辑是否严格照 712 结构编码，自定义字段会不会造成签名重放，值得一次针对性评审。最下是展示层：钱包不支持 4973 事件签名时，徽章“存在但看不见”，官方文档里写清查询入口与 unequip 路径能挡掉大半客服工单。分层想清楚，颁发者的责任链才不会断在最薄弱的一环。