Abstract
This standard extends the ERC-721 standard, enabling users to fuse two or more NFTs to create a new NFT with customized combination rules. This proposal aims to provide a more interactive and dynamic approach to NFT creation, unlocking new possibilities for NFT use cases and increasing their utility within the Ethereum ecosystem.
Motivation
The current NFT ecosystem lacks a standardized approach to combine multiple NFTs into a new one. While some projects have implemented custom solutions, these are often ad hoc and project-specific, limiting their interoperability with other NFTs and platforms. This standard aims to create a standardized method for fusing NFTs, enabling users to create new NFTs by combining existing ones according to customizable combination rules. This will foster more incredible innovation and creativity within the NFT space and create new possibilities for NFT use cases.
Specification
The keywords âMUST,â âMUST NOT,â âREQUIRED,â âSHALL,â âSHALL NOT,â âSHOULD,â âSHOULD NOT,â âRECOMMENDED,â âMAY,â and âOPTIONALâ in this document are to be interpreted as described in RFC 2119.
Interface
The following interface extends the existing ERC-721 standard:
// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.10;
interface IERC6927 {
// Events
/// @dev Emits when a combo is minted.
/// @param owner The owner address of the newly minted combo
/// @param comboId The newly minted combo identifier
event ComboMinted(address indexed owner, uint256 indexed comboId);
/// @dev Emits when a combo is dismantled.
/// @param owner The owner address of the combo
/// @param comboId The dismantled combo identifier
event ComboDismantled(address indexed owner, uint256 indexed comboId);
/// @dev Emits when an owner approves another address
/// @param spender The approved address
/// @param tokenOwner tokenOwner The NFT's owner
/// @param tokenAddresses The NFT's collection addresses
/// @param tokenIds The NFT identifiers
/// @param allowances The allowed number of uses
event ComboApproval(
address indexed spender,
address indexed tokenOwner,
address[] tokenAddresses,
uint256[] tokenIds,
uint256[] allowances
);
// Structs
/// @dev A ComboFactor defines the requirements for NFTs from a specific collection
/// to participate in the combo and the rules that apply.
/// A customized combination rule consists of several ComboFactors.
/// @param collectionAddress The NFT collection address
/// @param minRequired Minimum number of NFTs required from the collection
/// @param maxAllowed Maximum number of NFTs allowed from the collection
/// @param lockTokens Indicates if tokens from the collection will be locked when minting a combo
/// @param maxReuseCount Maximum total reuse count of a token from the collection in
/// this combo collection (only applicable for ERC-721 and when lockTokens is false)
struct ComboFactor {
address collectionAddress;
uint64 minRequired;
uint64 maxAllowed;
bool lockTokens;
uint64 maxReuseCount;
}
/// @param tokenAddress The NFT's collection address
/// @param tokenId The NFT identifier
/// @param amount The number of NFTs with `tokenId` used
struct Ingredient {
address tokenAddress;
uint256 tokenId;
uint256 amount;
}
// Functions
/// @dev Mints a combo using the provided NFTs as ingredients.
/// If a combo rule specifies an NFT to be locked, it will be locked within the combo.
/// For unlocked NFTs, their reuse count will be reduced accordingly.
/// @param ingredients The NFTs used to mint a combo
/// @param hash The hash representing user-specific adjustments or
/// operations applied to the final NFT's visual appearance when fusing NFTs. This
/// value provides additional information about the unique combination of NFTs.
function mint(
Ingredient[] calldata ingredients,
string calldata hash
) external;
/// @dev Dismantles a combo, returning locked NFTs to the current owner of the combo,
/// and restoring the reuse count of the participating but unlocked NFTs.
function dismantle(uint256 comboId) external;
/// @dev Retrieve the combo rule.
function getComboRule() external view returns (ComboFactor[] memory);
/// @dev Retrieve a combo's ingredients.
function getIngredients(
uint256 comboId
) external view returns (Ingredient[] memory);
/// @dev Approves `spender` to use `msg.sender`'s NFTs when minting a combo.
/// The approval allows the spender to use the specified NFTs within their allowance limits.
/// Only ERC-721 NFTs are approvable.
/// @param tokenAddresses The NFT's collection addresses
/// @param tokenIds The NFT identifiers
/// @param allowances The maximum number of uses
function approveCombo(
address spender,
address[] calldata tokenAddresses,
uint256[] calldata tokenIds,
uint256[] calldata allowances
) external;
}
Rationale
Firstly, the process of fusing existing NFTs to create new ones is highly diverse. The current NFT trading market uses a price discovery mechanism dominated by collection floor prices. To facilitate price discovery, it is essential to assign new NFTs created with different combination rules to separate collections. Therefore, we have extended the ERC-721 to support various combination rules.
Secondly, the potential for customizable combination rules is immense, and maintaining simplicity and flexibility is a fundamental principle. Given the current NFT trading marketâs price discovery mechanism, which is dominated by collection floor prices, we have positioned the collection as the basic unit of combination factors. Both ERC-721 and ERC-1155 are supported as combination factors. To avoid over-design, we have added only the most necessary parameters for each combination factor, such as upper and lower bounds and lock settings. Moreover, to prevent users from repeatedly creating combos using the same NFT without locking and destroying the scarcity of new assets, we have added usage limits for NFTs that do not require locking in the combination.
Lastly, fusing NFTs results in an internal structure within combos. These ingredients are distinct from metadata that cannot be read by smart contracts. They can be read by other smart contracts and used in more native on-chain application scenarios, such as smart airdrops and raffles based on different ingredients of combos.
Backwards Compatibility
This proposal is fully backwards compatible with the existing ERC-721 standard, extending the standard with new functions that do not affect the core functionality.
Test Cases
Test cases should be developed to cover the following scenarios:
- Minting a valid combo with ERC-721 and/or ERC-1155 NFTs.
- Dismantling a combo and returning locked NFTs to their owners.
- Setting combo rules and ensuring compliance during the minting - - process.
- Approving ERC-721 NFTs for use in combos.
- Querying combo rules and ingredients.
Reference Implementation
An implementation of this EIP will be provided upon acceptance of the proposal.
Security Considerations
This standard introduces some potential security considerations that must be addressed. These include:
- Ownership and permissions: It is crucial to ensure that only the rightful owner of the NFTs can initiate the fusing process. Proper access control and authentication mechanisms must be in place to prevent unauthorized users from fusing tokens they do not own.
- Reentrancy attacks: The fusing process may involve multiple calls to external contracts, potentially leading to reentrancy attacks. Proper security measures, such as reentrancy guards or the Checks-Effects-Interactions pattern, can help mitigate this risk.
- Gas consumption: The fusing process may involve complex computations and multiple contract interactions, leading to potentially high gas costs. Optimizing the fusing process to minimize gas consumption will be essential for ensuring usability and cost-effectiveness.
Copyright
Copyright and related rights waived via CC0.
Link to the EIP:
