Understanding ERC-998: The idea behind composable NFTs

Composable NFTs aim to solve a simple problem: the things we own onchain often come with other things. A game character owns equipment, a metaverse parcel contains buildings and wearables, an art NFT might include licenses or a treasury of tokens. Today, these relationships are fragmented across contracts and wallets. ERC-998 proposes a way for one NFT to own other NFTs and fungible tokens, and to move them together as a single, programmable bundle. This design unlocks richer asset hierarchies, safer transfers, and more intuitive user experiences. See the proposed standard in EIP-998 (Composable Non-Fungible Token).

What ERC-998 actually adds

ERC-721 defines unique assets. ERC-998 extends that idea with child ownership so a “parent” NFT can directly manage:

• Other ERC-721 tokens (e.g., items, sub-assets)
• ERC-20 balances (e.g., in-game currency, royalties)

ERC-998 introduces two patterns:

• Top-down composables: the parent NFT maintains an index of its children and can transfer them out or receive new ones. When you transfer the parent, children can move atomically with it. See the interface on EIP-998.
• Bottom-up composables: a child token records a reference to its parent for upward traversal. This lets contracts discover and enforce ownership hierarchies.

The practical win is atomicity: moving a single NFT can carry an entire inventory with it. For gaming, collectible bundles, or treasury-backed art, that’s a big UX upgrade compared to manual multi-asset transfers.

How ERC-998 compares to other standards

• ERC-721: one unique token per ID. It does not define child ownership. Reference: EIP-721.
• ERC-1155: multi-token standard where the same contract can issue both fungible and non-fungible tokens, with batch transfers and lower gas overhead. It still doesn’t define parent-child ownership out of the box. Reference: EIP-1155.
• Token Bound Accounts (EIP-6551): gives each NFT its own smart account so an NFT can hold assets and sign transactions via a contract wallet. Conceptually similar to “NFTs own assets,” but implemented via accounts rather than parent-child links. Reference: EIP-6551.
• Account Abstraction (EIP-4337): makes smart accounts more user-friendly and programmable (e.g., sponsored gas, custom validation), which complements NFT-owned accounts and advanced asset flows. Reference: EIP-4337.

In short, ERC-998 is a composability pattern at the token level, while EIP-6551 uses account-level composability. For some applications, ERC-998’s bundled transfer semantics are ideal; for others, token-bound accounts provide more flexible execution.

Why composable NFTs matter in 2025

Builders are pushing beyond simple collectibles into onchain games, metaverse primitives, and dynamic digital goods. Composability is crucial for:

• Game characters and loadouts: a single transfer updates ownership of the character plus equipment, pets, and consumables.
• DeFi positions: bundling a strategy NFT with staked assets or reward tokens for one-click moves or marketplace listing. Uniswap v3 positions are already ERC-721 tokens; bundling them with collateral or rewards improves UX. Reference: Uniswap v3 NonfungiblePositionManager.
• Metaverse parcels and sub-assets: land can carry structures, wearables, and access passes as children.
• Rights and licensing: the master NFT can include sub-licenses or revenue share tokens, transferring them together for clear ownership semantics.

With lower fees on Ethereum layer 2s, these richer interactions are more feasible to deploy and use at scale. See the overview of rollups and fee savings on Ethereum Layer 2.

Design and implementation notes

If you’re considering ERC-998, think through:

• Transfer semantics: define when children move with the parent and how to opt out. E.g., a “safe transfer” that carries children by default and a “light transfer” that leaves them.
• Child management: functions to add/remove children and enumerate them. Emit events for indexers to track bundles reliably. Reference indexing tools: The Graph documentation.
• Approvals and permissions: avoid accidental draining of children via approvals. Consider role-based controls for specific child types.
• Reentrancy and hooks: adding and transferring children triggers contract calls; follow best practices to avoid reentrancy and state inconsistencies. Reference: Ethereum security considerations for smart contracts.
• Marketplace visibility: ensure metadata includes child relationships and that events are friendly to indexers and aggregators. ERC-1155-like batch events can reduce indexing load.
• Upgradability and migration: if you use proxies, carefully handle storage layout and child registries across upgrades.

Note that ERC-998 is still a proposed extension. Many teams also explore token-bound accounts via EIP-6551 to get similar benefits with smart account tooling and EIP-4337-powered UX. Both paths can coexist: ERC-998 for simple, atomic bundles; EIP-6551 for complex execution and permissions.

Composability across L2s and cross-chain

• L2 deployments: batch child operations on rollups to save gas, and use canonical bridges to keep bundle integrity when moving between chains. Reference: Ethereum Layer 2.
• Cross-chain strategies: consider lock-and-mint or canonical mapping for parent and children, and make sure the bundle’s state can be reconstructed on the destination. Avoid partial bridging that breaks ownership graphs.

UX and developer checklist

• Build inventory views: show parent-child trees with balances and items.
• Atomic listing: enable “sell parent with children” options in marketplaces, or escrow children during listings to avoid disputes.
• Clear receipts: include child movements in transaction receipts and events so users and auditors can verify bundle integrity.
• Gas budgeting: batch operations and avoid unbounded child lists; cap sizes or use pagination.
• Testing: simulate edge cases (orphaned children, partial transfers, revocations) and integrate fuzzing for state machine coverage.

Where the market is heading

The renewed interest in onchain games, dynamic NFTs, and programmable ownership has brought composability to the forefront. Token-bound accounts (EIP-6551) are gaining adoption among builders, while standards like ERC-1155 continue to dominate high-throughput assets. ERC-998 offers a neat, token-native way to bundle assets, and in 2025 we’re seeing teams explore hybrids: ERC-998 for ownership graphs and EIP-6551 for execution power, all backed by account abstraction via EIP-4337 for better UX. References: EIP-6551, EIP-4337.

Safely holding composable NFTs

Managing NFTs that control other assets increases the stakes for private key security. Using a hardware wallet helps ensure signatures and approvals can’t be hijacked by malware. OneKey focuses on open-source security, multi-chain support, and clear signing flows, making it easier to review complex transactions that may move a parent NFT and its children in one go. If you intend to custody ERC-998 bundles or token-bound NFTs, practicing hardware-backed key management and transaction simulation is strongly recommended.

Key references

• Proposed specification: EIP-998 (Composable Non-Fungible Token)
• Base standards: EIP-721, EIP-1155
• Token-bound accounts: EIP-6551
• Account abstraction: EIP-4337
• Layer 2 overview: Ethereum Layer 2
• Indexing: The Graph documentation
• DeFi NFT positions: Uniswap v3 NonfungiblePositionManager

ERC-998 gives NFTs a way to carry what they own. Whether you choose token-level composability or account-level token-bound accounts, the goal is the same: predictable, secure transfer of rich onchain objects. As ecosystems mature in 2025, well-designed composability—paired with secure custody—will define the next generation of NFT experiences.