EIPs/EIPS/eip-6454.md

eip	title	description	author	discussions-to	status	last-call-deadline	type	category	created	requires
6454	Minimalistic Non-Transferable NFTs	An interface for Non-Transferable Non-Fungible Tokens extension allowing for tokens to be non-transferable.	Bruno Škvorc (@Swader), Francesco Sullo (@sullof), Steven Pineda (@steven2308), Stevan Bogosavljevic (@stevyhacker), Jan Turk (@ThunderDeliverer)	https://ethereum-magicians.org/t/minimalistic-transferable-interface/12517	Last Call	2023-04-07	Standards Track	ERC	2023-01-31	165, 721

Abstract

The Minimalistic Non-Transferable interface for Non-Fungible Tokens standard extends ERC-721 by preventing NFTs from being transferred.

This proposal introduces the ability to prevent a token from being transferred from their owner, making them bound to the externally owned account, smart contract or token that owns it.

Motivation

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:

• Verifiable attribution
• Immutable properties

Verifiable attribution

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.

Immutable properties

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.

Specification

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 0xa7331ab1.

pragma solidity ^0.8.16;

interface IERC6454 /* is IERC165 */ {
    /**
     * @notice Used to check whether the given token is non-transferable or not.
     * @dev If this function returns `true`, the transfer of the token MUST revert execution
     * @dev If the tokenId does not exist, this method MUST revert execution
     * @param tokenId ID of the token being checked
     * @return Boolean value indicating whether the given token is non-transferable
     */
    function isNonTransferable(uint256 tokenId) external view returns (bool);
}

Rationale

Designing the proposal, we considered the following questions:

1. Should we propose another Non-Transferable NFT proposal given the existence of existing ones, some even final, and how does this proposal compare to them?
   This proposal aims to provide the minimum necessary specification for the implementation of non-transferable NFTs, we feel none of the existing proposals have presented the minimal required interface. Unlike other proposals that address the same issue, this proposal requires fewer methods in its specification, providing a more streamlined solution.
2. Why is there no event marking the token as Non-Transferable in this interface?
   The token can become non-transferable either at its creation, after being marked as non-transferable, or after a certain condition is met. This means that some cases of tokens becoming non-transferable cannot emit an event, such as if the token becoming non-transferable is determined by a block number. Requiring an event to be emitted upon the token becoming non-transferable is not feasible in such cases.
3. Should the non-transferable state management function be included in this proposal?
   A function that marks a token as non-transferable or releases the binding is referred to as the non-transferable management function. To maintain the objective of designing an agnostic non-transferable proposal, we have decided not to specify the non-transferable management function. This allows for a variety of custom implementations that require the tokens to be non-transferable.
4. Why should this be an EIP if it only contains one method?
   One could argue that since the core of this proposal is to only prevent ERC-721 tokens to be transferred, this could be done by overriding the transfer function. While this is true, the only way to assure that the token is non-transferable before the smart contract execution, is for it to have the non-transferable interface.
   This also allows for smart contract to validate that the token is non-transferable and not attempt transferring it as this would result in failed transactions and wasted gas.
5. Why does this proposal use isNotTransferable instead of isTransferable?
   ERC-721 tokens are usually transferable, but this interface focuses on the use case where NFTs may not be transferable. The method name was chosen to reflect this.

Backwards Compatibility

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.

Test Cases

Tests are included in nonTransferable.ts.

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

cd ../assets/eip-6454
npm install
npx hardhat test

Reference Implementation

See ERC721NonTransferableMock.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 asset, accept asset, and more.

A smart contract can implement the proposal interface but returns fraudulent values, i.e., returning true for isNotTransferable 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 non-transferable state can change over time, verifying that the state of the token is non-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

Copyright and related rights waived via CC0.