NFT 自带零钱包：ERC-7590 代币持有人扩展的进出与防抢跑

游戏里一枚装备 NFT 附带一袋金币，或者一张会员卡同时攒着积分余额——过去要把“藏品”和“钱”分装进两个合约再缝起来。ERC-7590 把缝线省了：ERC-20 代币直接住进 ERC-721 合约里，账本归属挂在枚上而不是地址上。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该标准状态为 Review，2024 年 1 月 5 日创建，依赖 ERC-20、ERC-165 与 ERC-721。

四个函数与“币到底在谁账上”

读账用 balanceOfERC20(erc20Contract, tokenId)：注意返回的是“这枚代币”的余额，不是某个地址的。存币用 transferERC20ToToken(erc20Contract, tokenId, amount, data)：代币从 msg.sender 名下转入 NFT 合约本身，因此那枚 ERC-20 合约必须事先对本合约做过授权，这笔转账由 NFT 合约代为执行。取币用 transferHeldERC20FromToken(erc20Contract, tokenId, to, amount, data)：余额从合约付出，调用者必须是这枚 NFT 的所有者或经授权管理者，否则回滚——顺带把转出 nonce 加一。erc20TransferOutNonce(tokenId) 单独暴露这个计数器。事件侧，ReceivedERC20 记录入账、TransferredERC20 记录出账，索引参数覆盖币种、枚号与对手地址。

一句话账本真相：ERC-20 的 balanceOf 里被加总的那部分，持有人地址是 NFT 合约；枚的所有者身份才是取款钥匙。藏品的转让因此多出一层含义——transferFrom 换掉的不仅是藏品，还有这袋随枚附赠的余额。

nonce 防的是什么

取币递增 nonce 的用意在标准文本里写得直白：防抢跑。设想挂单出售一枚带余额的 NFT，恶意观察者可以在你的交易确认前抢先完成取币转账——nonce 把“取币动作”与一个单调计数绑定，让依赖旧 nonce 的预签名交易失效，给组合交易与签约流程提供一致性凭据。对普通持有人，这意味着授权第三方合约代管 NFT 时要多想一层：isApprovedForAll 一旦放行，被授权方即可调用取币函数。

三个使用前的确认点

挂单前的一分钟自查

最容易被忽视的场景是卖带余额的 NFT。市场挂单通常要求先授权合约转移藏品，一旦放行，拥有 isApprovedForAll 级权限的市场合约理论上就满足了 transferHeldERC20FromToken 的调用条件——正规平台当然不会乱动用户的袋内资产，但权限分析的写法和“相信平台自觉”不是一回事。稳妥的顺序是：先 transferHeldERC20FromToken 把袋中 ERC-20 提到自己地址，再对 NFT 做挂牌授权，让“送藏品”与“送零钱”两个决定分开签字。第二个自查点是 nonce：erc20TransferOutNonce 随每次出账递增，任何预先签好、绑定了旧 nonce 的组合交易都会作废，这保护了用户，也意味着批处理脚本要先读 nonce 再组装。第三个自查点是可见性：在常规资产面板里看不到枚内余额不代表钱丢了，查询路径是 NFT 合约上的 balanceOfERC20，参数是币种合约地址加代币编号；如果项目方自己的界面都不提供这一读数，那至少说明它对这一扩展的支持还停留在口头。标准还在 Review 阶段，接口以 ethereum/ERCs 仓库文本为准。最后把这一扩展的适用画像收个尾：它最合身的场景是游戏道具附带耗材、会员卡捆绑积分、组合权益一次成交这类“藏品与余额天然同体”的产品逻辑；反之，若藏品与资金本就该分账管理，强行套进枚内余额只会把简单的 ERC-20 转账复杂化成两段授权加一层枚内簿记，多出来的每次 nonce 校验与回调判断都是实打实的攻击面——工具的正确用法不是处处用它，而是认出它该出场的地方；在动手写集成之前，先在测试网把存、取、转让、nonce 四条路径各走一遍，比读十遍文档更能暴露理解偏差。顺带一句普通买家也该懂的常识：一枚“带币”的 NFT 在不同市场之间的显示口径并不统一，同一枚藏品在 A 站显示含内嵌余额的综合估值、在 B 站只显示裸藏品，两边截图互相转发时极易引发误会，核对永远以链上函数的即时返回为准。

其一，去哪个合约查余额：链上直查要走 NFT 合约的扩展函数，常规 ERC-20 持仓页看不见“枚内余额”，聚合器若未适配就会显示不一致，这属于口径差异而非丢币。其二，转让语义：把带余额的 NFT 转给他人等于连零花钱一起送，转账前调一次 balanceOfERC20 是 3 秒钟的自保动作。其三，合规声明：标准建议合规合约同时实现 ERC-165 与 ERC-721 的完整接口，遇到“只有一半实现”的合约应直接回避。标准尚在 Review，接口与事件签名以仓库文本为准。本文为协议机制科普，不构成任何投资建议；标准状态以 ethereum/ERCs 仓库文本为准（核验时间 2026 年 9 月 9 日）。