NFT 能装进 NFT 吗：ERC-6059 可嵌套代币的 propose、accept 与递归销毁

先给直观含义

ERC-6059（Parent-Governed Nestable Non-Fungible Tokens，2022 年提出，已定稿）让一枚 NFT 的所有者可以是另一枚 NFT：父币持有子币，子币自己也可以再当父币。标准文档的定位一句话能说完——一个 NFT 可以被另一个 NFT 拥有，同时自己也持有若干 NFT。父币的根主人对子币有完整管理权，而任何人都有权向父币提议装进某个子币。

所有权模型：直接所有者与根所有者

接口里第一个关键函数是 directOwnerOf：返回三个值——直接持有者的地址（若持有者是另一枚代币，这里给的是父币所在集合的合约地址）、父币编号（持有者不是 NFT 时为 0）、以及一个标明“持有者是否为 NFT”的布尔值。它区分开两个概念——“谁拿着它”和“谁真正说了算”。子币的直接所有者是父币合约，但父币自己还有个主人，链上操作权限跟着父币易手。

装入：任何人提议，根主人点头

往父币里加子币必须走 propose-commit 流程。子币先进父币的待处理（Pending）数组，再由父币的根主人执行 acceptChild 迁入活跃（Active）数组，全程对应 ChildProposed 与 ChildAccepted 事件；rejectAllChildren 一次性清空待处理列表并触发 AllChildrenRejected 事件。

标准文档对这个设计有两段说明值得读：为什么 accept 要传数组下标而不是子币编号——用编号确认需要遍历数组、gas 随子币数量浮动，用下标则成本固定；为什么待处理数组应当限制在 128 个槽位——文档明说是为了防止垃圾和骚扰。它还补充了待处理数组的使用姿态：那不是“想留又舍不得转正”的仓库，而是一份候选清单，应当被及时审阅、接受或拒绝。

取出与转移：transferChild 的几种状态迁移

transferChild 是主管理函数。按文档列出的状态迁移，它能覆盖子币的几种走向：拒绝待处理的子币提议、放弃子币、解除嵌套（unnest，子币回到普通 ERC-721 形态）、把子币转给一个外部账户或 ERC721Receiver、以及把子币换到一个新的父币之下。函数参数里带着父币编号、目标地址与目标父币编号、子币所在数组的下标与 isPending 标志——用什么坐标组合触发哪种走向，文档给了图示说明。子币在父币持有期间转手只有这一条路，因为标准刻意不让普通转账函数绕过父子数组，防止两边状态不一致。

递归销毁：maxRecursiveBurns 为什么必须给数字

burn 函数销毁父币时可以连带销毁整棵子树，参数里有一个最大递归销毁数：按规范，若实际要销毁的子币数超过这个上限，执行必须回滚；把它设为 0 意味着只尝试销毁指定代币本身，只要还存在任何子币就必须回滚；函数返回实际被递归销毁的子币数量。这个参数的用意是防失控——嵌套没有硬深度，不设上限的话一笔交易可能被迫遍历极深的树，gas 消耗无从预估。

核验与阅读顺序

查一枚子币的真实状态：先 directOwnerOf 看它挂在谁名下、是不是另一枚代币；再沿父链逐层往上走，直到落在一个地址上——根主人才是它的实际控制人。查一枚父币带什么子币：childrenOf 列活跃子币，pendingChildrenOf 列待处理候选，两个数组含义完全不同。

三条风险说明

嵌套深度带来治理清晰：持币即持权。但也要看清三件事：一是待处理数组里的候选不是已装入的子资产，读到列表先分清活跃与待处理；二是递归销毁是打包操作，动手前确认数字足够并理解每一层；三是标准的跨集合嵌套只是所有权记账，子币的合约、元数据、风险仍然各管各的。

标准为什么要写成这样

文档的 Rationale 部分解释了几个关键取舍。为什么确认操作用数组下标而不是子币编号：用编号需要先遍历数组，gas 成本随父币的子币数量浮动，用下标则成本固定——这是一条很朴素的成本考虑。为什么待处理数组建议封顶 128 个槽位：防垃圾、防骚扰，同时文档直言待处理数组不是仓库，它是一份候选清单，应当被定期审阅接受或拒绝。为什么只做对 ERC-721 的向下兼容：让接口保持简单。为什么跨集合嵌套：嵌套关系不必锁在同一个合约里，不同项目的集合之间也能建立父子关系——这条决定了这套标准能做生态级组合，而不只是单合约内的包装玩法。

风险提示：本文为标准机制科普，不构成任何投资建议；嵌套关系与资产归属以合约实时查询为准。