ERC-7432 NFT Roles 是什么：不转移藏品，怎么把使用权分给别人

一个常见需求：东西还是我的，但你可以用

很多人手里有“带功能”的 NFT：会员凭证、数字房产、活动通行证、可以领取空投的资格凭证。持有者有时想把部分功能借给别人，却不想把代币转出去。ERC-7432 就是针对这个需求提出的“NFT 角色”标准，它在以太坊改进提案仓库中已被标记为 Final（最终）状态。

它的思路不是把 NFT 转给借用者，而是在链上登记一条“某地址对某枚 NFT 拥有某角色”的记录。所有权仍然在原来的持有人手里，被授权人以“角色”的身份获得特定操作许可。

一条角色记录里有什么

按照规范，每次角色授权对应一个结构体，核心字段包括：

• roleId：角色标识，是一个 bytes32 值，通常由角色名称做哈希得到，例如对 keccak256("PropertyManager()") 这样的字符串取哈希。同一个 NFT 下不同的 roleId 代表不同角色。
• tokenAddress 和 tokenId：指明这条角色挂在哪个合约的哪一枚代币上。
• recipient：被授予角色的地址。
• expirationDate：到期时间戳，到点后角色自动失效，不需要谁再发一笔撤销交易。
• revocable：布尔值，标记这个角色在到期前是否可以被撤销。如果授权时设为不可撤销，在到期前原持有人也无法单方面收回，这一点和直觉相反，务必看清楚。
• data：任意字节数据，留给项目方自定义，例如写入额度、层级编号等。

规范还定义了 TokenLocked、RoleGranted、RoleRevoked、RoleUpdated 等事件，以及查询角色数量、角色详情的视图函数。应用可以先锁定（存入或冻结）NFT，再往外发放角色，也可以只做角色登记而不动代币，具体取决于实现。

和所有权转移、租赁有什么不同

三种安排解决的是不同问题：

1. 转移所有权：代币真的换持有人，ownerOf 的结果改变。之前的授权和挂单都要重新处理。
2. 独占租赁（例如 ERC-4907 的思路）：一段时间内只有承租人能用，到期回到出租人手里，同一时刻通常只有一个用户。
3. 角色授权（ERC-7432）：可以一次给多个地址发不同角色，各角色有自己的到期日和自定义数据，持有人不动代币。

用数字房产举例：业主可以给自己保留“管理者”角色，给物业发一个“物业管理者”角色，给几位租客各发一个带房间编号的“租户”角色。每个人的权限边界由 roleId 和 data 描述，到期自动失效。

要警惕的边界

角色标准解决的只是“链上记录谁能做什么”。它不保证：

• 现实世界的合同效力。链上角色不等于法律文件里的租赁或服务协议。
• 所有应用都认识角色。角色只有被具体的 dApp 读取并执行时才有效果；很多市场和应用根本不查询这个接口。
• 权限一定合理。roleId 对应什么实际功能，完全由项目方自己定义，需要读项目文档确认。

把角色机制放回整个“使用权工程”的版图看会更清楚：ERC-4907 和 ERC-7507 处理的是独占使用人和多订阅者的时间问题，ERC-6220 的槽位处理的是装备组合，ERC-7432 处理的是“谁在什么条件下能执行哪类操作”。它们都共享同一个前提——代币不动，功能先动。理解这一点后，遇到任何“借出功能不卖币”的产品，你都可以先问：它用的是哪一层记录？记录里有没有到期时间？撤销权在谁手上？三个问题问完，机制画像基本就出来了。

检查一份角色授权时，值得逐项核对：角色挂在哪个合约、哪个 tokenId、到期时间、是否可撤销、以及项目文档里这个角色到底能做什么。对操作者来说还有一条实用提醒：授权交易发出后，链上事件 RoleGranted 会完整记录这些要素，撤销时对应 RoleRevoked，两件事都能在区块浏览器里按地址检索到；如果应用宣称发了角色却查不到对应事件，这个“授权”大概率只存在于客服截图里。

风险提示：NFT 及相关授权机制存在智能合约漏洞、规则理解偏差等风险，本文仅作机制说明，不构成任何投资建议或操作建议。