ERC-7590: ERC-20 Holder Extension for NFTs

Extension to allow NFTs to receive and transfer ERC-20 tokens.

Metadata
Status: ReviewStandards Track: ERCCreated: 2024-01-05
Authors
Steven Pineda (@steven2308), Jan Turk (@ThunderDeliverer)
Requires
EIP-20, EIP-165, EIP-721
Links
GitHub pageDiscussion on Ethereum Magicians

Abstract

This proposal suggests an extension to ERC-721 to enable easy exchange of ERC-20 tokens. By enhancing ERC-721, it allows unique tokens to manage and trade ERC-20 fungible tokens bundled in a single NFT. This is achieved by including methods to pull ERC-20 tokens into the NFT contract to a specific NFT, and transferring them out by the owner of such NFT. A transfer out nonce is included to prevent front-running issues.

Motivation

In the ever-evolving landscape of blockchain technology and decentralized ecosystems, interoperability between diverse token standards has become a paramount concern. By enhancing ERC-721 functionality, this proposal empowers non-fungible tokens (NFTs) to engage in complex transactions, facilitating the exchange of fungible tokens, unique assets, and multi-class assets within a single protocol.

This ERC introduces new utilities in the following areas:

  • Expanded use cases
  • Facilitating composite transactions
  • Market liquidity and value creation

Expanded Use Cases

Enabling ERC-721 tokens to handle various token types opens the door to a wide array of innovative use cases. From gaming and digital collectibles to decentralized finance (DeFi) and supply chain management, this extension enhances the potential of NFTs by allowing them to participate in complex, multi-token transactions.

Facilitating Composite Transactions

With this extension, composite transactions involving both fungible and non-fungible assets become easier. This functionality is particularly valuable for applications requiring intricate transactions, such as gaming ecosystems where in-game assets may include a combination of fungible and unique tokens.

Market Liquidity and Value Creation

By allowing ERC-721 tokens to hold and trade different types of tokens, it enhances liquidity for markets in all types of tokens.

Specification



Rationale


Pull Mechanism


We propose using a pull mechanism, where the contract transfers the token to itself, instead of receiving it via "safe transfer" for 2 reasons:


    

  1. 

    Customizability with Hooks. By initiating the process this way, smart contract developers have the flexibility to execute specific actions before and after transferring the tokens.
    

    2. 

  2. 

    Lack of transfer with callback: ERC-20 tokens lack a standardized transfer with callback method, such as the "safeTransfer" on ERC-721, which means there is no reliable way to notify the receiver of a successful transfer, nor to know which is the destination token is.
    

    3. 



This has the disadvantage of requiring approval of the token to be transferred before actually transferring it into an NFT.


Granular vs Generic


We considered 2 ways of presenting the proposal:


    

  1. A granular approach where there is an independent interface for each type of held token.
    2. 

  2. A universal token holder which could also hold and transfer ERC-721 and ERC-1155.
    3. 



An implementation of the granular version is slightly cheaper in gas, and if you're using just one or two types, it's smaller in contract size. The generic version is smaller and has single methods to send or receive, but it also adds some complexity by always requiring Id and amount on transfer methods. Id not being necessary for ERC-20 and amount not being necessary for ERC-721.


We also considered that due to the existence of safe transfer methods on both ERC-721 and ERC-1155, and the commonly used interfaces of IERC721Receiver and IERC1155Receiver, there is not much need to declare an additional interface to manage such tokens. However, this is not the case for ERC-20, which does not include a method with a callback to notify the receiver of the transfer.


For the aforementioned reasons, we decided to go with a granular approach.


Backwards Compatibility


No backward compatibility issues found.


Test Cases


Tests are included in erc7590.ts.


To run them in terminal, you can use the following commands:




Reference Implementation


See ERC7590Mock.sol.


Security Considerations


The same security considerations as with ERC-721 apply: hidden logic may be present in any of the functions, including burn, add resource, accept resource, and more.


Caution is advised when dealing with non-audited contracts.


Implementations MUST use the message sender as from parameter when they are transferring tokens into an NFT. Otherwise, since the current contract needs approval, it could potentially pull the external tokens into a different NFT.


When transferring ERC-20 tokens in or out of an NFT, it could be the case that the amount transferred is not the same as the amount requested. This could happen if the ERC-20 contract has a fee on transfer. This could cause a bug on your Token Holder contract if you do not manage it properly. There are 2 ways to do it, both of which are valid:


    

  1. Use the IERC20 interface to check the balance of the contract before and after the transfer, and revert if the balance is not the expected one, hence not supporting tokens with fees on transfer.
    2. 

  2. Use the IERC20 interface to check the balance of the contract before and after the transfer, and use the difference to calculate the amount of tokens that were actually transferred.
    3. 



To prevent a seller from front running the sale of an NFT holding ERC-20 tokens to transfer out such tokens before a sale is executed, marketplaces MUST beware of the erc20TransferOutNonce and revert if it has changed since listed.


ERC-20 tokens that are transferred directly to the NFT contract will be lost.


Copyright


Copyright and related rights waived via CC0.