链上一键提货：ERC-5560 把 NFT 兑换实物写成标准动作

“持有这张 NFT 可以兑换一件实体版画”——这类承诺在实体锚定藏品、音乐专辑特典、赛事纪念品里越来越常见。问题在于，绝大多数项目的“兑换”是一段帮助中心文字加一张客服表单，链上没有任何痕迹，你甚至无法分辨客服说“已经给您核销”到底动了什么。ERC-5560（2022 年 8 月 30 日创建，提案文档现状为 Stagnant）想给这件事补一个最小组件：让“可兑换”成为 NFT 的一种标准状态，让“已兑换”成为一条可查询的链上记录。

两个函数、一个事件

标准的正文短得罕见。它给 ERC-721 合约加一个 redeem(tokenId) 函数和一个 isRedeemable(tokenId) 查询：前者触发核销，后者告诉任何人这枚 NFT 现在处于“还能兑换”还是“已经兑换过”的状态。合约部署后默认所有代币 isRedeemable 返回真；一旦 redeem 被调用，状态翻成假，同时广播 Redeem(from, tokenId) 事件，第三方的索引器可以像追踪转账一样追踪核销。还有一个容易被跳过的安全细节：标准写法里 redeem 默认可被任何人调用，官方给出的建议实现是用一条 require 检查调用者确实是代币持有人——也就是说，接口本身不自动管权限，项目方必须自己把“谁能核销”这道锁装上，标准文本明确把设定兑换资格的责任划给发行方。ERC-165 的标识号在文中写作 0x2f8ca953。

链上状态与快递单是两本账

这套机制最大的价值是消灭一种扯皮：用户赎回后转卖，接盘者却以为还能再兑一件实物——isRedeemable 一查便知。但反过来，它给不了的东西更多，必须掰开说清。第一，redeem 调用成功不等于实物发货，物流、清关、质量、售后全部在合约之外，链上状态与快递单是平行记账的两套系统。第二，谁有资格调用 redeem、地址改了怎么办、兑换窗口有没有截止，标准统统不管，答案藏在项目自己的条款里。第三，也是最大的一个：一个项目实现 5560 只能说明它的核销动作有了可追踪的格式，不能证明兑换承诺本身会兑现——实现标准成本极低，履行承诺能力才是难的。顺带给两个近邻定位：ERC-5791 走芯片签名路线，让 NFT 所有权自动跟着实物走；ERC-7578 给提货说明书建了结构；5560 处在光谱最轻的那一端，只有一个状态灯。

下单前后的动作清单

看到“实物兑换 NFT”时，先探测合约是否对 0x2f8ca953 返回真，确认标准是真实现的而不是宣传图上的；再对目标代币跑一次 isRedeemable，二手交易里这一步等价于“确认这张券还没被用过”；赎回操作完成后，自己留存 Redeem 事件所在交易的哈希，作为链上核销时刻的证据。如果对方要求你先去一个陌生网页“验证持有”再引导签名，标准流程里根本没有这一步，那更接近钓鱼脚本的剧本，应立即停手核查域名。本文解释的是一种接口形态与对应的核验方法，实物交易的真实性、合法性由发行方条款决定，也不构成任何买卖建议。

两次转手之间的核验时间线

把一张“实物兑换 NFT”放进完整交易生命周期看，每个节点各有一个对应动作。买入前：查 isRedeemable 为真，读 Redeem 事件历史确认该编号从未被核销，确认项目条款写清兑换资格是否随转手延续——有些项目规定首任持有人才有提货权，这类条款会把二手买家的权益直接归零，比任何链上状态都优先。持有时：定期复查状态，异常地从真变假说明有第三方触发过核销，需要立刻向发行方与合约权限方求证。卖出时：把 isRedeemable 查询结果连同交易哈希发给买家，这是零成本但最难伪造的凭证。赎回时：redeem 交易确认后再查一次状态为假，并第一时间启动条款约定的实物流程，保留链下沟通记录。把这条时间线立起来之后，5560 提供的两个函数与一条事件就不再是抽象接口，而是每个节点上可执行的自检点——标准的全部价值都在于此，它让“我有没有兑换资格”从客服的口述变成任何人都能独立跑一次的问题。