This EIP defines an interface to carry a real world asset with some privileges that can be exercised by the holder of the corresponding NFT. The EIP standardizes the interface for non-fungible tokens representing real world assets with privileges to be exercised, such as products sold onchain which can be redeemed in the real world.
And the privileges we describe here specifically refer to the rights and interests bound to the RWA NFT that can be executed by the holder in the real world.
NFTs bound to real-world assets sometimes need to carry certain privileges that can be exercised by the holder. Users can initiate transactions onchain to specify the exercise of a certain privilege, thereby achieving real-world privileges that directly map the onchain privilege through subsequent operations. For example, if a certain product such as a pair of shoes is sold onchain in the representation of NFT, the NFT holder can exercise the privilege of exchanging physical shoes offchain, to achieve the purpose of interoperability between the blockchain and the real world.
Having a standard interface enables interoperability for services, clients, UI, and inter-contract functionalities on top of this use-case.
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 inherits the ERC-721 NFT token standard for all transfer and approval logic. All transfer and approval functions are inherited from this token standard without changes. Additionally, this standard also inherits the ERC-721 Metadata standards for name, symbol, and metadata URI lookup.
Any compliant contract following this EIP MUST implement the following interface:
The function exercisePrivilege performs the exercise action to a specific privilege of a token. If succeeds, it is expected to emit a PrivilegeExercised event.
The function getPrivilegeIds provides a way to manage the binding relationship between NFTs and privilegeIds.
The metadata extension is OPTIONAL for EIP-7765 smart contracts. This allows your smart contract to be interrogated for its details about the privileges which your NFTs carry.
This is the “EIP-7765 Metadata JSON Schema” referenced above.
IERC7765Metadata provides specifications for obtaining metadata information of privileges. A contract that implements IERC7765Metadata SHALL also implement IERC7765.
With the PrivilegeExercised event emitted onchain, we can determine that the user has confirmed the exercise of this privilege, so as to implement the privilege in the real world.
We choose to include an address _to for functions exercisePrivilege, isExercisable and isExercised so that a specific privilege of an NFT MAY be exercised for someone who will benefit from it other than the NFT holder nor the transaction initiator. And This EIP doesn't assume who has the power to perform this action, it's totally decided by the developers who are using this standard.
We choose to include an extra _data field to function exercisePrivilege for extra message or future extension. For example, developers can use _data to exercise a privilege that takes effect directly onchain such as direct distribution of cryptocurrency assets.
The boolean view functions of isExercisable and isExercised can be used to check whether a specific privilege of an NFT can be exercisable or has been exercised to the _to address.
This standard is an extension of ERC-721. It is fully compatible with both of the commonly used optional extensions (IERC721Metadata and IERC721Enumerable) mentioned in the ERC-721 standard.
The reference implementation of Privileged NFTs can be found Here.
Compliant contracts should pay attention to the storage to the states of the privileges. The contract should properly handle the state transition of each privilege of each NFT, clearly showing that each privilege is exercisable or has been exercised.
Compliant contracts should also carefully define access control, particularly whether any EOA or contract account may or may not call exercisePrivilege function in any use case. Security audits and tests should be used to verify that the access control to the exercisePrivilege function behaves as expected.
Copyright and related rights waived via CC0.