ERC-7589 半同质化代币角色：把一张多人权益卡拆成可撤销的座位

合买一张季票、拼一间会员包厢，难点从来不是“能不能分”，而是“散了怎么办”。ERC-7432 给单枚 ERC-721 设计过角色系统，ERC-7589 则把同样的思路落到 ERC-1155 这类半同质化代币上：持有一叠可互换的份额，同时把“谁能用什么权益、用到什么时候”做成链上可查的角色。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该提案状态为 Draft，依赖 ERC-1155 与 ERC-165。

先建承诺，再发角色

流程分两步。第一步 commitTokens(grantor, tokenAddress, tokenId, tokenAmount)：授权人把若干份额质押进系统，换回一个全局唯一的 commitmentId，此后 grantorOf、tokenAddressOf、tokenIdOf、tokenAmountOf 四个查询函数把这枚承诺牌的底细全部摊开——谁质押的、质押了哪种代币多少份。第二步 grantRole(commitmentId, role, grantee, expirationDate, revocable, data)：以承诺牌为锚，给具体地址发一个 bytes32 标识的角色，随附到期时间戳、是否可撤销与自定义数据。TokensCommitted、RoleGranted、RoleRevoked、TokensReleased 四组事件把每次建立、授予、收回、释放记成可索引的流水。

角色到期由 roleExpirationDate 自动失效，无需链上收租动作；isRoleRevocable 让每个角色自带“能不能提前收回”的声明；想整个撤掉，用 revokeRole；权益用完想拿回质押份额，用 releaseTokens。批量操作还有可选扩展接口，把质押和授权合成一步。

和租赁、灵魂绑定的位置感

三件套之外的第四个问题

评估一套 ERC-7589 实现时，除了接口齐不齐，更要问“角色到底是什么”。规范里的 role 是 32 字节的任意标识，data 是任意字节，合约层面对内容零假设：同一个 bytes32 在不同项目里含义完全不同。因此核验重心必须落在解释层——发行方有没有公开角色字典、角色数据指向的链下权益是否有独立可验证的兑现机制、到期时间用的是区块时间戳还是预言机时钟。承诺牌本身也有生命周期陷阱：如果质押合约被管理员暂停，角色查询一切正常，但底层份额既退不出也用不了，这类“上游锁死、下游空转”正是 7589 场景里最需要事前压力测试的链路。

与 ERC-7432 的分工再确认

同一家族里 ERC-7432 已覆盖“单枚 NFT 的角色”，7589 的存在理由是把角色做到 ERC-1155 的“份额”维度：一个 commitment 可以对应数量大于一的质押份额，角色在共享池里发放，份额归还走统一的 releaseTokens。两者接口形状神似、事件字段相近，钱包适配时最省事的策略是探测接口标识后按标准分流，而不是看名字猜语义。对普通用户，识别方法就是看权益载体标准：持仓页显示“1 枚唯一代币”多为 7432 世界，显示“拥有 12/100 份”则多半走在 7589 的承诺模型上。

原子性的隐性红利

流程还有个隐性优点：从质押到发角色到释放，每一步都由单个合约内部的记账完成，没有跨合约的中间态，用户不必担心“份额已质押但角色没发出去”这类半套状态；任何一步失败都原子回退，最多损失一次模拟与 Gas。工程接入还需注意接口的批量扩展：一次交易同时质押并给多个地址发角色，签名前逐条核对到期时间列表，避免批量里混入一条过长有效期。

对使用者，这套机制值得和两组邻居对比：ERC-4907 的租赁是“整枚代币临时使用权易手”，ERC-7589 则是“资产不动，权益切片分发”；与灵魂绑定徽章相比，它又刻意保留了到期与撤销，定位更接近会员席位而不是身份标签。风险侧要盯三处：承诺合约由谁部署、能否被管理员冻结质押物；角色数据字段里链接的链下权益是否可持续兑现；以及撤销条款是否偏向发行方。提案仍是 Draft，字段细节以仓库正文为准。本文为协议机制科普，不构成任何投资建议；标准状态以 ethereum/ERCs 仓库文本为准（核验时间 2026 年 9 月 9 日）。