在以太坊卖 NFT 的人熟悉这样的流程：先对某市场合约点一次 approve 或 setApprovalForAll，之后市场才能替你转走代币；授权如果忘了撤，就一直挂在链上。NEAR 上的 NFT 市场也有同样的需求，处理它的标准是 NEP-178——NEP 委员会 2022 年批准的非同质化代币标准，其中”Approvals Management”一节专门为”允许市场替我转账”这件事定了一套接口。它的颗粒度和以太坊不太一样，值得逐条对照。
先看接口表。NEP-178 规定合约提供四个授权相关方法：nft_approve 给某个 token ID 授权某个账户，调用时必须附带一个 msg 参数（市场通常拿它登记挂单信息），且按标准这必须是一个视图方法调用——也就是授权和挂单一步完成；nft_revoke 撤销指定 token ID 上某个账户的授权，nft_revoke_all 则撤销本账户所有 NFT 上的所有授权，两者都要求是变更状态的调用；nft_is_approved 供任何人查询”某枚代币是否授权给了某账户、msg 是什么”。每个 token 内部维护 approved_account_ids 映射，账户与授权附言一一对应。标准原文还有一条容易被忽略的经济学细节：授权记录占用存储，被授权账户若要清除记录（比如交易完成后），要按字节的存储成本补偿代币持有者。
和 ERC-721 的差异可以列三条。第一，授权账本存在 NFT 合约自己的状态里、按 token 分账，ERC-721 的 getApproved 同样逐币，但 setApprovalForAll 那种”一个开关放行全部藏品”的全局授权在 NEP-178 里没有对应物——想做批量操作就得逐枚 approve，风险面天然小一圈，代价是市场批量上架要多签几笔。第二，approve 强制携带 msg，市场把挂单参数直接写进授权记录里，nft_is_approved 查回来的不只是”有没有授权”，还有”当时挂的是什么条件”，这给事后核对留了证据。第三，撤销是标准方法而不是靠发一笔”授权额度改零”的交易，nft_revoke_all 一个调用清干净，新手被”无限授权”缠上的经典坑在协议层面被削弱了。
实操上可以按四个场景核对。挂单前：用 nft_is_approved 查这枚代币当前挂着谁的授权——挂单未成交、又在别处挂第二单，是双花纠纷的高发结构；NEAR 市场挂单通常就是调 nft_approve 并附 msg，看清签名弹窗里那个合约是不是市场官方合约。成交后：正常流程市场转走代币并清理授权，但异常中止的订单未必清理干净，定期跑一遍 nft_is_approved 或在钱包授权管理页扫一遍。急事时：拿不准哪笔授权还开着，直接 nft_revoke_all 全撤再重挂要卖的——注意会同时撤掉正在进行的活跃挂单，先撤单再撤销授权更稳。迁移时：换市场不需要先”解除旧授权”才能在新市场挂单，但把两边授权都留着的代币在被清理前理论上有多个可转账方，稳妥顺序仍是旧市场撤单、确认授权清理、新市场挂单。
最后提醒标准覆盖不到的部分：NEP-178 管”谁能替你转这一枚”，不管”mint 时你同意了什么”、也不管市场前端会不会诱导你签错合约。授权字段读得再熟，签名弹窗里目标合约地址仍要逐次核对——标准给了账本，核对账本的人只能是你自己。
值得补一段费用视角。NEAR 的账户模型对“谁为存储付费”极为认真：授权记录写进 NFT 合约状态，占用的是合约的存储余额，标准用“被授权方清理记录时补偿持有者”的设计把这笔账算平。落到用户感知上，nft_approve 附带的那笔押金（标准示例是 1 yoctoNEAR 起）主要是防误调用的门槛，真正的成本在挂单成交后的链上结算里；挂单未成交而授权一直挂着，这条记录就一直占着位置。还有一个新手最容易踩的坑和以太坊高度相似：诈骗站会诱导你调用 nft_approve，把 msg 写成“成交后把钱打到攻击者地址”的挂单参数——从钱包视角看这只是一次普通函数调用，签名弹窗里的合约名与参数必须逐项核对；nft_is_approved 查回来的 msg 字段就是当时那笔挂单的完整声明，任何看不懂的 msg 都应当立刻 nft_revoke。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。