This standard is an extension of ERC-1155. It proposes an additional role (user) which can be granted to addresses that represent a user of the assets rather than an owner.
Motivation
Like ERC-721, ERC-1155 tokens may have utility of some kind. The people who “use” the token may be different than the people who own it (such as in a rental). Thus, it would be useful to have separate roles for the “owner” and the “user” so that the “user” would not be able to take actions that the owner could (for example, transferring ownership).
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.
// SPDX-License-Identifier: CC0-1.0
pragmasolidity^0.8.0;interfaceIERC5006{structUserRecord{uint256tokenId;addressowner;uint64amount;addressuser;uint64expiry;}/**
* @dev Emitted when permission for `user` to use `amount` of `tokenId` token owned by `owner`
* until `expiry` are given.
*/eventCreateUserRecord(uint256recordId,uint256tokenId,uint64amount,addressowner,addressuser,uint64expiry);/**
* @dev Emitted when record of `recordId` are deleted.
*/eventDeleteUserRecord(uint256recordId);/**
* @dev Returns the usable amount of `tokenId` tokens by `account`.
*/functionusableBalanceOf(addressaccount,uint256tokenId)externalviewreturns(uint256);/**
* @dev Returns the amount of frozen tokens of token type `id` by `account`.
*/functionfrozenBalanceOf(addressaccount,uint256tokenId)externalviewreturns(uint256);/**
* @dev Returns the `UserRecord` of `recordId`.
*/functionuserRecordOf(uint256recordId)externalviewreturns(UserRecordmemory);/**
* @dev Gives permission to `user` to use `amount` of `tokenId` token owned by `owner` until `expiry`.
*
* Emits a {CreateUserRecord} event.
*
* Requirements:
*
* - If the caller is not `owner`, it must be have been approved to spend ``owner``'s tokens
* via {setApprovalForAll}.
* - `owner` must have a balance of tokens of type `id` of at least `amount`.
* - `user` cannot be the zero address.
* - `amount` must be greater than 0.
* - `expiry` must after the block timestamp.
*/functioncreateUserRecord(addressowner,addressuser,uint256tokenId,uint64amount,uint64expiry)externalreturns(uint256);/**
* @dev Atomically delete `record` of `recordId` by the caller.
*
* Emits a {DeleteUserRecord} event.
*
* Requirements:
*
* - the caller must have allowance.
*/functiondeleteUserRecord(uint256recordId)external;}
The supportsInterface method MUST return true when called with 0xc26d96cc.
Rationale
This model is intended to facilitate easy implementation. The following are some problems that are solved by this standard:
Clear Rights Assignment
With Dual “owner” and “user” roles, it becomes significantly easier to manage what lenders and borrowers can and cannot do with the NFT (in other words, their rights). For example, for the right to transfer ownership, the project simply needs to check whether the address taking the action represents the owner or the user and prevent the transaction if it is the user. Additionally, owners can control who the user is and it is easy for other projects to assign their own rights to either the owners or the users.
Easy Third-Party Integration
In the spirit of permissionless interoperability, this standard makes it easier for third-party protocols to manage NFT usage rights without permission from the NFT issuer or the NFT application. Once a project has adopted the additional user role, any other project can directly interact with these features and implement their own type of transaction. For example, a PFP NFT using this standard can be integrated into both a rental platform where users can rent the NFT for 30 days AND, at the same time, a mortgage platform where users can use the NFT while eventually buying ownership of the NFT with installment payments. This would all be done without needing the permission of the original PFP project.
Backwards Compatibility
As mentioned in the specifications section, this standard can be fully ERC compatible by adding an extension function set, and there are no conflicts between ERC-5006 and ERC-1155.
In addition, new functions introduced in this standard have many similarities with the existing functions in ERC-1155. This allows developers to easily adopt the standard quickly.