ERC-6147 Guard 是什么？把 NFT 的持有权和转让权分开锁

一个被忽略的问题：钱包里的 NFT 谁说了算

在标准 ERC-721 里，一枚 NFT 的权利几乎全部押在持有人地址上：owner 能转、能授权，被授权的操作员也能转。这个模型简单，但遇到租赁、质押、代管这类场景就麻烦了——租赁方希望租客期间只有自己能操作转让，出租方又担心对方卷币跑路。ERC-6147 的思路是在合约里加一个新角色：guard（看门人），并且给它配一个到期时间 expires。guard 生效期间，转让权被收走到 guard 手里；到期之后，权利自动回到 owner。这份标准在 ERC 仓库中的状态是 Final，2022 年 12 月 7 日创建，依赖 ERC-165 与 ERC-721。

规则其实只有四条

按规范文本，行为可以压缩成四句话。第一，当一枚 NFT 没有有效 guard 时，owner、被授权操作员和被批准地址都可以设置 guard 和到期时间。第二，一旦 guard 生效，这三类地址都不能再改 guard 或到期时间，也不能转让这枚 NFT——规范特别强调，即使市场通过 setApprovalForAll 拿到了授权，也带不走带 guard 的藏品。第三，guard 本人可以解除自己的角色、改期或直接转让。第四，查询接口 guardInfo 会返回 guard 地址与到期时间戳，零地址表示当前没有 guard。

实现层面，参考实现用一张 tokenId 到 GuardInfo 结构体的映射，里面存 guard 地址和一个 64 位无符号整数 expires（UNIX 时间戳）。changeGuard 要求新到期时间必须晚于当前区块时间；transferAndRemove 则把转账和解除 guard 打包成一个动作，方便租赁到期归还。销毁代币时 guard 记录一并删除。

它和 ERC-6454 那类锁定有什么不一样

锁定类扩展（例如 ERC-6454）回答的是“这枚代币现在能不能动”，动作开关在持有者一侧；guard 回答的是“现在谁有权动”，权利被整体移交到一个带时限的第三方地址。这个差别让 guard 天然适合表达“一段时间内由别人代管”的关系：租约、分期购买中的卖方保留、会议 SBT 的组织方回收权，都可以直接映射。同时规范也建议市场端在列单前检查 guardInfo，避免把带 guard 的藏品错误地挂出来却无法交割。

普通持有者要核对什么

如果你买入或收到的 NFT 声明支持 ERC-6147，值得逐项确认。先在合约页面调用 guardInfo 看当前 guard 是谁、什么时候到期；guard 是合约地址时，去读它的源码或项目说明，因为规范允许把 guard 设成第三方协议合约，功能都藏在那段代码里。其次确认自己签过的每一笔 changeGuard：guard 一旦生效，在到期之前 owner 无权反悔。最后，警惕任何要求你先“设置 guard 到某个地址”的空投或客服话术——这等价于把转让权交出去。

风险边界

guard 机制改变的是合约内的权利分配，不改变作品版权，也不保证任何收益。guard 合约本身若有漏洞或被恶意部署，反而会成为单点风险；到期时间设得太长，会让资产在约定之外被锁住。租赁、代管类产品请以项目条款与合约代码为准，链上字段只是权利声明的一部分。本文内容为机制科普，不构成任何投资建议或买卖时机判断。

规范愿景里的三种标准用法

规范正文列了 guard 机制支持的场景，逐条读来对应着三种信任梯度。防盗最轻：guard 设为自己控制的冷地址或监控地址、到期时间拉远，热钱包被盗时藏品转不走，解冻却只需要一条持有人路径，这等于把保险丝装在了钱包之外。借贷与租赁深一层：把 guard 设为协议合约、到期时间随借期或租约走，合约代码执行到期归还是还币解押，借款人或租客在期限内无法转走——此时 hold 与 transfer 的分离才真正发挥了作用。SBT 场景最极端：发行方把 guard 统一设为指定地址，凭证变成灵魂绑定加可回收的组合体，不可转世却又并非不能撤销。ERC-165 探测接口让市场可以机械核验合约是否实现了这套扩展，声称支持 guard 的市场应当查得到 supportsInterface 的肯定答复。但别忘了三种用法的共同前提：把转让权交给 guard 之后，你在期限内除了持证什么都做不了，guard 合约自身就成了新的故障点，读它的源码属于必修课而不是可选项。