ERC-5633：同一个 1155 合约里，哪几种灵魂绑定哪几种自由流通

“灵魂绑定”这个词被用得很宽：有人指整份合约都不可转让的凭证，有人指某张卡、某件装备不能卖。现实里的游戏和会员系统往往两种都要——成就徽章终身跟人，普通道具却可以交易。把它们塞进两个合约当然可行，可 ERC-5633（2022 年 9 月 9 日创建，现状为 Stagnant）想解决得更精细：在同一个 ERC-1155 合约内，让灵魂绑定属性按代币类型逐类成立。

一个查询函数管住所有转账

标准的接口只有一问一答加一个事件：isSoulbound(uint256 id) 对某个代币类型返回真假，Soulbound(id, bounded) 事件记录属性的设定。规则写得干脆：一旦某类代币被标记为 soulbound，合约里所有把它从一个账户转到另一个账户的 ERC-1155 函数都必须执行失败，唯一的例外是铸造与销毁。钱包与合约实现方通过 ERC-165 查询该扩展是否启用，接口标识符为 0x911ec470。这套设计的妙处在于“预判”：转账发起前，工具就能对每一类代币先问一句，是绑定的就别提交那笔注定失败的交易，省 Gas 也省心。

与相邻几个标准的边界

不可转让资产的标准谱系容易混。ERC-5192 面向 ERC-721，用 locked 查询单枚代币当前是否处于锁定态，锁定可以解除；ERC-5516 解决一枚 721 多个持有人的共享问题；Solana 的 Token-2022 用 NonTransferable 扩展把不可转让做进资产本身。ERC-5633 的位置是 ERC-1155 加“类型级”属性：不问某一枚，而问某一类；也不提供解锁接口，属性更偏出厂设定。读合约时可以把两条线分开核——查 721 的锁定看 5192 的 locked，查 1155 的绑定看 5633 的 isSoulbound，两边都没实现的项目，其“绑定”多半只是自定义函数加事件约定，兼容性要靠项目文档自证。

实用清单与风险提示

对个人用户，这份标准带来的是更便宜的核验：在任何 1155 合约里发现想转的资产，先调 isSoulbound，返回真就不要再试转账，也不要在客服群里问“为什么转不动”；发现某类道具属性被 Soulbound 事件中途改写过，说明合约属主拥有改规则的权柄，这类项目把“可否转让”变成了可被运营干预的状态，购买前值得多一层警惕。对开发者的另一面也要知道：标准本身是 Stagnant 状态，采用有限，钱包支持参差，集成时既要在 165 上如实声明，也要为不识别该属性的旧工具留好 revert 提示。资产能否转让是持有体验的一部分，但“可转让”不等于“卖得掉”，流动性从来不由接口决定。本文只做协议机制科普，不构成投资建议。

一个查询串起钱包端体验

设想钱包资产页收到一批 1155 条目，界面右上角的“可转让性”标签从何而来？理想链路是：先对合约调一次 supportsInterface 确认 5633 声明，再对每一类代币批量跑 isSoulbound，真值打上锁定图标，假值挂上交易按钮，用户的转账入口只在安全的那一侧出现。没有这条链路时，钱包只能对全部条目一视同仁，用户对着绑定资产发起注定失败的转账，白白烧掉 Gas 还容易误以为钱包故障。对开发者，落地 5633 的自检清单同样清晰：合约部署后先查 165 返回值，再用测试地址确认 Soulbound 事件按设计发出，最后在主流转账工具里走一遍被拒路径，确认回退提示指向“该类型已灵魂绑定”而不是含糊的通用报错。标准是死的，体验是活的——一个查询函数能不能变成用户眼前的确定性，取决于钱包端有没有把它接进决策链。

属性改写在治理上意味着什么

前文提到 Soulbound 事件可以中途改写某类代币的绑定属性，这一点值得单独展开。一个合规实现的 5633 合约里，该函数的调用权限与策略完全由项目自定：可能锁死后不可改，也可能留给属主随时翻转。两种设计对应两种信任叙事——不可改是“出厂承诺”，可改是“运营裁量”。对收藏者，差异会在市场里显性定价：绑定可能被随时加上的资产，其流动性折扣几乎必然存在，理性的买家会先读源码里的权限修饰符再出价。对协议研究者，这也是观察标准与治理分层的好样本：5633 规定“怎么问”，不规定“谁有权答”，把权力结构留给项目自己声明；于是同一接口可以跑出完全不同的经济行为，读标准永远只是尽调的起点而非终点。