ERC-7652 保证扩展：NFT 的“随时换币”承诺怎么写进合约

“买我的 NFT，随时按保证价换回代币”——这句话写在白皮书里是情怀，写进合约才是结构。ERC-7652 就是给这类承诺准备的接口：为 ERC-721 引入“担保人”角色，持有人为指定代币设定保证份额与保证价值，之后可按约定把 NFT 换回流通代币，围绕这笔保证还会派生保证利息的分配与保证义务的履行。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该标准状态为 Draft，2024 年 3 月 10 日创建，依赖 ERC-165 与 ERC-721。

接口骨架：设定、查询、履行

功能面分三层。设定层让用户读或设某个代币编号当前的保证价值与保证份额；查询层给出保证参数、应付或应得的利息数额；履行层完成两笔方向相反的动作——持有人交回 NFT 拿代币，或担保方按约定收回利息与执行义务。每次状态变化都有标准事件兜底。与 NFT 借贷类标准的区别在视角：ERC-7595 是“我押住它去借钱”，债务到期才有清算；ERC-7652 更像“它自带一个回售权”，持有人可以随时行使。

谁来兜底，才是问题核心

一份回售承诺的含金量等于担保资金的充裕度。读这类合约的正确顺序不是看保证价多高，而是先确认：担保资金池地址是哪个、余额多少、被谁管理、有无提款延迟与优先级条款；保证份额的总量有没有铸造上限，会不会被不断追加的担保代币稀释；保证利息的资金来源是投资利差、版税收入还是空气。规范文本给出了接口，但担保人的偿付能力从来不由接口保证——这与 RWA 项目里“发行人兜底”话术的核验逻辑一模一样：结构可见，偿付看资金。

三个常见误读

第一，“可随时换回”不等于“按市价换回”。保证价值是设定时写死的参数，市场暴跌时保证价高于市价，池子会被挤兑；市场暴涨时保证价形同虚设，人人宁可去二级市场卖。两种情形都是这类结构的天然压力测试。第二，保证不等于保险：保险有第三方核保与理赔条款，保证只是同一批合约里的一个函数，担保资金被挪用或亏光时没有任何外部赔付。第三，把“保证收益”当卖点的项目尤其要警惕——保证的对象应当只是“按约定价格换回代币”，任何叠加“年化多少”的宣传都偏离了标准设计初衷，甚至滑向收益承诺的灰色地带。

持有人核验清单

三种市场局面下的保证价

把保证价值放进三种行情里推演一遍，结构缺陷自然浮现。行情平淡时，保证换回与二级出售价格接近，持有人按习惯走市场，保证函数几乎不被调用，合约安静运转。价格崩落时，保证价高于市价，理性持有人集体行使回售权，池子按先到先得顺序排水，越晚排队的人面对越薄的余额——此时“随时可兑”的体验完全取决于排队规则与池深，而不是保证数字本身。价格狂飙时反向失血：无人回售，保证显得无害，但项目方若指望靠低保证价锁定用户流动性，市场会用脚投票。三种局面的共同结论是：保证价值参数不重要，池子深度与提取规则才重要。读合约时优先找三样东西——担保资金的存放地址、每区块或每笔的回售上限、担保池余额不足时履行函数 FulfillGuaranteeTransfer 的回滚行为，比盯任何“保底”文案都接近真相；设定与查询保证参数则围绕 setNFTGuarantedInfo 与 establishNFTGuarantee 这组函数展开，权限归属逐一读源码。

先看源码确认 guaranteeValue、份额设置函数的实际调用权限；再用 eth_call 或浏览器直读担保池余额与最近 30 天出入流水；然后核对保证换回的滑点与排队机制（有没有每区块上限、有没有先兑先得）；最后确认行使回售的那笔交易怎么签——需要 NFT 授权的正常流程是 approve 到本合约，凡是要求签“授权任意合约转出资产”的页面直接远离。本文为协议机制科普，不构成任何投资建议，不构成对任何兑付能力的判断；标准状态以 ethereum/ERCs 仓库文本为准（核验时间 2026 年 9 月 9 日）。