In our world, renting is a very common thing. Everyone have seen their parents renting a house or a car from someone. Or renting their house to someone. Renting a physical asset is very common and has a very easy process to do.

In the decentralised world, renting an asset can be a little bit tricky. Lands and houses in the blockchain and cryptocurrency world are NFTs. We all know what NFTs are and if you are not with this term, you can go to this link and have a look at my other article about this term.

So, what if you have an NFT land in a game and you want to rent it to someone and get some income from it? How can you do that with ERC 721 tokens? Is it really possible to do that?

Well, in one word, NO. Renting an NFT is happening through centralised authorities like the game itself, and it is not submitted on the blockchain. So, what to do now? If you do not trust the centralised game or authority, what should you do?

ERC 4907: Rental NFT, ERC-721 User And Expires Extension

ERC 4907 is designed to rent NFTs on the blockchain. All the transactions are submitted on the blockchain and you can trust these transactions on the blockchain. In these situations, it makes sense to have separate roles that identify whether an address represents an “owner” or a “user” (renter from) and manage permissions to perform actions accordingly.

Some projects already use this design scheme under different names such as “operator” or “controller” but as it becomes more and more prevalent, we need a unified standard to facilitate collaboration amongst all applications.

Furthermore, applications of this model (such as renting) often demand that user addresses have only temporary access to using the NFT. Normally, this means the owner needs to submit two on-chain transactions, one to list a new address as the new user role at the start of the duration and one to reclaim the user role at the end. This is inefficient in both labour and gas and so an “expires” function is introduced that would facilitate the automatic end of a usage term without the need of a second transaction.

Specification

The Solidity interface should look like the code below:

interface IERC4907 {

    // Logged when the user of a NFT is changed or expires is changed
    /// @notice Emitted when the `user` of an NFT or the `expires` of the `user` is changed
    /// The zero address for user indicates that there is no user address
    event UpdateUser(uint256 indexed tokenId, address indexed user, uint64 expires);

    /// @notice set the user and expires of a NFT
    /// @dev The zero address indicates there is no user
    /// Throws if `tokenId` is not valid NFT
    /// @param user  The new user of the NFT
    /// @param expires  UNIX timestamp, The new user could use the NFT before expires
    function setUser(uint256 tokenId, address user, uint64 expires) external;

    /// @notice Get the user address of an NFT
    /// @dev The zero address indicates that there is no user or the user is expired
    /// @param tokenId The NFT to get the user address for
    /// @return The user address for this NFT
    function userOf(uint256 tokenId) external view returns(address);

    /// @notice Get the user expires of an NFT
    /// @dev The zero value indicates that there is no user
    /// @param tokenId The NFT to get the user expires for
    /// @return The user expires for this NFT
    function userExpires(uint256 tokenId) external view returns(uint256);
}

The userOf(uint256 tokenId) function MAY be implemented as pure or view.

The userExpires(uint256 tokenId) function MAY be implemented as pure or view.

The setUser(uint256 tokenId, address user, uint64 expires) function MAY be implemented as public or external.

The UpdateUser event MUST be emitted when a user address is changed or the user expires is changed.

The supportsInterface method MUST return true when called with 0xad092b5c.