质押中的 NFT 还算谁的？ERC-7531 的权利持有人登记

把一个没有锁定功能的早期 NFT 质押进池子，第一步就是 transferFrom——代币名分整个转进质押合约。麻烦随之而来：原产项目的白名单、空投、线下会员活动大多按 ownerOf 认人，质押中的头像瞬间“查无此人”。ERC-7531 的方案不动代币本体，只在旁边立一本权利簿：谁在行使权利，链上留名。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该标准状态为 Review，2023 年 10 月 1 日创建，依赖 ERC-165 与 ERC-721。

一条事件拆开两种身份

接口的心脏是一个事件：RightsHolderChange(tokenAddress, tokenId, holder, right)。触发条件是“持有代币的合约地址”与“实际权利人”不一致——质押场景里前者是质押合约，后者是你的钱包。right 用四字节标识权利类型，标准给了两个初始值：0x399d2b36 对应 ownership（所有权权益），0x230a5961 对应 usage（使用权），例如出租给玩家打游戏的 NFT，使用权在租客、名分在出租合约，两者分列。未来要加新权利类型也不破坏兼容。对应的查询函数 rightsHolder 对不存在或当前无主的代币必须回滚。

监听方的两条铁律

事件不是免检的，规范文本给了两条验证规则。其一，权利事件必须与 Transfer 事件同块或后续块发出；一旦后来又有 Transfer 动了同一枚代币，此前的权利登记即被取代——名分都转走了，旧权利簿自然翻篇。其二，监听方必须核对：发事件的合约地址，是否正好等于该代币此刻 ownerOf 的答案。不查这一条，任何合约都能发一条伪造事件“宣布”权利归属，把白名单骗到手。这两条把“谁有资格写权利簿”钉死在真正持有代币的合约上。与之配套的是查询函数 rightsHolderOf(tokenAddress, tokenId, right)，传入藏品合约地址、代币编号与权利类型，返回权利人地址；代币不存在或当前无人持有时必须回滚。

适合谁，不适合谁

标准自己的动机说得很直白：面向 CryptoPunks、BAYC、EtherRocks 这类当年没写锁定功能的古董级藏品——新合约可以要求实现可锁定扩展再质押，老藏品只能在“转出”与“不质押”之间二选一。对原生支持锁定或已有授权赎回机制的集合，这套登记并非必需，反而多一层状态。也要看清能力边界：ERC-7531 不创建锁，也不阻止你仍然把代币转出，它只是给转出后的权利归属加了一条标准问句。白名单系统、空投快照、链上会员要不要认这本权利簿，取决于对方是否支持或愿意读它；一个从不使用标准的集合不会因为合约部署了 ERC-7531 就自动把质押者算进快照。

持有人怎么用

一次快照季的自查脚本

空投与白名单的季节，这份权利簿就是你的申诉底账。按顺序过一遍：先调 ownerOf 确认名分此刻在质押合约——这是 RightsHolderChange 成立的前提；再按 tokenAddress 与 tokenId 过滤权利事件，确认存在指向你地址的 ownership 记录，且发出方地址与该合约地址吻合，此后没有更新的 Transfer 覆盖它；发现事件缺失或发事件地址对不上，先向质押平台报告，再把它当红旗。若平台声称“支持权益保留”却读不懂这些事件，支持二字只是文案。同时要校准预期：登记只提高你“被正确识别”的概率，不改变资产状态——质押合约被黑时，权利簿救不了代币，它只在识别层面起作用；想减少损失，回到质押协议本身的审计与透明度，那是另一个话题的另一课。

质押前先确认质押合约是否部署了这套接口并会在同块发事件，否则“支持 ERC-7531”只是宣传语；质押后到权利登记里查自己那枚代币的 holder 记录是否指向自己、权利字段是不是预期值。出租场景另有一层：使用权交给租客后，你名下的 ownership 记录应保持不动，游戏权益按 usage 字段走，纠纷时两者都是可举证的链上记录。本文为协议机制科普，不构成任何投资建议；标准状态以 ethereum/ERCs 仓库文本为准（核验时间 2026 年 9 月 9 日）。