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.
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:
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.
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.
By allowing ERC-721 tokens to hold and trade different types of tokens, it enhances liquidity for markets in all types of tokens.
We propose using a pull mechanism, where the contract transfers the token to itself, instead of receiving it via "safe transfer" for 2 reasons:
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.
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.
This has the disadvantage of requiring approval of the token to be transferred before actually transferring it into an NFT.
We considered 2 ways of presenting the proposal:
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.
No backward compatibility issues found.
Tests are included in erc7590.ts.
To run them in terminal, you can use the following commands:
See ERC7590Mock.sol.
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:
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.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.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 and related rights waived via CC0.