This proposal introduces a standard for fractionally represented non-fungible tokens, allowing NFTs to be managed and owned fractionally within a single contract. This approach enables NFTs to coexist with an underlying fungible representation seamlessly, enhancing liquidity and access without dividing the NFT itself, or requiring an explicit conversion step. The standard includes mechanisms for both fractional and whole token transfers, approvals, and event emissions. This specification draws from design in both ERC-721 and ERC-20, but is not fully compatible with either standard.
Fractional ownership of NFTs has historically relied on external protocols that manage division and reconstitution of individual NFTs into fractional representations. The approach of dividing specific NFTs results in fragmented liquidity of the total token supply, as the fractional representations of two NFTs are not equivalent and therefore must be traded separately. Additionally, this approach requires locking of fractionalized NFTs, preventing free transfer until they are reconstituted.
This standard offers a unified solution to fractional ownership, aiming to increase the liquidity and accessibility of NFTs without compromising transferability or flexibility.
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.
All ERC-7651 compliant contracts MUST implement the ERC-7651 and ERC-165 interfaces.
Compliant contracts MUST emit fractional Approval or Transfer events on approval or transfer of tokens in fractional representation.
Compliant contracts MUST additionally emit non-fungible ApprovalForAll, Approval or Transfer on approval for all, approval, and transfer in non-fungible representation.
Note that this interface draws from similarly defined functions in the ERC-721 and ERC-20 standards, but is not fully backwards compatible with either.
This is a RECOMMENDED interface, identical in definition to the ERC-721 Metadata Interface. Rather than using this interface directly, a distinct metadata interface should be used here to avoid confusion surrounding ERC-721 inheritance. Given function definitions here are identical, it's important to note that the ERC-165 interfaceId will be identical between metadata interfaces for this specification and that of ERC-721.
This is a RECOMMENDED interface that is intended to be used by implementations of ERC-7651 that implement NFT ID reuse.
This is a RECOMMENDED interface that is intended to be used by implementations of ERC-7651 that want to allow users to opt-out of NFT transfers.
This standard unifies the representation of fractional ownership with the non-fungible token model, aligning closely with ERC-721 principles while enabling the functionality of ERC-20 transfers. This dual compatibility aims to mitigate the integration complexity for existing protocols. Our goal is to implicitly support as high a degree of backwards compatibility with ERC-20 and ERC-721 standards as possible to reduce or negate integration lift for existing protocols. The core rationale for this fractional NFT standard centers on two main strategies: first, designing interfaces that clearly align with either ERC-721 or ERC-20 standards to avoid ambiguity; and second, detailing implementation approaches that distinctly separate the logic of overlapping functionalities.
Ensuring clear differentiation between token IDs and fractional amounts is central to this design. This non-overlapping design principle means that no input should be ambiguously interpreted as both an ID and an amount. We won't dive into implementation guidelines, but implementations may achieve this through various means, such as validating ownership for ID inputs or reserving specific ranges for token IDs.
This approach ensures that logic in "overlapping" interfaces is similarly isolated, such that the chance of an unexpected outcome is minimized.
The overlap of event signatures between the ERC-20 and ERC-721 standards presents a challenge for backward compatibility in our fractional NFT standard. Various approaches have been explored, including aligning with a single standard's events or introducing unique events with distinct parameter indexing to resolve conflicts.
We feel that when moving towards standardization, ensuring events are properly descriptive and isolated is the ideal solution despite introducing complexity for indexing software. As a result, we adhere to traditional transfer and approval event definitions, though distinguish these events by the Fractional or NonFungible prefixes.
In a standard ERC-7651 transfer, value can be transferred by specifying either a fractional amount or a specific NFT ID.
NFT ID Transfers: Transferring by NFT ID is straightforward. The specified NFT, along with its entire associated fractional value (equivalent to 10 ** decimals()), is transferred from the sender to the recipient.
Fractional Amount Transfers: Transferring fractional amounts introduces complexity in managing NFT allocations. There are three main scenarios:
While ERC-7651 provides a broad framework for fractional NFTs, it does not prescribe specific methods for handling these scenarios. Common practices include monotonically minting or burning tokens to reflect changes, or tracking NFT ownership with a stack or queue during transfers of fractional amounts.
Transferring fractional amounts means that a large number of NFTs can be moved in a single transaction, which can be costly in gas usage. We recommend an optional opt-in mechanism for exemption from NFT transfers that both EOAs and contracts can use to reduce the gas burden of transferring large token amounts when the NFT representation is not needed.
When executing the function call to either opt-in or opt-out of NFT transfers, NFTs held by the address will be directionally rebalanced to ensure they stay in sync with the new exemption status. In other words, when opting-out of NFT transfers, an address's NFTs will be banked and their NFT balance set to 0. When opting-in to NFT transfers, sufficient NFTs will be pulled from the bank and transferred to the address to match their fractional token balance.
As discussed in the Transfers section, when an address newly gains a full token in fractional terms, they are consequently owed an NFT. Similarly, when an address drops below a full token in fractional terms an NFT must be removed from their balance to stay in sync with their fractional balance.
The NFT banking mechanism provides a space in which un-owned but available NFTs relative to supply are tracked. We remain unopinionated on implementation here, but want to provide a handful of examples that would fit specification.
One approach to reconcile the bank is by monotonically burning and minting NFT IDs as they are pulled from and added back to circulation, respectively. The minting portion of this strategy can incur significant gas costs that are generally not made up for by the slight gas refund of deleting storage space for burnt token IDs. This approach additionally introduces inflexibility for collections that desire a persistent, finite ID space.
An alternate implementation of ERC-7651 includes a mechanism to store and reuse IDs rather than repeatedly burning and minting them. This saves significant gas costs, and has the added benefit of providing a predictable and externally readable stream of token IDs that can be held in a queue, stack or other data structure for later reuse. The specific data structure used for this banking mechanism is immaterial and is left at the discretion of any implementations adhering to the standard.
We include the ERC-165 interface in specification both to adhere to ERC-721 design philosophy, and as a means of exposing interfaces at the contract level. We see this as a valuable, accepted standard to adhere to such that integrating applications may identify underlying specification.
Note that ERC-7651 contracts should not make any claim through supportsInterface to support ERC-721 or ERC-20 standards as, despite strong backwards compatibility efforts, these contracts cannot fully adhere to existing specifications.
In-line with ERC-721, we've decided to isolate replicated metadata functionality through a separate interface. This interface includes traditional naming and token URI logic, though also introduces patterns surrounding token banking visibility, as outlined above in both the NFT Banking and Transfer Logic sections.
The fractional non-fungible token standard aims to be nearly backwards compatible with existing ERC-721 and ERC-20 standards, though makes no claim to fully adhere to either and has as such been proposed through a distinct interface.
Events in ERC-721 and ERC-20 specifications share conflicting signatures on approval and transfer, meaning an adherent hybrid of the two cannot be achieved.
This is one of the few areas where backwards compatibility has been intentionally broken, resulting in a new series of events with either a Fractional or NonFungible prefix. We believe that a decisive move to a non-conflicting, descriptive solution is ideal here, though will require external lift for indexing software.
The balanceOf function as defined in both ERC-20 and ERC-721 standards varies, in practice, to represent either fractional or whole token ownership respectively. Given fractional non-fungible tokens should adhere to an underlying fractional representation, it follows that this function should return a balance in that representation. This does, however, imply that fractional NFT contracts cannot fully adhere to the balanceOf specification provided by ERC-721.
The transfer and approve functions both return a boolean value indicating success or failure. This is non-standard for the ERC-721 specification, though is standard for ERC-20. Fractional non-fungible tokens adhere to a returned boolean value to meet minimum expectations for the ERC-20 standard, acknowledging that this deviates from a state of ideal backwards compatibility.
This section is placeholder for further discussion surrounding the misidentification of ERC-7651 as being either ERC-20 or ERC-721. Namely, discussion surrounding potential security implications of interface misinterpretation need to be thoroughly considered.
Needs discussion.
Copyright and related rights waived via CC0.