Rental NFT, NFT User Extension
ERC-5006 proposes a new type of NFT that can be leased or rented out to others for a specific period of time. This is achieved by separating ownership and usage rights, and creating "expirable" NFTs that can be automatically withdrawn upon expiration through smart contract. The proposal also introduces a new role called "user" which represents permission to "use" the NFT, but not the ability to transfer it or set users. This allows for separate permissions and actions for owners and users of the NFT. The proposal aims to create a decentralized, collateral-free, and purely "on-chain" leasing model for NFTs, which could disrupt the way people trade and use NFTs.
Video
Original
Abstract
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 pragma solidity ^0.8.0; interface IERC5006 { struct UserRecord { uint256 tokenId; address owner; uint64 amount; address user; uint64 expiry; } /** * @dev Emitted when permission for `user` to use `amount` of `tokenId` token owned by `owner` * until `expiry` are given. */ event CreateUserRecord( uint256 recordId, uint256 tokenId, uint64 amount, address owner, address user, uint64 expiry ); /** * @dev Emitted when record of `recordId` are deleted. */ event DeleteUserRecord(uint256 recordId); /** * @dev Returns the usable amount of `tokenId` tokens by `account`. */ function usableBalanceOf(address account, uint256 tokenId) external view returns (uint256); /** * @dev Returns the amount of frozen tokens of token type `id` by `account`. */ function frozenBalanceOf(address account, uint256 tokenId) external view returns (uint256); /** * @dev Returns the `UserRecord` of `recordId`. */ function userRecordOf(uint256 recordId) external view returns (UserRecord memory); /** * @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. */ function createUserRecord( address owner, address user, uint256 tokenId, uint64 amount, uint64 expiry ) external returns (uint256); /** * @dev Atomically delete `record` of `recordId` by the caller. * * Emits a {DeleteUserRecord} event. * * Requirements: * * - the caller must have allowance. */ function deleteUserRecord(uint256 recordId) 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.
Test Cases
Test cases are included in test.js.
Run in terminal:
cd ../assets/eip-5006
npm install
npx hardhat test
Reference Implementation
See ERC5006.sol
.
Security Considerations
This EIP standard can completely protect the rights of the owner, the owner can change the NFT user, the user can not transfer the NFT.
Copyright
Copyright and related rights waived via CC0.
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all