NFT 版税争论里有一个反复出现的方案：既然拦不住不守规矩的市场，那就由代币合约自己在转账函数里把关——凡是被拉进黑名单的第三方合约，一律不许代表你转移我的藏品。Operator Filter Registry（操作人过滤登记表）就是这个思路的合约实现，OpenSea 曾推动新部署的合集接入，后来又在仓库里把它标记为弃用。这一进一退，恰好是理解”链上黑名单”能力与局限的最好样本。
它解决什么问题
ERC-721 的转账模型里，被批准的操作人（operator）可以代表持有人执行 transferFrom。市场合约是最常见的操作人：挂单成交时由合约完成资产交割。有些市场以零版税或低版税为卖点，藏品从这些市场走一笔，创作者一分钱分成都拿不到。登记表方案的目标很直接：把”哪些合约代码不许代行转账”变成链上可查询的名单，让代币合约在 approve、setApprovalForAll、transferFrom、safeTransferFrom 处调用检查，命中名单就拒绝。仓库自己的表述也留了余地：这不是万无一失的办法，只是让绕开创作者费在大规模交易时更不顺畅。
登记、订阅与复制三种姿势
登记表合约维护两类条目：具体地址，以及代码哈希。地址过滤针对已部署的特定合约；代码哈希过滤更狠，同一段字节码部署出的所有合约一并拦截（外部账户有一个约定的空代码哈希值）。代币合约与登记表的关系有三种建立方式：直接登记后自行维护名单；订阅（subscribe）另一个登记主体的名单，此后对方更新、己方实时生效；或者一次性复制（copy）某名单快照、之后不再跟随。OperatorFilterer 这个供代币合约继承的抽象组件，在构造函数里就接受”订阅或复制谁、是否订阅”两个参数；官方提醒，如果合约不提供 EIP-173 的 owner，订阅关系在部署后就锁死在构造时选定的选项上。名单条目随时可增删，订阅关系随时可取消。
曾经被拦的是谁
OpenSea 维护的默认名单里，早期条目包括 Blur 的执行代理合约、LooksRare 的两个转账管理器（ERC-721 与 ERC-1155）、SudoSwap 的路由器——都是主打免版税或低费策略的市场。规则写在 README 里：入选标准是”该应用让用户在同笔交易本应支付创作者费的场景下绕过费用”，或使用包装合约规避链上版税强制执行。部署了登记表但没有注册前，检查不生效；登记表本身没部署的网络上，继承组件也不会让交易失败——这些边界决定了”接了过滤器”和”真的拦得住”是两回事。
从强制到弃用
2022 年底到 2023 年初，OpenSea 曾要求新发布合约必须带操作人过滤才有资格获得费用强制执行，期限还延过一次；随后又追加了必须实现 ERC-2981 版税声明的要求。而现在的仓库 README 第一行是：本项目已被弃用，详情见 OpenSea 创作者费用更新的博文。名单不再被强制，链上代码仍在——已接入的合集不会自动解除过滤，取消订阅或清空名单需要合约管理员动手。
给买家的三条实用判断
第一，看过滤现状而不是宣传口径：一枚藏品的合约是否继承了 OperatorFilterer、当前订阅着谁的名单，决定了你能在哪些市场把它低价卖掉；被严格过滤的藏品，换市场卖可能多花一步”解绑”操作。第二，管理员权限要盯住：谁能改名单，等于谁能决定这件资产的流通渠道。第三，别把过滤器当成版税问题的终极答案——它拦的是名单上的合约，链下议价、场外成交、名单外的新市场，它都管不着。这套机制的价值与天花板，到这里就都说清了。
对想核实现状的读者，登记表的设计是透明可查的：注册关系、订阅关系与名单条目都是链上状态，任何人都能查询任意合集对特定市场合约的过滤结果，判断自己准备挂单的市场会不会被这件藏品拒收。这类”先看链上再听宣传”的核法，适用于所有号称强制执行版税的项目——名单在不在、订阅挂给谁、管理员是谁，三个问题在任何区块浏览器上五分钟能问完，比项目方的 FAQ 诚实得多。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。