| eip | title | description | author | discussions-to | status | type | category | created | requires |
|---|---|---|---|---|---|---|---|---|---|
6982 |
Efficient Default Lockable Tokens |
A gas-efficient approach to lockable ERC-721 tokens |
Francesco Sullo (@sullof), Alexe Spataru (@urataps) |
Draft |
Standards Track |
ERC |
2023-05-02 |
165, 721 |
This proposal introduces a lockable interface for ERC-721 tokens that optimizes gas usage by eliminating unnecessary events. This interface forms the foundation for the creation and management of lockable ERC-721 tokens. It provides a gas-efficient approach by emitting a DefaultLocked(bool locked) event upon deployment, setting the initial lock status for all tokens, while individual Locked(uint256 indexed tokenId, bool locked) events handle subsequent status changes for specific tokens. The interface also includes a view function locked(uint256 tokenId) to return the current lock status of a token.
Existing lockable token proposals often mandate the emission of an event each time a token is minted. This results in unnecessary gas consumption, especially in cases where tokens are permanently locked from inception to destruction (e.g., soulbounds or non-transferable badges). This proposal offers a more gas-efficient solution that only emits events upon contract deployment and status changes of individual tokens.
The interface is defined as follows:
// erc165 interfaceId 0x6b61a747
interface IERC6982 {
// MUST be emitted one time, when the contract is deployed,
// defining the default status of any token that will be minted
event DefaultLocked(bool locked);
// MUST be emitted any time the status changes
event Locked(uint256 indexed tokenId, bool locked);
// Returns the default status of the token.
function defaultLocked() external view returns (bool);
// Returns the status of the token.
// If no special event occurred, it MUST return what defaultLocked() returns.
// It MUST revert if the token does not exist.
function locked(uint256 tokenId) external view returns (bool);
}The ERC-165 interfaceId is 0xb45a3c0e.
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.
This standard aims to minimize gas usage by reducing the emission of events. The DefaultLocked event sets the initial lock status for all tokens, thus eliminating the need for an event upon the minting of each token. Some tokens may change their behavior (for example, after a reveal), in that case, the DefaultLocked event may be emitted again to set up the new default behavior when no token-specific event has been emitted yet.
The Locked event serves to track changes to individual tokens' lock status.
The defaultLocked function returns the default lock status of a token, which is set upon contract deployment. It is good to have it because it allows interacting with other contracts, and avoids conflicts with ERC-5192 (which is in final stage).
The locked function provides the current lock status of a token, enabling interaction with other contracts. If nothing changed for a specific token ID, it must return whatever defaultLocked returns.
Please note that the designation of a token as "locked" does not necessarily mean that it is completely non-transferable. There may be specific conditions under which a token, despite its locked status, can still be transferred. This locked status primarily pertains to its transferability on marketplaces and external exchanges.
To illustrate, let's consider the Cruna protocol. In this system, an NFT owner has the ability to activate what is termed an 'initiator'. This is essentially a secondary wallet with the unique privilege of initiating key transactions. Upon setting an initiator, the token's status is rendered 'locked'. However, this does not impede the token's transferability if the initiation for the transfer comes from the designated initiator.
This standard is fully backwards compatible with existing ERC-721 contracts. It can be easily integrated into existing contracts and will not cause any conflicts or disruptions.
There isn't a reference implementation due to the simplicity of the proposal. A production-ready implementation can be found in the Cruna Dominant-Subordinate protocol.
This EIP does not introduce any known security considerations. However, as with any smart contract standard, it is crucial to employ rigorous security measures in the implementation of this interface.
Copyright and related rights waived via CC0.