一张 NFT 多次核销：ERC-6672 用操作方和 redemptionId 记账

一张演唱会门票 NFT，进场时核销一次，纪念周边摊位再核销一次，线上回放又核销一次——传统 ERC-721 没有地方记录“哪些权益已经用过、被谁用掉”。ERC-6672 就是补这块的：它在 ethereum/ERCs 仓库标注为 Final 状态，2023 年 2 月 21 日创建，要求合约同时完整实现 ERC-721，给一枚代币挂上多份互不干扰的核销记录，这类代币有时被称为多重核销 NFT。

记账的键是三个值拼出来的

这套标准最关键的设计是核销记录的键。标准规定，核销标记必须用“操作方地址、代币编号、核销编号”三元组作为键来存储，查询函数 isRedeemed 也按这三个参数返回一个布尔值。换句话说，同一枚 NFT 在 A 主办方那里核销过，不影响它在 B 摊位还是全新状态；同一个操作方名下，不同的 redemptionId 也各自独立记账。redeem 函数把某个核销标记为已使用并发出 Redeem 事件，cancel 可以撤销某条核销并发出 Cancel 事件，两者都带一个备注参数。getRedemptionIds 则列出一个地址在某枚代币上登记过的全部核销编号，方便前端把“已用/未用”画成清单。

还有一条容易被忽略的强制规则：redeem 和 cancel 的函数参数里刻意没有操作方地址，合约必须把 msg.sender 当作操作方。翻译过来就是“只有我能改我自己写的账”：一个活动方无法替另一个活动方核销或撤账，这正是多主办方共享一枚 NFT 时最容易出事的越权点。

它记录什么，不记录什么

链上核销记录是防重复使用的账本，不是权益本身。它能说明：某年某月，某个地址确实为这枚代币在某个操作方名下写过一条核销。它不能说明：实物周边到底寄没寄、线下门票有没有真的验过、权益兑没兑。标准甚至在元数据建议里让发行方用 description 字段写清楚活动细节——正因为它自己清楚，链上那三个字段承载不了完整的履约信息。把“已核销”当成“已履约”，本质是把记账和发货混为一谈，这两步之间的落差在链上没有任何机制兜底。

持有者核对清单

购买带权益的 NFT 之前，先用 ERC-165 探测合约是否真的实现了这个接口；再对照白皮书确认每个权益对应哪个 redemptionId——编号本身没有语义，全部解释权在活动方，标准并没有替你规定“编号一是门票”。每次核销发生时，去区块浏览器核对交易里的事件：操作方地址是不是你打交道的那家、代币编号是不是你手里这枚。如果记录显示“已使用”而你从未兑换过，要么授权链出了问题，要么有人冒用了你的签名，应立即撤销全部授权、转移其余资产并联系平台，别等客服流程走完再说。

常见误区

误区一：以为核销是全局的。不是，换个操作方就是另一本账，看到别人晒“已核销”不等于你的权益作废。误区二：担心 cancel 被滥用。撤销是核销场景的容错设计，规则上仅限原操作方能撤自己的账，但也要理解这意味着对方保留“改自己的账”的能力，履约争议最终回到条款而不是链上事件。误区三：把多重核销当积分点数。核销记录是状态旗标，不是可以滚动积累的余额。ERC-6672 给“一枚 NFT 配多个权益”提供了一个诚实的分户账本，但每项权益到底值不值，取决于发行方的履约记录，而不是链上那个布尔值。本文不构成投资建议。