Last year in March, Beeple made headlines when one of its artwork ‘The First 5000 Days’, got sold for $69,346,250. An astronomical amount for digital art. Besides, the pace at which art tokenization is gaining acceptance is quite intriguing. And it is not just art that is getting tokenized. From simple collectibles for fun to real-world physical objects like real estate, fashion, license, certification, etc., anything that can be termed an asset is getting tokenized. A real-world asset, a non-fungible token (NFT) denotes virtual ownership of material goods.
Assets are a good source of revenue. Be it real or tokenized, they always open up new revenue streams. NFT is no different. Anyone can now rent out these NFTs with a trustless and secure blockchain network. It is happening with art- venues that have started creating digital art galleries and renting out NFT art, and it is a legitimate way of displaying high-value NFT for a short period.
Other areas like car rental have also started exploring NFT opportunities. But its implementation and deployment require a detailed plan. In this blog, I have explained steps that one should adopt before going live with the service.
Tokenising real-world assets can also bring opportunities for great passive income sources. One can rent out these NFT’s with a trustless and secure blockchain network. Not only real-world assets, renting digital assets have its benefits too. Various venues are starting to create digital art galleries, and rental NFT service creates less friction for serving galleries and venues that want to display original NFT artwork legitimately. Renting service could show benefit to those who are trying to build their name in the NFT space and want a high-value NFT for a short period.
Basics of Renting an NFT Car
Startups have started showing interest in the idea of renting out an NFT car. In fact, some of them have launched their own setup to enjoy first mover’s advantage. One such is CurioDAO. This startup has recently announced the listing of Mercedes AMG GTS as one car that users can rent.
Any rental car owner can tokenize their vehicle as an RCT (Rental Car Token) that is bound to an Ethereum account. They can further go ahead and invite other users to create tokenized reservations on such RCT. Following are the steps that a guest user adopts to rent a car.
- A guest user wanting to rent a car can look for the RCT token id.
- Check the car’s availability for the desired time period.
- RCT token owner decides the rent price.
- If the guest is okay with terms and conditions, then he/she can pay the rent price and reserve it..
- Upon reservation, the guest user will receive a Reservation token (REZ), representing the guest’s rental rights over the reserved period.
Choosing the Right Architecture Design
I have used the ERC809 standard to make my RCT tokens rentable. ERC809 allows creating an API that can further allow any rival NFT to be rented. The NFT is considered rival in this case, if simultaneously having the NFT prevents access to other individuals.
While the ERC-809 standard caters to rental rights, it does not tokenize them. ERC-1201 is another standard that aims to tokenize such rental rights and thus allow the rental rights to be easily exchanged between different parties. Much of my implementation of car rental is inspired by this blog. Here, the author proposes an improvement over the existing ERC1201 standard. The ERC-1201 rental tokens mostly duplicate ERC721 functions with a rental prefix, significantly hindering this contract’s interoperability. The ability to display, transfer, and trade access rights (reservation token) are more desirable than performing these operations to the management (RCT token). Under this approach, we would need to rebuild the wallet and exchange to support ERC1201—the author proposes a paired smart contracts architecture: ERC809 and ERC809Child, both inheriting ERC721.
Notice ERC809 and ERC809Child are relatively simple and missing the reserve function, this is intentional. Just like ERC721 does not have mint function as part of the standard, the reserve action has a lot of variables that we cannot account for: whether the user pays now or later, what auxiliary data is required at the time of reservation, whether the reservation is instantly accepted or requires further approval, etc. With such an amount of variance, it is challenging to design a reserve interface that is useful across implementations.
How I Implemented?
I have used the Remix IDE to edit and deploy the contracts. Many of the user interfaces and library sources that I found were written in older versions of Solidity, so I updated it to Solidity 8.0. Follow this GitHub link to the source code of use case implementation.
The RentalCar.sol is the contract to which any end-user directly interacts. It represents and manages the rental car token (RCT) and the reservations booked on the rental car. The Reservation.sol contract holds the reservation token (REZ) and provides functionalities to maintain various states in the reservation lifecycle. There are multiple states that a reservation can take on during its lifetime, which are as follows:
- Reserved – Rental car is reserved
- PickedUp – Car is picked up by the renter
- Returned – The renter reservation is complete & returns car , rental car owner acknowledges the car return, and all payments are processed
- Cancelled – When the reservation is canceled
The diagram below overviews the flow of the car rental lifecycle.
The rent price charged at the reservation is based on the number of rental hours. Along with the rent price, the guest user has to deposit a collateral amount which is refunded when the reservation is completed. The reservation lifecycle starts when a guest user books a rental car reservation. From here, it can proceed in three ways:
- The car is picked up within the reservation period and safely returned to the owner. The rental car owner acknowledges the return and completes the reservation cycle. The rent fee is transferred to the owner’s account, and the renter reverts the collateral.
- The car is not picked up, and the reservation period is over. The rental car owner marked the reservation as completed. The rent fee is transferred to the owner’s account, and the collateral is reverted to the renter.
- Reservation canceled before pick up. For now, there is no cancellation charge. All the rent fee and collateral is refunded to the renter’s account on cancellation.
How I Deployed?
Instead of deploying directly on Ethereum, I chose its side chain – Polygon. Ethereum, for a long time, has been facing issues related to high gas fees, which is not compatible with; dApps like Uniswap. Other high-performing blockchains like Binance Smart Chain, Polkadot, and Solana may soon replace Ethereum. The scaling solution, formerly known as Matic, Polygon. It connects blockchains and decentralized applications to Ethereum via sidechains, which, instantly settles the transactions and gas fees reduces to zero.
Additionally, I made RCT tokens capable of being listed on open marketplaces like OpenSea. However, listing these NFT’s on OpenSea like marketplace won’t allow the renting feature of these tokens yet. OpenSea can only transfer the entire ownership of the token, not the rental rights. For the trade rental rights, we would require a customized marketplace specific to the reservation of NFT and capable of working with ERC809 contracts.
Below are the steps that I followed to deploy contracts on Polygon and integrate Polygon – OpenSea:
- Two essential things are necessary to make Polygon NFT’s minting and selling on OpenSea more straightforward:
- Overriding isApprovedForAll method to allow OpenSea’s 0x exchange proxy to operate on the NFT’s contract.
- Enabling Meta-transactions to allow gas-less transactions. OpenSea has various well-documented steps to integrate with Polygon.
- Even after the integration, our NFT contract still lacks the ERC721 metadata API. ERC721 has an optional metadata extension that is used by OpenSea like platforms to display the details about the asset that the NFT represents. For the OpenSea to pull in the off-chain metadata for ERC721 assets, the contract will need to return a URI where we can find the metadata. To see this URI, we use the tokenURI method in ERC721. I’ve used the same URI used in OpenSea docs as a sample to save some work.
- Now the contract is ready to be deployed on the Polygon network. This documentation by the Polygon team will help you deploy your agreement to the Polygon Mumbai Testnet.
- Once the contract is deployed, mint a few tokens. Now we should check our minted tokens on the OpenSea marketplace. The NFT’s on the Polygon testnet contract can be listed to Opensea from this link. Just select the Mumbai testnet and provide your contract address.
Final Words
NFT renting could become a great source of passive income for NFT holders. There are already lending/renting marketplaces available for digital assets such as reNFT. It’s possible that soon we will see a similar platform for renting out real-world physical assets. The smart contract implementation I presented touches upon a car rental use case flow. There are surely possible work items ahead, such as cancellation charges, no-show fees, KYC of involved parties, etc. I look forward to including these ins the future. This set of contracts can easily be generalized to any NFT renting problem with very few modifications. Till then, stay connected and stay safe!
