6 Ways of Making NFTs Rentable
TLDR:
1. The demand for Utility NFTs (GameFi, Metaverse) and the ability to rent them is growing. There are several different approaches to implementing this functionality.
2. A key part of enabling renting is to achieve a Division of Property Rights between the owner and the user.
3. Many solutions to achieve this division (Off-Chain Account Service, Smart Wallets, Metadata Extension) have serious drawbacks when it comes to security and development costs.
4. The best solution by far is to build the NFTs with Dual-Roles: one for the owner and one for the user.
5. For existing projects that cannot upgrade their contract so that their NFTs have two roles, the equally elegant solution of a Wrapped Dual-Roles NFT exists.
6. Because we believe Dual-Roles may be the great unlock for NFT technology to easily be rented, we’ve submitted EIP-4907 to push it as the standard for rental NFTs and strongly urge you to support it.
Table of Contents:
· 1) Introduction:
∘ What is a Division of Property Rights?
∘ The Problem with Collateral
∘ Unlocking Derivative NFT Transactions
∘ How do we achieve a Division of Property Rights?
· 2) Separation by Account Service
∘ Off-Chain Account Service
∘ The Smart Wallet (On-Chain Account Service)
∘ Axie Infinity’s Scholarship Program
· 3) Separation by Projects
∘ Dual Roles
∘ Metadata Extension
∘ Wrapped Dual-Roles
· 4) Conclusions
∘ ERC-4907: Rental NFT Standard
∘ Moving on
· 5) Glossary of Concepts:
1) Introduction:
With every new GameFi or Metaverse project, it becomes more and more apparent that NFTs represent more than just pieces of artwork to be speculated on. Whether it’s land to put buildings on in Decentraland or playable Axie units in Axie Infinity, it’s clear that their true potential lies in their ability to represent assets with utility — in the same way cars and houses have utility in our economy.
And, just like how people rent cars, it’s inevitable that the demand to rent these assets in order to use them is also growing. However, as the builders of a rental protocol, we’ve seen firsthand the technical nuance and depth of making NFTs rentable. Through our extensive research, we have identified the various patterns, pitfalls and implications of the implementations of renting NFTs in a variety of projects. It’s these findings that we would like to share with you in this article series.
In our model, the process enabling renting can be divided into three steps. First, division of property rights must be achieved. Then, a system of user rights management must be implemented. Finally, user rights trading can then be enabled. In this first article, we will explore the first step in depth.
What is a Division of Property Rights?
Owner Rights vs User Rights
In the traditional economy, there are certain expectations of what the owner of an asset with utility can do, and what a user of one can do. For example, the “user” of a rented 20,000$ violin maintains the right to play the violin (albeit temporarily) and maybe even earn money by playing with it at a prestigious concert. However, the “owner” of the violin maintains the right to sell the violin outright — or destroy it with a sledgehammer, if he so chooses.
In order to enforce that the user of the violin does not violate the property rights of the owner, the user is required to provide collateral that would be lost to the owner in the event that he does. Thus, the user of the violin is strongly incentivized to respect the rights of the owner.
However, for NFTs, simply incentivizing for property rights to not be violated is simply not enough. The very first goal of an implementation of NFT renting should be to make it impossible for ownership rights to be violated by the user in the first place. It’s this objective that we will call a Division of Property Rights. Later in this article, we will explore the different ways rental protocols and projects achieve this division and the implications of their implementations.
The Problem with Collateral
As this market is in an early stage, these property rights are often not properly separated. Take for example ReNFT’s V1.0 model, which did not split ownership and usage rights whatsoever and relied entirely on collateral as the mechanism to protect owners. Similar to a violin rental, the renter needs to, in addition to paying the rent, be able to deposit 1.5x the value of the NFT in FT currency as collateral in order to gain the right to use the NFT for a certain amount of time. If the renter does not return the NFT after expiration, the deposit will be forfeited to the original owner. The biggest advantage of this approach is that this is extremely simple to implement. However the drawbacks are glaring.
For renters, the collateral requirement is dismally prohibitive. One of the main reasons someone would wish to rent a NFT is because they are unable or unwilling to buy it. Those who wish to rent the NFT but do not possess (or are not willing to stake) 1.5x the value of the NFT in currency are shut out of this transaction completely. Those who do have that much currency may be more inclined to purchase the NFT outright!
For lenders, the risk of losing their NFT in this transaction is ever present. The renter, at any point, has the option to forfeit the collateral and run off as the new owner of the NFT. Facing this risk, many (if not most) prospective lenders would find it not worth it at all to list their NFT for potential income.
Because of these problems, it’s clear that the collateral model is extremely limiting and would have very few use cases. It also highlights the importance of achieving a division of property rights because, if it’s not possible for the user to violate the owner’s rights in the first place, there is no need for exorbitant collateral and owners would not have to bear the risk of losing their property.
Unlocking Derivative NFT Transactions
Achieving Division of Property Rights is not only the cornerstone that enables NFT rental but also the foundational Lego baseplate on top of which all sorts of transactions and derivatives can be enabled.
On OpenSea, 90% of NFT transactions are simple exchanges: ownership of the NFT for a single lump sum. In our traditional economy, transactions can be much more sophisticated. For example, we often take mortgage loans and pay in installments for larger assets such as cars and real estate. The process of amortization can span decades and during that time the buyer must be able to use the asset. As the demand for utility NFTs grows, there will also be a demand for installment payment schemes similar to this — which, of course, would require a Division of Property Rights.
The possibilities do not, by any means, end here. Free trials, Guild Management Tools and Self-Repaying Loans are among the possible derivatives that are unlocked. We will go through these possible derivative applications in the next article.
How do we achieve a Division of Property Rights?
At present, the industry does not have a clear categorization of the different ways a protocol can separate user rights and owner rights. In our analysis, they are split into three main buckets: No Separation of Property Rights(using collateral, which we have already discussed), Separation by Account Service and Separation by Projects. In the next two parts of this article, we will go through the latter two in depth. The diagram below shows how projects using each approach would distribute property rights.
2) Separation by Account Service
The first solution to separating user and owner roles is through the usage of what we will call a “Account Service”. In this model, the owner hands over access to their NFT to addresses controlled by the Account Service. If the owner of the NFT wishes to grant usage rights to others, those people must also open an account, and receive access through this entity. These Account Services can take both on-chain and off-chain forms.
Off-Chain Account Service
The first thing that comes to mind that would fulfill the role of an Account Service would be a traditional centralized server complete with usernames and passwords. It would be similar to CEX models like Binance, where people would deposit tokens into CEX wallets and, later, when they wish to conduct on-chain transactions such as withdrawals, the CEX server would call up the wallet to submit the on-chain transaction on behalf of the user.
However, the architecture of an Account Service for NFTs would have to be significantly more complicated than CEX’s. CEXs only has to handle one type of function (transfer()) while the NFT functions that an Account Service would have to handle are overwhelmingly diverse and complex. This “rights assignment” problem is absolutely problematic. The Account Service would have to differentiate between functions that represent user rights and functions that represent ownership rights. Then they would have to restrict the accessibility of each accordingly. Take for example Axie Infinity’s breed() function, which would be classified as an ownership right. The Account Service would have to identify it as such and restrict access to the user. Facing this task for every function of every NFT project integrated into the Account Service, the workload can quickly grow to become unsustainable for developers.
Other, no less debilitating issues exist with this model. A separate front end must be developed by either the Account Service or the project integrating with it — and that workload should also not be underestimated. Furthermore, lenders must fully trust the Account Service since they relinquish all control of their NFTs. As a result of this centralization, the lenders expose themselves to the risk of losing their property — whether it’s to hackers attacking the Account Service, rogue insiders or technical problems. Philosophically, it runs counter to the crypto-native ideology.
The Smart Wallet (On-Chain Account Service)
Although the CEX-esque off-chain model is technically feasible, it is riddled with problems that render it impractical and, as a result, we haven’t seen any projects that use it. However, what if you put the entire Account Service on-chain by implementing it through smart contracts? For such a model, the logic is sound. We call this model the Smart Wallet model since it is basically the familiar multi-signature wallet (like Gnosis Safe) that implements user and owner rights separation through smart contracts. Projects like Pine, 99StarZ are currently experimenting with this approach.
Like the advantages of DEX over CEX, the smart wallet model solves the problem of trust. However it is also plagued by the front end and rights assignment issues of the off-chain account service model. First, although the Smart Wallet is called a “wallet”, the front end would also need to be specifically built since there are only a limited number of dapps that would work with Smart Wallets. Second, these contract addresses have no private key, so there is no way to provide signatures. Because of this, even OpenSea does not support Smart Wallets like Gnosis Safe.
Finally, smart wallets also introduce as many problems as they solve. For example, these contracts must be upgraded whenever a new function is added. Frequent upgrades can lead to exorbitant gas consumption and security vulnerabilities.
Axie Infinity’s Scholarship Program
Even though we see that the Account Service model has many disadvantages, one in particular has seen tremendous success. That would be Axie Infinity’s Scholarship program. In their implementation, each wallet address corresponds to an account on a centralized server. When the game runs, the server reads the NFT information of the address associated with the account and synchronizes with it. Players can then play the game through the server. Since the on-chain wallets have a private key that would protect owner rights, the user’s right to play the game can be freely shared through the account on the server. Axie Infinity enables the account to be temporarily shared or “rented” with a QR code that expires in 14 days. Through this setup, a division of property rights is achieved. It’s this model that has played a major role in the spike in growth of Axie Infinity players.
That said, the Axie model has inherent limitations. For one thing, Axie Infinity has a centralized component: the game logic that must be implemented on a traditional 2.0 account system, with all its restrictions and vulnerabilities. This, of course, contradicts the vision of an open and interoperable Metaverse and makes the Axie Scholarship program a special case rather than a groundbreaking model to be replicated.
3) Separation by Projects
The second category of methods to achieve Division of Property Rights is to have projects to implement the separation themselves rather than rely on an Account Service to do it for them.
Dual Roles
The most straightforward solution in this category is to have the project add a second “user” role to the NFT as a wallet address in addition to the original “owner” role. The projects will achieve a separation of rights by granting the ability to perform certain actions according to whether an address represents an owner or an user of the NFT.
Many flagship projects already do this using different names for the user role. For example, ENS has specially added the role of “controller” that has the right to set records but cannot transfer NFTs. Similarly, Decentraland has added the role of “operator” to its LAND NFT. The operator can build scenes on LAND, but cannot sell.
However, this requires the user-related functions to be added to the NFT prior to being released, or the NFT must be upgraded with this new role. Fortunately, these tasks are very simple and can be completed easily and quickly by even slightly experienced contract engineers.
Projects then must handle rights assignment by controlling access based on these roles. This should be simple for these projects as well, since, after all, who is more familiar with what users and owners should and shouldn’t be able to do than the project creators themselves? Each project is only responsible for the property rights of their own NFT so the developer workload is minimal compared to that of an Account Service. In addition, the need for a separate front end also does not exist here since projects can simply integrate the renting feature into their own front ends.
Since other projects can also interact with the NFT’s user role directly without needing the consent of the creators, it also becomes easier to achieve permissionless interoperability where multiple projects can interact with the same NFT.
Metadata Extension
There are cases where the NFT has been deployed but cannot be upgraded so the extra user role cannot be added to it. This is when a new contract that adds the “user” information to the metadata of the NFT is needed. We call this technique “Metadata Extension”. reNFT and Rentable are both examples of projects that take this approach.
As of now, most Metadata Extension developers are not the same as those of original NFT projects. These developers often have to develop custom contracts that suit the usage rights needs of the original NFT. As a result of being created by a third party, these contracts often contain extra functions that represent business logic (such as order information). In order to get user information, the projects must carefully analyze the contract and extract the information they need.
This has several implications. First, these projects must trust that the user information returned by these third-party contracts are real and valid. Although blockchain contracts are generally open source and transparent, the time required to read the entirety of the code from beginning to end in order to ensure there are no loopholes can be staggering. Second, this increases the difficulty of development. Since user information may not have a readable interface on these contracts, projects must obtain that information they need by painstakingly analyzing details of the contract and events.
Take for example reNFT’s collateral-free contract. There are only two view functions that can access order data. For one NFT there could be thousands of orders, which makes it difficult to find which one is the one you want and get the information you want (tokenId, count, expires).
mapping(bytes32 => Lending) private lendings;
mapping(bytes32 => Renting) private rentings;function getLending(
address nftAddress,
uint256 tokenID,
uint256 _lendingID
)
external
view
returns (
uint8,
address,
uint8,
bytes4,
uint16,
uint16,
uint8
)
{
bytes32 identifier = keccak256(
abi.encodePacked(nftAddress, tokenID, _lendingID)
);
IRegistry.Lending storage lending = lendings[identifier];
return (
uint8(lending.nftStandard),
lending.lenderAddress,
lending.maxRentDuration,
lending.dailyRentPrice,
lending.lendAmount,
lending.availableAmount,
uint8(lending.paymentToken)
);
} function getRenting(
address nftAddress,
uint256 tokenID,
uint256 _rentingID
)
external
view
returns (
address,
uint16,
uint8,
uint32
)
{
bytes32 identifier = keccak256(
abi.encodePacked(nftAddress, tokenID, _rentingID)
);
IRegistry.Renting storage renting = rentings[identifier];
return (
renting.renterAddress,
renting.rentAmount,
renting.rentDuration,
renting.rentedAt
);
}
Wrapped Dual-Roles
A more elegant solution to the un-upgradable problem is to mint a new NFT containing the user information that “wraps over” the original. Similar to the wrapping of ETH into an ERC-20 compliant wETH, the code for this solution is concise and remains decoupled from the business logic of a Third-Party Metadata Extension solution.
The “wrap” contract is extremely simple and the interface is easy to use. This method does not have the problems (complexity, trust requirement, development costs etc) that plague projects using other techniques. The wrap method will not cause double spending problems because, like wETH, each wNFT corresponds with an existing NFT on a 1-to-1 basis. In addition, the wrap concept of wETH has already been widely recognized by the industry, which will make adoption of wNFTs seamless.
4) Conclusions
ERC-4907: Rental NFT Standard
EIP-4907: Add a time-limited role(user) with restricted permissions to ERC-721 tokens
As the demand for utility NFTs continues to grow, it will become clearer and clearer that having Dual-Roles in the NFT is the best architectural choice if NFTs are intended to be rentable. Not only is it the easiest to implement and the most secure, it’s also the most composable(as we get into in a future article). The sooner this model can be adopted as the de facto standard way to build NFTs, the faster the innovation in the NFT ecosystem will grow.
However, despite the fact that many projects already implement a dual-role model to separate user and owner, there has yet to be an agreed upon standard for naming and implementing this standard. Like with the Tower of Babel, this makes collaboration difficult and slows down the adoption of this concept. This is why we have proposed ERC-4907, which adds a user role in addition to the owner role to ERC-721 and adds the function expires() that would end user rights to facilitate renting.
The expires function is a crucial inclusion because, without it, the owner must manually reclaim the user rights after the rental duration is over. Doing so is not only inconvenient for the owner (especially those renting out multiple assets simultaneously) but also unnecessarily expensive in gas. This is inspired by ENS.
If this standard is widely adopted, it would accelerate the growth of the renting market and become the Lego Baseplate on top of which all sorts of interesting and unique transaction types can be built.
interface IERC4907 {
// Logged when the user of a token assigns a new user or updates expires
/// @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);
}
Moving on
As we can see here, almost all of the approaches we have gone over in this article are being tried by various projects. While all have potential, only the Dual-Roles and Wrapped Dual Role methods can claim to be easy to implement, secure and trustless. Because of these advantages, we expect that this is the future of how Division of Property Rights will be achieved.
Once user and owner property rights are separated, the next problem that needs to be explored would be, how do we keep track of who has those rights? While a simple registry would be enough for the ownership rights of standard ERC-721 tokens since most will only have one owner, it often isn’t enough to track user rights because there could be multiple users that have access to user rights at different points in time. In the next article in this series, we will explore the second major objective to be achieved in order for NFTs to be rentable: User Rights Management.
5) Glossary of Concepts:
- Division of Property Rights — concept of separating a NFT’s user rights from owner rights
- Owner Rights — functions that an owner of a NFT can call or actions an owner can take transfer(), Axie Breed Function, etc.
- User Rights — functions that can be called by a renter/user/borrower of an NFT (playing with a borrowed Axie in Axie Infinity, building on rented LAND in Decentraland)
- Account Service — An escrow entity that would implement Division of Property Rights
- Off-Chain Account — A theoretical model of a centralized Account Service akin to CEX’s
- Rights Assignment — Problem of controlling the accessibility of functions based on whether they represent a user right or an owner right.
- Smart Wallet — Implementing an Account Service through smart contracts
- Separation By Project — An approach to renting where projects implement a Division of Property Rights themselves (usually through Dual Roles)
- Dual Roles — A renting-friendly NFT architecture that contains two wallet address values as roles: an Owner Role and a User Role
- Metadata Extension — A solution for renting non-upgradable NFTs that emulates Dual Roles by adding the user role to the NFT metadata via a smart contract.
- Wrapped Dual Roles — Another solution for renting non-upgradable NFTs where the Dual Role information is minted on a new “wNFT” that “wraps” over the original. Similar to ETH and wETH
*If you are also building around NFT rental, or have feedback on this article, please reach out!
*And shout out to Jesse for the help.
