ERC-6150: Hierarchical NFTs
Hierarchical NFTs, an extension to EIP-721.
Abstract
This standard is an extension to EIP-721. It proposes a multi-layer filesystem-like hierarchical NFTs. This standard provides interfaces to get parent NFT or children NFTs and whether NFT is a leaf node or root node, maintaining the hierarchical relationship among them.
Motivation
This EIP standardizes the interface of filesystem-like hierarchical NFTs and provides a reference implementation.
Hierarchy structure is commonly implemented for file systems by operating systems such as Linux Filesystem Hierarchy (FHS).
Websites often use a directory and category hierarchy structure, such as eBay (Home -> Electronics -> Video Games -> Xbox -> Products), and Twitter (Home -> Lists -> List -> Tweets), and Reddit (Home -> r/ethereum -> Posts -> Hot).
A single smart contract can be the root, managing every directory/category as individual NFT and hierarchy relations of NFTs. Each NFT's tokenURI may be another contract address, a website link, or any form of metadata.
The advantages and the advancement of the Ethereum ecosystem of using this standard include:
- Complete on-chain storage of hierarchy, which can also be governed on-chain by additional DAO contract
- Only need a single contract to manage and operate the hierarchical relations
- Transferrable directory/category ownership as NFT, which is great for use cases such as on-chain forums
- Easy and permissionless data access to the hierarchical structure by front-end
- Ideal structure for traditional applications such as e-commerce, or forums
- Easy-to-understand interfaces for developers, which are similar to Linux filesystem commands in concept
The use cases can include:
- On-chain forum, like Reddit
- On-chain social media, like Twitter
- On-chain corporation, for managing organizational structures
- On-chain e-commerce platforms, like eBay or individual stores
- Any application with tree-like structures
In the future, with the development of the data availability solutions of Ethereum and an external permissionless data retention network, the content (posts, listed items, or tweets) of these platforms can also be entirely stored on-chain, thus realizing fully decentralized applications.
Specification
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
Every compliant contract must implement this proposal, EIP-721 and EIP-165 interfaces.
Optional Extension: Enumerable
Optional Extension: Burnable
Optional Extension: ParentTransferable
Optional Extension: Access Control
Rationale
As mentioned in the abstract, this EIP's goal is to have a simple interface for supporting Hierarchical NFTs. Here are a few design decisions and why they were made:
Relationship between NFTs
All NFTs will make up a hierarchical relationship tree. Each NFT is a node of the tree, maybe as a root node or a leaf node, as a parent node or a child node.
This proposal standardizes the event Minted to indicate the parent and child relationship when minting a new node. When a root node is minted, parentId should be zero. That means a token id of zero could not be a real node. So a real node token id must be greater than zero.
In a hierarchical tree, it's common to query upper and lower nodes. So this proposal standardizes function parentOf to get the parent node of the specified node and standardizes function childrenOf to get all children nodes.
Functions isRoot and isLeaf can check if one node is a root node or a leaf node, which would be very useful for many cases.
Enumerable Extension
This proposal standardizes three functions as an extension to support enumerable queries involving children nodes. Each function all have param parentId, for compatibility, when the parentId specified zero means query root nodes.
ParentTransferable Extension
In some cases, such as filesystem, a directory or a file could be moved from one directory to another. So this proposal adds ParentTransferable Extension to support this situation.
Access Control
In a hierarchical structure, usually, there is more than one account has permission to operate a node, like mint children nodes, transfer node, burn node. This proposal adds a few functions as standard to check access control permissions.
Backwards Compatibility
This proposal is fully backward compatible with EIP-721.
Reference Implementation
Implementation: EIP-6150
Security Considerations
No security considerations were found.
Copyright
Copyright and related rights waived via CC0.