ERC-5023 Shareable NFT (Shareable Non-Fungible Token)
Final · NFTs & multi-token · created 2022-01-28
A standard that lets you issue a copy of an NFT you hold as a new token and hand it out to others. The original stays as it is, and events record who shared what with whom.
Why it is needed
The existing NFT standards EIP-721 and EIP-1155 were designed for scarce digital assets and only define how to mint tokens and transfer them to someone else. However, some digital resources do not need to be scarce and instead become more valuable the more they are shared. For example, a person who receives a token recognizing their contribution to a project may want to share that recognition with colleagues who worked alongside them. Existing standards have no such sharing action, so each contract had to implement its own way of minting a copy and handing it over while keeping the original. There was also no common event recording shares, so the network of who shared with whom could not be tracked in a standard way. This standard solves the problem by defining the minimum functions and events for sharing in a single interface.
What to implement
event Share(address indexed from, address indexed to, uint256 indexed tokenId, uint256 derivedFromtokenId);: The event emitted when a token is shared. It records the sharing address, the receiving address, the newly minted token id, and which token it was derived from.function share(address to, uint256 tokenIdToBeShared) external returns(uint256 newTokenId);: Reminting an existing token assigns a new token id, and the new token is transferred to the recipient while the caller keeps the original. The recipient must be a different address from the caller.
In depth
Interface structure and ERC-165 identifier
IERC5023 inherits from IERC165 and consists of a Share event and a single share function. share(address to, uint256 tokenIdToBeShared) reminting an existing token to assign a new token id, keeps the original token owned by the caller, transfers the newly minted token to the recipient, which is an address other than the caller, and then returns newTokenId. The ERC-165 identifier of this interface is 0xded6338b. It requires EIP-165.
Meaning of the Share event
The Share event is expected to be emitted when the share function is called successfully, a new token is minted based on the given token id, and it is transferred to the recipient. from (the sharing address), to (the receiving address), and tokenId (the new token id) are indexed parameters, and derivedFromtokenId records which token it was derived from. It signals that a token was reminted and given to a wallet other than the function caller.
Transferability is left to the implementation
How to handle token transferability is left to the contract implementer. If transfers are left open, a shareable token behaves much like an existing token, except that the original version is kept when it is shared. If transfers are blocked, it becomes a shareable non-transferable token that can be minted and given or shared with others but cannot be handed on to someone else. Since the interface does not require a specific kind of token, implementations of different sharing methods are all possible, such as digital copying, partial sharing, and granting usage rights.
A graph built from share events
As Share event data accumulates, a tree structure forms over time. If Bob shares with Alice and Alice shares with Charlie and David, the sharing activity yields a basic tree structure. Gathering and folding more of these trees produces a network representation based on who shared with whom over a period of time, for example a social graph. This data can later be used for deeper analysis of the sharing activity the tokens represent.
Reference implementation ShareableERC721
The reference implementation is a shareable non-transferable token that honors community contributions. It inherits ERC721URIStorage and Ownable, and mint can be called only by the contract owner through onlyOwner. share uses require to check that to is not the zero address, that the token to be shared exists, and that msg.sender is the owner of that token. It reads the original's tokenURI, mints a new token using _currentIndex as the id, sets the same URI, and then emits the Share event. transferFrom and safeTransferFrom are both overridden to revert, so tokens cannot be transferred.
Compatibility with existing standards
This proposal is backwards compatible with EIP-721 and EIP-1155. The shareable tokens it designs are made to be compatible with existing token standards at the interface level, and implementation contracts may include extensions to meet requirements such as shareability. The status of the standard is Final, so it will not change further.
Things to watch out for
- Do not use the reference implementation as is: The reference implementation must not be used as is in a production environment. Beyond this, there are no other security considerations directly related to implementing the standard.