NFT 质押之后链上算谁的：ERC-4987 的 heldOwnerOf 问的是另一个人

链上有两枚一模一样的藏品：A 放在自己钱包里，B 质押进了某个游戏金库。把它们逐枚对比，结果会让人困惑——两笔 ownerOf 查询一条返回个人地址、另一条返回金库合约地址。更微妙的是，链上有一类靠“你持有多少”行事的系统：治理投票、展览资格、会员权益、PFP 验证。金库地址不会投票，也不会亮头像，于是质押参与者陷入两难：交了押品就失去原有权益，不交又错过协议收益。ERC-4987（2021 年 9 月 21 日创建，提案文档现状为 Stagnant）给出的解法不是把代币留在原主手里，而是让金库合约自己开口回答“这枚币的功能性主人是谁”。

被持有代币与它的一问两答

标准把“被某个合约持有的代币”定义成 held token，然后为 20、721、1155 三条线各配了一套查询接口。以 721 版本为例，核心只有两个函数：heldOwnerOf(tokenAddress, tokenId) 从合约持管的某枚具体代币反查功能性所有人；heldBalanceOf(tokenAddress, owner) 正查某个人在这个合约名下押着多少。配套的是两个事件：代币进合约时广播 Hold，退还时广播 Release，金库与用户之间的每一次 custody 变动都有链上留痕。接口识别同样走 ERC-165 探测，721 版本的标识符在标准文本里写明为 0x16b900ff。整个设计刻意做轻：它不碰质押规则、不碰清算逻辑，只负责把“账面持有”和“功能所有”这两层关系说清楚。

谁该实现，谁在使用

标准文本把生态位列得很清楚。实现方是把币收进合约的那一类：质押与挖矿合约、借贷池、时间锁与归属金库、碎片化 NFT 合约、智能合约钱包。消费方是靠持仓行事的系统：治理、游戏、PFP 验证、画廊与展示厅、会员计划。理想的画面是，用户一边把藏品押进金库赚积分，一边仍然能在治理投票里被数到一票。反过来说，这套接口解决不了的事情同样明确：它只是登记与查询层，退押条件、罚没规则、平台运营状态依旧归质押协议自己管；一个 bug 缠身的金库不会因为实现了 4987 就变得更可信任。

读者视角的三查

下次看到“质押你的 NFT 并保留权益”的宣传，可以用三步落地：第一，去代币合约或金库合约的字节码声明里查它是否实现 4987 的 165 标识，没有实现意味着治理与展示系统大概率把你从统计里漏掉；第二，用 heldOwnerOf 实测一枚自己的押品，看反查是否灵敏，别信页面文案；第三，回看 Hold 与 Release 事件历史，确认进出记录与自己记得的操作对得上。顺带说明坐标，避免混淆：ERC-4353 之类提案是在代币合约一侧加质押余额查询，而 4987 站在持有合约一侧回答所有权问题，方向正好相反；两者都还远谈不上普及。本文只做机制介绍，不构成任何质押或买卖建议，参与任何锁仓前请自行评估协议与合约风险。

一个容易被忽略的信任缺口

把 4987 想成“自动公平”是误读：heldOwnerOf 的回答完全由金库合约的代码给出，而这份标准只规定回答的形状，不规定回答的正确性。一个恶意或有缺陷的合约完全可以对所有人都返回同一个地址，或者在退出事件上做手脚。所以规范的用法是把 4987 当交叉验证工具而不是唯一信源：Hold 事件里登记的存入交易哈希，应该能在代币合约那边找到对应的真实转入；Release 事件出现后，去代币合约核对 ownerOf 是否已回到你的地址。两边能对上，登记层才可信。还要说清一个高频疑问：在多数质押结构里，代币进入金库时发生了真实转账，代币合约的 Transfer 事件照常广播，浏览器的转账历史会显示“你转给金库一枚币”——这不是资产丢失的信号，而是此类质押的实现方式，4987 存在的意义恰恰是给这类正常但易被误读的记录补一层语义。