一枚合约两张面孔：ERC-7681 让 ERC-20 与 ERC-1155 同步记账

想参与一枚高价 NFT 的人希望它碎成 ERC-20 份额方便买卖，想收藏整枚的人又需要它在钱包里以 ERC-1155 的形式真实存在。ERC-7681（Dual Nature Multi Token Protocol）把这对矛盾塞进一份合约：同时完整实现 ERC-20 与 ERC-1155 两套接口，让碎片化的同质份额与半同质的多代币身份保持比例同步。按 ercs 仓库记录，提案状态为 Draft（草稿），创建于 2024 年 4 月 8 日，声明参考了更早的 ERC-7631——那份把 ERC-20 与 ERC-721 互联起来的姊妹方案。

为什么要选 1155 而不是 721

ERC-7631 路线有一个技术性障碍：ERC-20 和 ERC-721 都定义了签名相同的 Transfer(address,address,uint256) 事件，两套逻辑共存时事件日志难以区分是谁在转账。ERC-1155 天然避开了这一点——它的转账事件叫 TransferSingle 与 TransferBatch，还带着自己的 id 字段，两类记账在日志层面泾渭分明。规范因此把同样的互联思路搬到 ERC-1155 上：当你获得 ERC-20 份额时，合约按比例自动铸造对应数量的 ERC-1155 代币，两边各自符合各自的标准，市场与钱包可以按各自认识的那一半来处理。

同步规则与退出开关

同步是跟随 ERC-20 一侧发生的：你 ERC-20 持仓增加，1155 侧按比例出现；持仓减少，1155 侧按比例收回。如果某个地址不希望自己的 1155 半边被自动铸造或转移，规范留了逃生门——getSkipToken(owner) 查询该地址的跳过状态，setSkipToken(bool) 由持有人自己开启或关闭。开启跳过后，ERC-20 照常记账，1155 侧不再跟随。此外合约要求完整保留两边的全部标准事件：Transfer、Approval、TransferSingle、TransferBatch、ApprovalForAll 与 URI，任何一个缺失都不算合规实现。

双身份带来的新坑

第一类坑在余额口径：同一个人的财富在两张账本上各有一份表示，聚合工具若同时相加两个界面，会把同一笔资产数两遍；正确姿势是只认一侧为“全部”，另一侧视作镜像。第二类坑在授权：ERC-20 的 approve 与 ERC-1155 的 setApprovalForAll 是两个互不相干的权限开关，只撤一边等于漏撤。第三类坑在跳过开关：一旦开启 skip，之后 ERC-20 的买卖不会再同步出 1155 身份，想找回整枚形态要不要重新铸造、按什么规则铸造，完全由实现方决定——这一点规范没有替产品回答，必须读项目文档确认。

怎么看待“可拆分 NFT”

一次充值、两本账的对账清单

托管合约往往默认开启跳过开关：接收方是智能合约时（比如 DEX 或借贷协议），合约把自己 skip 状态设为 true，就不必为一次交互铸造一堆用不掉的 1155 代币。规范把这当作省 gas 的常规操作，读代码时却容易看漏一层后果：你的碎片如果流进过这类合约，1155 一侧的镜像可能根本没铸出来。给持有者的对账习惯是：每次充值或提币后，立刻用两套 balanceOf 各读一次——ERC-20 版本只带地址、1155 版本带地址和编号，两边折算后应当按比例吻合；再读一次 getSkipToken 确认自己的跳过状态没有被动过；最后翻一遍 Transfer 与 TransferSingle 事件是否成对出现。三个动作串起来，双身份才不会变成双黑洞。

一个容易被忽略的记账时点

同步发生在“持仓变化”的时刻，而不是“事件被索引”的时刻。同一个区块里如果你的 ERC-20 份额先被划走又被转回，1155 侧的镜像会经历一次收回再铸造，中间状态在事件日志里留有完整痕迹；反过来，索引器若按轮询快照对账，很容易把这种同块内的往返读成“从未持有”。排查“我的 1155 头像币怎么没了”这类问题，顺序应当是按交易逐笔重放两套事件，而不是比对两个页面截图——双合约单账本的结构里，页面是结果不是过程。

碎片化的叙事总是好听：人人参与、门槛归零。真实的结构是：碎片持有人拿到的是 ERC-20 份额对底层资产的索取逻辑，托管整枚资产的金库合约、赎回流程、争议处理，都不在 ERC-7681 的管辖范围里。标准只保证两本账对得上，不保证金库可信。评估此类产品时优先核对：1155 一侧的 uri 指向什么、赎回是销毁 ERC-20 换整枚还是现金、运营方变更时有没有只读证据可查。两张面孔的合约，值得用两副眼镜分别检查。本文为机制说明，不构成任何投资建议。