ERC-4675: Multi-Fractional Non-Fungible Tokens

Fractionalize multiple NFTs using a single contract

Metadata

Status: StagnantStandards Track: ERCCreated: 2022-01-13

Authors

David Kim (@powerstream3604)

Requires

EIP-165, EIP-721

Links

GitHub page Discussion on Ethereum Magicians

Abstract

This standard outlines a smart contract interface eligible to represent any number of fractionalized non-fungible tokens. Existing projects utilizing standards like EIP-1633 conventionally deploy separate EIP-20 compatible token contracts to fractionalize the non-fungible token into EIP-20 tokens. In contrast, this ERC allows each token ID to represent a token type representing(fractionalizing) the non-fungible token.

This standard is approximate in terms of using _id for distinguishing token types. However, this ERC has a clear difference with EIP-1155 as each _id represents a distinct NFT.

Motivation

The conventional fractionalization process of fractionalizing a NFT to FT requires deployment of a FT token contract representing the ownership of NFT. This leads to inefficient bytecode usage on Ethereum Blockchain and limits functionalities since each token contract is separated into its own permissioned address. With the rise of multiple NFT projects needing to fractionalize NFT to FT, new type of token standard is needed to back up them.

Specification

To receive Non-Fungible Token on safe Transfer the contract should include onERC721Received(). Including onERC721Received() is needed to be compatible with Safe Transfer Rules.

Rationale

Metadata

The symbol() & name() functions were not included since the majority of users can just fetch it from the originating NFT contract. Also, copying the name & symbol every time when token gets added might place a lot of redundant bytecode on the Ethereum blockchain. However, according to the need and design of the project it could also be added to each token type by fetching the metadata from the NFT contract.

Design

Most of the decisions made around the design of this ERC were done to keep it as flexible for diverse token design & architecture. These minimum requirement for this standard allows for each project to determine their own system for minting, governing, burning their MFNFT tokens depending on their programmable architecture.

Backwards Compatibility

To make this standard compatible with existing standards, this standard event & function names are identical with ERC-20 token standard with some more events & functions to add token type dynamically.

Also, the sequence of parameter in use of _id for distinguishing token types in functions and events are very much similar to ERC-1155 Multi-Token Standard.

Since this standard is intended to interact with the EIP-721 Non-Fungible Token Standard, it is kept purposefully agnostic to extensions beyond the standard in order to allow specific projects to design their own token usage and scenario.

Test Cases

Reference Implementation of MFNFT Token includes test cases written using hardhat. (Test coverage : 100%)

Reference Implementation

MFNFT - Implementation

Security Considerations

To fractionalize an already minted NFT, it is evident that ownership of NFT should be given to token contracts before fractionalization. In the case of fractionalizing NFT, the token contract should thoroughly verify the ownership of NFT before fractionalizing it to prevent tokens from being a separate tokens with the NFT.

If an arbitrary account has the right to call setParentNFT() there might be a front-running issue. The caller of setParentNFT() might be different from the real NFT sender. To prevent this issue, implementors should just allow admin to call, or fractionalize and receive NFT in an atomic transaction similar to flash loan(swap).