{"id":"ERC-6059","name":"Parent-Governed Nestable NFTs","status":"Final","chain":"both","category":{"id":"nft","name":"NFT Capabilities","description":"What NFTs can do beyond basic ownership"},"journeyStages":[{"id":"asset-display","name":"Asset Discovery & Display","description":"Seeing tokens, NFTs, and balances"},{"id":"management","name":"Asset Management","description":"Managing assets over time"}],"uxImpact":"ERC-6059 is an official Final nesting standard superseded for new integrations by ERC-7401, in which compatible NFTs can own other NFTs through parent-child relationships. ERC-7401 provides a corrected interface identifier while remaining functionally equivalent for the nesting model; existing ERC-6059 deployments may remain usable. For new integrations, prefer ERC-7401 and verify the target collection's nesting behavior.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-6059","lastReviewed":"2026-09-18","supersededBy":"ERC-7401","historical":true,"lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-6059","summary":"ERC-6059 is an official Final nesting standard superseded for new integrations by ERC-7401, in which compatible NFTs can own other NFTs through parent-child relationships. ERC-7401 provides a corrected interface identifier while remaining functionally equivalent for the nesting model; existing ERC-6059 deployments may remain usable. For new integrations, prefer ERC-7401 and verify the target collection's nesting behavior.","applicability":{"whenToUse":["An existing collection implements ERC-6059 parent-child nesting and the product needs to show that on-chain hierarchy.","The UI must explain accepted and pending children and the recursive owner effect of a parent transfer.","You are maintaining a compatible ERC-6059 deployment; choose ERC-7401 for new integrations."],"whenToAvoid":["The collections do not implement compatible parent-child interfaces.","The product only needs a visual folder with no on-chain ownership hierarchy.","The app cannot show pending children, acceptance, and the target contract's transfer behavior."]},"designerTakeaways":["Design a tree that distinguishes accepted children from pending child proposals.","Preview the parent and its accepted children before a transfer; the target implementation determines the exact transaction path.","Direct new integrations to ERC-7401, while keeping ERC-6059 deployment and history labels accurate."],"problemsSolved":[{"problem":"Related NFTs are scattered across a wallet","oldWay":"Character, sword, and armor appear as a flat list.","newWay":"A compatible contract can expose a parent-child tree with accepted and pending children.","impact":"critical"},{"problem":"Parent transfer consequences are hard to see","oldWay":"Users transfer a parent without reviewing its nested inventory.","newWay":"A transfer preview lists accepted children and explains recursive ownership before signing.","impact":"critical"},{"problem":"Collections lack a visual hierarchy","oldWay":"Every NFT appears at the same level.","newWay":"A tree and breadcrumb show parent, child, and deeper relationships from contract reads.","impact":"high"},{"problem":"Nested inventory is difficult to manage","oldWay":"Users search the entire wallet for an item associated with a parent.","newWay":"Parent detail can expose compatible children and their pending/accepted state.","impact":"high"},{"problem":"Bundle sale requirements are unclear","oldWay":"A marketplace invents custody and bundle behavior around multiple transfers.","newWay":"The product previews nested contents and labels any sale/escrow behavior as an application integration.","impact":"medium"}],"uxPatterns":[{"name":"Nested NFT Tree View","description":"Hierarchical display of NFTs owning NFTs from a compatible implementation.","userFlow":["User opens inventory","Sees top-level NFTs","Expands accepted and pending children separately","Navigates deeper children","Shows value only where price data exists"]},{"name":"Add Child to NFT","description":"Propose or accept a child according to the target contract's supported nest path.","userFlow":["User selects a parent","Views compatible items","Reviews the target method and permissions","Submits a nest proposal or transfer","Shows pending until the contract records acceptance"]},{"name":"Remove from Parent","description":"Extract a child only through the target implementation's supported transferChild or unnest path.","userFlow":["User opens parent inventory","Selects an accepted child","Reviews destination and nested descendants","Submits the supported extraction call","Shows the resulting owner/parent state after settlement"]},{"name":"Nested Transfer Preview","description":"Show accepted children before a parent transfer; sale terms remain application-specific.","userFlow":["User selects a parent","System reads accepted children","UI shows child count and previews","User reviews the target transfer path","Confirmation explains what the contract's recursive owner model implies"]},{"name":"Pending Child Request","description":"Review incoming child proposals before acceptance when the implementation supports pending state.","userFlow":["Someone proposes a child","Parent owner sees the pending request","Reviews item and sender","Accepts or rejects through the supported call","UI reflects the settled state"]}],"uiComponents":[{"name":"NFTTreeView","description":"Expandable tree showing nested NFT hierarchy","states":["collapsed","expanded","loading","empty"],"props":["rootNFT","depth","onExpand","onSelect"]},{"name":"NestingModal","description":"Dialog for adding NFT as child","states":["selecting","confirming","nesting","complete"],"props":["parentNFT","availableChildren[]","onNest"]},{"name":"BundleValueCalculator","description":"Optional application valuation for a nested NFT bundle when a verified price source exists","states":["calculating","ready","no-price-data"],"props":["parentNFT","children[]","showBreakdown"]},{"name":"PendingNestRequest","description":"Card for approving/rejecting nest requests","states":["pending","accepted","rejected"],"props":["childNFT","parentNFT","sender","onAccept","onReject"]},{"name":"NestedBreadcrumb","description":"Shows path: Wizard > Backpack > Potion","states":["shallow","deep"],"props":["path[]","onNavigate"]}],"antiPatterns":[{"pattern":"Flat list hiding nested structure","why":"Users cannot see where an NFT sits in the on-chain hierarchy.","instead":"Show a tree or Nested filter with accepted and pending states.","severity":"critical"},{"pattern":"Parent transfer without child preview","why":"Users may not understand the recursive ownership consequence.","instead":"Read and list accepted children before signing, subject to target implementation behavior.","severity":"critical"},{"pattern":"Auto-accepting incoming children","why":"Unwanted NFTs can enter a parent when the contract supports pending proposals.","instead":"Require an explicit acceptance action when the contract exposes that state.","severity":"high"},{"pattern":"Showing estimated bundle value as a guarantee","why":"Price data and sale settlement are outside the nesting standard.","instead":"Label estimates and disclose the application and market data source.","severity":"high"},{"pattern":"Hiding deep nesting","why":"Users lose orientation in multi-level trees.","instead":"Use breadcrumbs, depth limits, and a full-tree view.","severity":"medium"},{"pattern":"Extracting a child without a destination warning","why":"The child may have descendants or a contract-specific transfer path.","instead":"Confirm destination and resulting hierarchy before the supported extraction call.","severity":"medium"}],"specConstraints":[{"id":"recursive-burn-limit","constraint":"Recursive burns must revert when the configured maximum cannot cover the children to burn.","appliesTo":"application","normativity":"normative","specQuote":"* @dev When specifying the maximum recursive burns, the execution MUST be reverted if there are more children to be","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-6059#specification","designImplication":"Burn confirmation should show the recursive scope and a failure state when the maximum child count is too small."},{"id":"no-descendant-cycle","constraint":"A destination token must not be a child or downstream descendant of the token being transferred.","appliesTo":"application","normativity":"normative","specQuote":"* @dev The destination token MUST NOT be a child token of the token being transferred or one of its downstream","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-6059#specification","designImplication":"Nested-transfer UI must prevent cyclic destinations and explain the hierarchy conflict before signing."},{"id":"safe-nest-transfer","constraint":"nestTransfer is safe only when the destination is checked for IERC6059 compatibility.","appliesTo":"application","normativity":"rationale","specQuote":"6. **Why is there not a \"safe\" nest transfer method?**\\\n`nestTransfer` is always \"safe\" since it MUST check for `IERC6059` compatibility on the destination.","specSection":"Rationale","specUrl":"https://ercs.ethereum.org/ERCS/erc-6059#rationale","designImplication":"Present a compatibility check in nesting flows and keep unsupported-destination failures distinct from ordinary transfer rejection."},{"id":"pending-commit","constraint":"Child additions use a propose-commit flow, with pending state before acceptance or rejection.","appliesTo":"application","normativity":"rationale","specQuote":"Adding child tokens to a parent token MUST be done in the form of propose-commit pattern to allow for limited mutability by a 3rd party. When adding a child token to a parent token, it is first placed in a *\"Pending\"* array, and MUST be migrated to the *\"Active\"* array by the parent token's root owner. The *\"Pending\"* child tokens array SHOULD be limited to 128 slots to prevent spam and griefing.","specSection":"Rationale > Propose-Commit pattern for child token management","specUrl":"https://ercs.ethereum.org/ERCS/erc-6059#propose-commit-pattern-for-child-token-management","designImplication":"Show pending and active child states separately and give the authorized parent/root actor an explicit accept or reject action."},{"id":"pending-cap","constraint":"The pending child array should stay below its bounded capacity to reduce spam/griefing.","appliesTo":"application","normativity":"normative","specQuote":"*  - the pending array of the parent contract MUST not be full.","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-6059#specification","designImplication":"Surface pending-capacity pressure and prevent a parent-management UI from implying unlimited pending children."},{"id":"root-vs-direct-owner","constraint":"The standard distinguishes recursive root ownership from immediate parent ownership.","appliesTo":"application","normativity":"rationale","specQuote":"We continue to use ERC-721's `ownerOf` functionality which will now recursively look up through parents until it finds an address which is not an NFT, this is referred to as the *root owner*. Additionally we provide the `directOwnerOf` which returns the most immediate owner of a token using 3 values: the owner address, the tokenId which MUST be 0 if the direct owner is not an NFT, and a flag indicating whether or not the parent is an NFT.","specSection":"Rationale > Parent Governed pattern","specUrl":"https://ercs.ethereum.org/ERCS/erc-6059#parent-governed-pattern","designImplication":"Show both root owner and direct parent in nested-asset views; do not treat the wallet that ultimately controls the tree as the immediate transfer authority in every action."},{"id":"parent-governance","constraint":"Parent NFTs govern operations for children that they own.","appliesTo":"application","normativity":"rationale","specQuote":"The root owner or an approved party MUST be able do the following operations on children: `acceptChild`, `rejectAllChildren` and `transferChild`.","specSection":"Rationale > Parent Governed pattern","specUrl":"https://ercs.ethereum.org/ERCS/erc-6059#parent-governed-pattern","designImplication":"Scope controls to the authority that can actually accept, reject, transfer, or burn the nested asset and explain why a child may be unavailable to the root wallet."},{"id":"erc721-ownership-compat","constraint":"Nestable ownership is compatible with ERC-721 tooling while recursively resolving root ownership.","appliesTo":"application","normativity":"backwards-compatibility","specQuote":"## Backwards Compatibility\n\nThe Nestable token standard has been made compatible with [ERC-721](./eip-721.md) in order to take advantage of the robust tooling available for implementations of ERC-721 and to ensure compatibility with existing ERC-721 infrastructure.","specSection":"Backwards Compatibility","specUrl":"https://ercs.ethereum.org/ERCS/erc-6059#backwards-compatibility","designImplication":"Reuse ERC-721 display and transfer conventions where they remain valid, but label nesting and recursive ownership explicitly."},{"id":"nested-sale-integrity","constraint":"Child composition may change after a sale and hidden implementation logic may exist.","appliesTo":"application","normativity":"security-considerations","specQuote":"## Security Considerations\n\nThe same security considerations as with [ERC-721](./eip-721.md) apply: hidden logic may be present in any of the functions, including burn, add child, accept child, and more.\n\nSince the current owner of the token is allowed to manage the token, there is a possibility that after the parent token is listed for sale, the seller might remove a child token just before before the sale and thus the buyer would not receive the expected child token. This is a risk that is inherent to the design of this standard. Marketplaces should take this into account and provide a way to verify the expected child tokens are present when the parent token is being sold or to guard against such a malicious behaviour in another way.\n\nCaution is advised when dealing with non-audited contracts.","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-6059#security-considerations","designImplication":"Marketplaces and portfolio views should recheck expected children and surface that nested composition is mutable and implementation-dependent."},{"id":"zero-recursive-burn","constraint":"Setting maxRecursiveBurn to 0 SHOULD attempt to burn only the specified token and MUST revert if child tokens are present.","appliesTo":"application","normativity":"normative","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-6059#specification","designImplication":"Burn confirmation should show the recursive scope and explain the revert when a supposedly single-token burn still has children.","specQuote":"* @dev Setting the `maxRecursiveBurn` value to 0 SHOULD only attempt to burn the specified token and MUST revert if\n* there are any child tokens present."},{"id":"parent-transfer-routing","constraint":"When a child is owned by an NFT, transfers MUST use the parent token's transferChild path, which SHOULD call nestTransferFrom or safeTransferFrom according to the destination.","appliesTo":"application","normativity":"rationale","specSection":"Rationale > Parent Governed pattern","specUrl":"https://ercs.ethereum.org/ERCS/erc-6059#parent-governed-pattern","designImplication":"Make the parent-token transfer path and destination compatibility explicit in nested-transfer UI; do not imply that a child can always be transferred directly.","specQuote":"If the token is owned by an NFT, only the parent NFT itself MUST be allowed to execute the operations listed above. Transfers MUST be done from the parent token, using `transferChild`, this method in turn SHOULD call `nestTransferFrom` or `safeTransferFrom` in the child token's smart contract, according to whether the destination is an NFT or not. For burning, tokens must first be transferred to an EOA and then burned."}],"keyTakeaways":["ERC-6059 is Final and supports parent-child NFT nesting in compatible implementations.","ERC-7401 supersedes ERC-6059 with an interface-ID correction; prefer it for new integrations.","Show accepted and pending children and preview the parent transfer consequence.","Treat marketplace, escrow, and pricing behavior as application-specific.","Keep historical ERC-6059 deployment labels accurate; supersession does not erase existing state."],"technicalNotes":"ERC-6059 uses ownerOf() for recursive root ownership and directOwnerOf() for the immediate owner plus parent token data. Child queries include childrenOf(), pendingChildrenOf(), childOf(), and pendingChildOf(); there is no parentOf() or rootOwner() method. Use the specified nestTransferFrom() and transferChild() paths and show pending children separately until accepted. ERC-7401 supersedes ERC-6059 to correct the interface identifier while preserving the nesting model.","lastUpdated":"2026-09-18","sources":[{"label":"ERC-6059 official specification","url":"https://ercs.ethereum.org/ERCS/erc-6059","type":"official-spec"}],"lastReviewed":"2026-09-18","relatedStandards":[{"id":"ERC-7401","relationship":"Successor with corrected interface identifier; functionally equivalent nesting model for new integrations."}]},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-6059","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-6059","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-6059","markdown":"https://www.eipsfordesigners.com/standards/ERC-6059/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-6059/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-6059","official":"https://ercs.ethereum.org/ERCS/erc-6059","discussion":"https://ethereum-magicians.org/search?q=ERC-6059"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}