半灵魂绑定代币：ERC-5727 的槽位、签发与撤销

灵魂绑定代币常被概括成”不能转的 NFT”，但现实凭证往往更别扭：一份会员资格可能有二百份完全相同、每人拿几份不等；一张证书今天有效、明天被吊销；持有人失能后需要指定恢复人接管。状态为 Draft 的 ERC-5727（2022 年 9 月创建）把这些需求整合成半灵魂绑定代币（SFST）：不可转让，但可分份、可撤销、可验证。

槽位账本与角色分工

ERC-5727 把持有结构从”编号到余额”升级为槽位（slot）体系：同一类凭证占同一槽，slotCountOfOwner 数一个名下的槽位数、slotOfOwnerByIndex 枚举槽编号、ownerBalanceInSlot 查单槽数量——同一地址在同一槽可以有多份，像同一本书存四本库存。发行侧 issue 由发行方（issuer）调用，携带目标地址、槽号、销毁权限（burnAuth，声明销毁权归发行方或接收方）、验证人（verifier）地址与数据；revoke 让发行方吊销某编号，verify 供任何工具当场核验有效性。issuerOf 与 verifierOf 把两个角色写进合约：签发把凭证放进你名下，验证负责回答”它还作数吗”，二者可分属不同机构，比”谁发谁说了算”的传统更接近现实公证结构。扩展件同样成体系：Delegate 扩展授权操作者代发或管理某槽，Recovery 扩展让持有人预设新地址、由签发方按流程把凭证转移过去，给”钥匙丢了就永远失去资格”的 SBT 叙事打了务实补丁；Approval 扩展用提案表决处理敏感操作。

场景、短板与核对清单

为什么凭证类标准值得普通读者多花十分钟

收藏者习惯问值多少，凭证类资产逼你换一套问题：谁签的、还能信吗、我能拿它做什么。ERC-5727 这类标准的真正贡献，是把后三个问题做成链上可查询的字段，让生态对凭证的想象力从图片升级到流程——签发、验证、委托、恢复，每一步都有事件可回放，每一次吊销都留下公开记录。对你我的实际生活，学历、资质、会员、访问权的链上化已经零星发生，只是大多藏在机构后台。等它们浮出水面时，会敲这些接口问问题的人会占尽先机：链上凭证的黄金时代来临那天，读懂槽位与销毁权限的人不需要重新学任何东西。

最贴身的场景是机构凭证：学历、资质、合规会员、通行证——一人多份、可吊销、偶发需要恢复，套 721 或朴素 SBT 都要打补丁，进槽位模型却自然。它停在 Draft 也缘于此：每类机构对”谁能吊销、恢复按什么程序”的期待完全不同，接口统一得了查询动作，统一不了治理语义，生态迟迟没有公认模板。读者的核对清单顺着接口列成五问：签发人是谁（issuerOf）、验证人是谁（verifierOf）、当前有效吗（verify）、我名下有几份（槽位三连查）、销毁权挂在谁手里（burnAuth）。无论目标凭证是否实现该标准，这五问都成立。反面也要记住：链上 verify 通过只说明”这台机器认它”，签发机构官网、注册处与链上账目三方一致才算闭环；吊销事件的历史频率值得回看，今天有效不预示明天有效。凭证系统强度等于最弱一环，链上化只是把环公开出来让人检查——这是全部承诺，也足够有用。把清单落到更低门槛的场景同样好用：一枚链上活动徽章，先查签发地址是不是项目方公布的官方地址，再查它有没有吊销记录——两个问题都能在区块浏览器里用鼠标点完，答案足以过滤掉大部分限定发放话术的水分。更细的工程注脚还有两处：槽位设计让批量吊销可以按槽执行，机构整改一类凭证时不必逐枚发交易；而验证人与发行人的分离，意味着一个合规争议最坏情况下也只是让 verify 翻脸，凭证本体仍安静躺在你名下——状态的脆弱与所有权的稳固被拆成两层，这正是它比朴素 SBT 叙事更诚实的地方。本文只做协议机制科普，不构成投资建议。