The Minimalistic Transferable interface for Non-Fungible Tokens standard extends ERC-721 by introducing the ability to identify whether an NFT can be transferred or not.
This proposal introduces the ability to prevent a token from being transferred from their owner, making them bound to the externally owned account, abstracted account, smart contract or token that owns it.
With NFTs being a widespread form of tokens in the Ethereum ecosystem and being used for a variety of use cases, it is time to standardize additional utility for them. Having the ability to prevent the tokens from being transferred introduces new possibilities of NFT utility and evolution.
This proposal is designed in a way to be as minimal as possible in order to be compatible with any usecases that wish to utilize this proposal.
This EIP introduces new utilities for ERC-721 based tokens in the following areas:
Personal achievements can be represented by non-fungible tokens. These tokens can be used to represent a wide range of accomplishments, including scientific advancements, philanthropic endeavors, athletic achievements, and more. However, if these achievement-indicating NFTs can be easily transferred, their authenticity and trustworthiness can be called into question. By binding the NFT to a specific account, it can be ensured that the account owning the NFT is the one that actually achieved the corresponding accomplishment. This creates a secure and verifiable record of personal achievements that can be easily accessed and recognized by others in the network. The ability to verify attribution helps to establish the credibility and value of the achievement-indicating NFT, making it a valuable asset that can be used as a recognition of the holder's accomplishments.
NFT properties are a critical aspect of non-fungible tokens, serving to differentiate them from one another and establish their scarcity. Centralized control of NFT properties by the issuer, however, can undermine the uniqueness of these properties.
By tying NFTs to specific properties, the original owner is ensured that the NFT will always retain these properties and its uniqueness.
In a blockchain game that employs non-transferable NFTs to represent skills or abilities, each skill would be a unique and permanent asset tied to a specific player or token. This would ensure that players retain ownership of the skills they have earned and prevent them from being traded or sold to other players. This can increase the perceived value of these skills, enhancing the player experience by allowing for greater customization and personalization of characters.
The key words “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.
/// @title EIP-6454 Minimalistic Non-Transferable interface for NFTs
/// @dev See https://eips.ethereum.org/EIPS/eip-6454
/// @dev Note: the ERC-165 identifier for this interface is 0x91a6262f.
pragma solidity ^0.8.16;
interface IERC6454 /* is IERC165 */ {
/**
* @notice Used to check whether the given token is transferable or not.
* @dev If this function returns `false`, the transfer of the token MUST revert execution.
* @dev If the tokenId does not exist, this method MUST revert execution, unless the token is being checked for
* minting.
* @dev The `from` parameter MAY be used to also validate the approval of the token for transfer, but anyone
* interacting with this function SHOULD NOT rely on it as it is not mandated by the proposal.
* @param tokenId ID of the token being checked
* @param from Address from which the token is being transferred
* @param to Address to which the token is being transferred
* @return Boolean value indicating whether the given token is transferable
*/
function isTransferable(uint256 tokenId, address from, address to) external view returns (bool);
}
In order to determine whether a token is transferable or not in general, the function SHOULD return the appropriate boolean value when passing the 0x0000000000000000000000000000000000000000 address as the to and from parameter.
The general transferability of a token should not be affected by the ability to mint the token (value of from parameter is 0x0000000000000000000000000000000000000000) and the ability to burn the token (value of to parameter is 0x0000000000000000000000000000000000000000).
If the general transferability of token is false, any kind of transfer of the token, save minting and burning, MUST revert execution.
In order to determine whether a token is mintable, the exception SHOULD be made to allow the tokenId parameter for a token that does not exist. Additionally the from parameter SHOULD be 0x0000000000000000000000000000000000000000 and the to parameter SHOULD NOT be 0x0000000000000000000000000000000000000000.
In order to determine whether a token is burnable, the from parameter SHOULD NOT be 0x0000000000000000000000000000000000000000 and the to parameter SHOULD be 0x0000000000000000000000000000000000000000.
Implementers MAY choose to validate the approval of the token for transfer by the from parameter, but anyone interacting with this function SHOULD NOT rely on it as it is not mandated by the proposal. This means that the from parameter in such implementations validates the initiator of the transaction rather than the owner from which the token is being transferred (which can either be the owner of the token or the operator allowed to transfer the token).
Designing the proposal, we considered the following questions:
tokenId parameter?\
The initial version of the proposal contained a method that only accepted a tokenId parameter. This method would return a boolean value indicating whether the token is transferable. However, the fact that the token can be non-transferable for different reasons was brought up throughout the discussion. This is why the method was changed to accept additional parameters, allowing for a more flexible implementation. Additionally, we kept the original method’s functionality by specifying the methodology on how to achieve the same result (by passing the 0x0000000000000000000000000000000000000000 address as the to and from parameters).isTransferable validates approvals as well?\
We considered specifying that the from parameter represents the initiator of the token transfer. This would mean that the from would validate whether the address is the owner of the token or approved to transfer it. While this might be beneficial, we ultimately decided to make it optional.\
As this proposal aims to be the minimal possible implementation and the approvals are already standardized, we feel that isTransferable can be used in conjunction with the approvals to validate whether the given address can initiate the transfer or not.\
Additionally, mandating the validation of approvals would incur higher gas consumption as additional checks would be required to validate the transferability.The Minimalistic Non-Transferable token standard is fully compatible with ERC-721 and with the robust tooling available for implementations of ERC-721 as well as with the existing ERC-721 infrastructure.
Tests are included in transferable.ts.
To run them in terminal, you can use the following commands:
cd ../static/assets/eip-6454
npm install
npx hardhat test
See ERC721TransferableMock.sol.
The same security considerations as with ERC-721 apply: hidden logic may be present in any of the functions, including burn, add asset, accept asset, and more.
A smart contract can implement the proposal interface but returns fraudulent values, i.e., returning false for isTransferable when the token is transferable. Such a contract would trick other contracts into thinking that the token is non-transferable when it is transferable. If such a contract exists, we suggest not interacting with it. Much like fraudulent ERC-20 or ERC-721 smart contracts, it is not possible to prevent such contracts from existing. We suggest that you verify all of the external smart contracts you interact with and not interact with contracts you do not trust.
Since the transferability state can change over time, verifying that the state of the token is transferable before interacting with it is essential. Therefore, a dApp, marketplace, or wallet implementing this interface should verify the state of the token every time the token is displayed.
Caution is advised when dealing with non-audited contracts.
Copyright and related rights waived via CC0.