This standard proposes an extension to ERC721 Non-Fungible Tokens (NFTs) to support rental and mortgage functions. These functions are necessary for NFTs to emulate real property, just like those in the real world.
Abstract
This standard is an extension of ERC721. It proposes additional roles, the right of tenants to enable rentals, and the right of lien.
With ERC2615, NFT owners will be able to rent out their NFTs and take out a mortgage by collateralizing their NFTs. For example, this standard can apply to:
NFT developers are also able to easily integrate ERC2615 since it is fully backwards-compatible with the ERC721 standard.
One notable point is that the person who has the right to use an application is not the owner but the user (i.e. tenant). Application developers must implement this specification into their applications.
Motivation
It has been challenging to implement rental and mortgage functions with the ERC721 standard because it only has one role defined (which is the Owner).
Currently, a security deposit is needed for trustless renting with ERC721, and ownership lockup within a contract is necessary whenever one chooses to mortgage their ERC721 property. The tracking and facilitation of these relationships must be done separately from the ERC721 standard.
This proposal eliminates these requirements by integrating basic rights of tenantship and liens. By standardizing these functions, developers can more easily integrate rental and mortgage functions for their applications.
Specification
This standard proposes three user roles: the Lien Holder, the Owner, and the User. Their rights are as follows:
Extensions here are provided to help developers build with this standard.
1. ERC721 Compatible functions
This extension makes this standard compatible with ERC721. By adding the following functions, developers can take advantage of the existing tools for ERC721.
Transfer functions in this extension will transfer both the Owner and User roles when the tenant right has not been set. Conversely, when the tenant right has been set, only the Owner role will be transferred.
This standard does not deal with token or value transfer. Other logic (outside the scope of this standard) must be used to orchestrate these transfers and to implement validation of payment.
Mortgage functions
The following diagram demonstrates the mortgaging functionality.
Suppose Alice owns an NFT and wants to take out a mortgage, and Bob wants to earn interest by lending tokens to Alice.
Alice approves the setting of a lien for the NFT Alice owns.
Alice sends a loan request to the mortgage contract.
Bob fills the loan request and transfers tokens to the mortgage contract. The lien is then set on the NFT by the mortgage contract.
Alice can now withdraw the borrowed tokens from the mortgage contract.
Alice registers repayment (anyone can pay the repayment).
Bob can finish the agreement if the agreement period ends and the agreement is kept (i.e. repayment is paid without delay).
Bob can revoke the agreement if the agreement is breached (e.g. repayment is not paid on time) and execute the lien and take over the ownership of the NFT.
Rental functions
The following diagram demonstrates the rental functionality.
Suppose Alice owns NFTs and wants to rent out a NFT, and Bob wants to lease a NFT.
Alice approves the setting of a tenant-right for the NFT Alice owns.
Alice sends a rental listing to the rental contract.
Bob fills the rental request, and the right to use the NFT is transferred to Bob. At the same time, the tenant-right is set, and Alice becomes not able to transfer the right to use the NFT.
Bob registers rent (anyone can pay the rent).
Alice can withdraw the rent from the rental contract.
Alice can finish the agreement if the agreement period has ended and the agreement is kept (i.e. rent is paid without delay).
Alice can revoke the agreement if the agreement is breached (e.g. rent is not paid on time) and revoke the tenant-right and take over the right to use the NFT.
Rationale
There have been some attempts to achieve rentals or mortgages with ERC721. However, as I noted before, it has been challenging to achieve. I will explain the reasons and advantages of this standard below.
No security lockup for rentals
To achieve trustless rental of NFTs with ERC721, it has been necessary to deposit funds as security. This is required to prevent malicious activity from tenants, as it is impossible to take back ownership once it is transferred.
With this standard, security deposits are no longer needed since the standard natively supports rental and tenantship functions.
No ownership escrow when taking out a mortgage
In order to take out a mortgage on NFTs, it has been necessary to transfer the NFTs to a contract as collateral. This is required to prevent the potential default risk of the mortgage.
However, secured collateral with ERC721 hurts the utility of the NFT. Since most NFT applications provide services to the canonical owner of a NFT, the NFT essentially cannot be utilized under escrow.
With ERC2615, it is possible to collateralize NFTs and use them at the same time.
Easy integration
Because of the above reasons, a great deal of effort is required to implement rental and mortgage functions with ERC721. Adopting this standard is a much easier way to integrate rental and mortgage functionality.
No money/token transactions within tokens
A NFT itself does not handle lending or rental functions directly. This standard is open-source, and there is no platform lockup. Developers can integrate it without having to worry about those risks.
Backward compatibility
As mentioned in the specifications section, this standard can be fully ERC721 compatible by adding an extension function set.
In addition, new functions introduced in this standard have many similarities with the existing functions in ERC721. This allows developers to easily adopt the standard quickly.
Test Cases
When running the tests, you need to create a test network with Ganache-CLI:
ganache-cli -a 15 --gasLimit=0x1fffffffffffff -e 1000000000
Since the external contract will control lien or tenant rights, flaws within the external contract directly lead to the standard’s unexpected behavior.