With Facebook’s recent announcement, all eyes are on the metaverse. VC interest in crypto-gaming is at an all-time high, and traditional studios are rolling out their NFT strategies. But if we are to crystallize the vision of the metaverse as laid out in Snow Crash, Ready Player One, SAO… there still are fundamental building blocks that must be built and adopted.

In this series, we hope to introduce such building blocks - the economic primitives of the metaverse - and in doing so, make clear their absolute necessity. We want to particularly focus on utilities that have not achieved widespread attention and adoption - hence we will leave it up to the reader to explore fractionalization and NFT collateralized loans themselves.

We will first briefly go over the definition of the metaverse, and reiterate NFT’s role in securing digital property rights. We then outline the fundamental limitation of smart contracts and introduce different implementations of renting and lending that are currently live.

As always if you enjoy this article please follow us on Twitter @0xtaetaehoho and @0xcesare.

If you are already familiar with the concept of the metaverse and crypto’s role in securing digital property rights, we suggest skipping to Part 3. In the first two sections, we quote directly from existing literature and provide the reader with links to texts that explain these concepts with far better clarity than what we are capable of.

Disclosure: @0xtaetaehoho purchased an NFT issued by reNFT during the writing of this article.

Table of Contents

1. What is the Metaverse (a quick recap)
2. Crypto’s Role in the Open Metaverse (an ultra-quick recap)
3. Economic Primitives in the Metaverse
4. Renting and Lending
5. The Contract Inheritance Model
6. The Collateralized Model
7. The Uncollateralized/Project-Side Integration Model
8. The Future?
9. Credits

What is the Metaverse?

The Metaverse is, in the words of Matthew Ball:

a massively scaled and interoperable network of real-time rendered 3D virtual worlds which can be experienced synchronously and persistently by an effectively unlimited number of users, and with continuity of data, such as identity, history, entitlements, objects, communications, and payments. (emphasis added)

For a visual representation, check out a clip from Ready Player One:

Many thinkers (including Zuck) believe that this will be the natural next step in the digitization of our lives and of human networking.

“The Metaverse represents our next great milestone as a networked species.” - Piers Kicks

If you would like to read more about the Metaverse we suggest the following resources:

https://www.matthewball.vc/all/forwardtothemetaverseprimer
https://futuristspeaker.com/future-trends/the-history-of-the-metaverse/
https://editorial.superrare.com/2021/09/10/into-the-metaverse-a-short-history/

Crypto’s Role in the Metaverse

For an in-depth exploration we suggest - Into the Void: Where Crypto Meets the Metaverse by Piers Kicks:

What NFTs enable for the first time is a decentralized, universal digital representation and ownership layer through which scarcity, uniqueness, and authenticity can be transparently managed.

In order for the economic component of the Metaverse to flourish, there first has to emerge shared standards and protocols that are widely recognized for the issuance and movement of virtual goods.

To paint a general picture, the metaverse is a vision of fully immersive shared virtual spaces as the culmination of progress in networking and digitization. NFTs secure the digital property rights in this ecosystem, allowing us to create artificial digital scarcity that will underlie virtual economies and create unprecedented economic value on the internet.

From here, it is an easy mental mapping from reality to the digital world. The objects we own and interact with are NFTs, our currency is crypto, and the contractual relationships that dictate the flow of both are smart contracts.

Economic Primitives

At the moment, the main roadblock to this vision is that NFTs don’t come with the rich functionality required to replicate complex economic relationships we rely on in the real world.

This is in part due to the inherent differences between smart contracts and paper contracts. Because in reality, the state is responsible for arbitration and enforcement of contracts, the parties partaking in a contract are all known, and because there is flexibility in renegotiation and termination, contracts don’t have to be fully edge-case exhaustive to be secure. A general agreement can be carried out in good faith with edge-case arbitration outsourced to the judicial system, judgments passed on centuries of precedent/common law, against two parties who are known to each other.

In the case of smart contracts, this is not the case. Most of the time we have no idea who our counterparty is, and the existence of one bad actor can jeopardize the agreement (a hacker). There is limited flexibility in renegotiation and termination especially as user growth scales, and contracts have to be fully edge-case exhaustive. You can’t rely on common law and a larger judicial system to arbitrate unforeseen issues (we are unsure how UETA/E-SIGN apply here). This is the fundamental limitation to implementing the complex economic relationships we see in the real world today - and also why the first innovations of smart contracts have come in defi where conditional logic can cover more and where all information required already lives on-chain.

But the vast majority of what we interact with is non-fungible and the most important protocols of the metaverse will be those that can create these difficult-to-replicate functionalities we experience in reality within the virtual spaces of our future.

Economic Primitives of the Metaverse is an ongoing series where we hope to introduce protocols that are building towards those primitives, upon which we’ll see a Cambrian explosion of applications the likes we’ve seen in de-fi. We’ll start off with a discussion about the importance of renting and lending, then discuss 3 existing solutions, going over their technical implementation details and how they work in an accessible manner. We then hope to introduce future applications and potential use cases of these protocols.

The Importance of Renting and Lending

In Q1 of 2019, S&P500 companies collectively reported $503B of operating lease liabilities and 69B of financial lease liabilities. This includes office space, land, industrial machinery, data centers, network equipment, vehicles, laboratory equipment, restaurant, and hospitality equipment, construction equipment… etc. Even Facebook (Meta) - a pure software product company, has $11B USD in operating lease liabilities on their balance sheet.

If it’s anywhere closer to home, every day I wake up in a rented apartment, ride a rented Citi Bike to school. I’ve rented cameras for photoshoots, cabins from Airbnb, surfboards, motorcycles, video games, DVDs, U-hauls, storage spaces. For reference, US renters paid $512B in rent in 2019, and $4.5T in the past decade.

We may or may not notice while going about our daily lives, but the renting and lending of nonfungible items and access to services underlie one of the most frequently used economic constructs in our lives, and as the examples above show, most of what we interact with in this world are non-fungible.

Yet, there are few existing implementations of this economic primitive. This is primarily because of the aforementioned limitations of smart contracts. NFTs are at all times “owned” by one wallet (unless fractionalized). And whereas in reality, it is easy to implement relationships where the owner, the user/tenant, the bank… all have different rights in relation to the asset in question, this is hard once there is only one unique pseudonymous owner-user.

In the following section, we introduce three existing and live implementations working on this issue. There are a couple of protocols we are keeping a close eye on that we hope to cover in the future as they open-source their contracts.

Contract Inheritance Model (EIP2615)

The first concrete attempt at implementing a solution to trustless renting and lending of NFTs was in April 2020 with the proposal of “EIP-2615: Non-Fungible Token with mortgage and rental functions”, by Kohshi Shiba. The project initially had strong backing, and a working group was created by the Blockchain Game Alliance with support from Yield Guild Games, Delphi Digital among others. Although the project did not end up moving beyond an initial implementation, it is still of interest to introduce the challenges unique to this problem and understand how proposed solutions have evolved.

One of the main challenges of implementing rental functions with the ERC721 standard is that it only defines the Owner role, limiting the complexity and range of its functionality. At best an approved address can transfer this role, but there are no other natively available roles with differentiated access/rights to said NFTs.

EIP2615 proposes ERC2615: an extension to the ERC721 token standard that supports rental and mortgage functions through defining additional roles: the Lien Holder, the Owner, and the User. These three roles enable more complex relationships to form, like allowing tenants to list items for rental and giving owners the right to lien. By making ERC2615 backward compatible with ERC721, ERC2615 NFTs would still be compatible with protocols interacting with standard ERC721s.

Lien: a right to keep possession of property belonging to another person until a debt owed by that person is discharged. (In a mortgage this is the bank)

Let’s dive deeper into ERC2615 and the functionalities that it unlocks. As we mentioned, the standard proposes three roles: a Lien Holder, an Owner, and a User.

1. The lienholder has the right to transfer the owner and user roles.
2. The owner has the right to transfer the owner and user role
3. The user has the right to transfer the user role.

All rental and mortgage logic can be expressed with these three roles and their respective rights, with one small addition: the executor; another smart contract that sets the conditions for agreement between the different parties (eg. renter and rentee) and is responsible for handling role changes, token transfers and enforcing the consequences if one of the parties breaks their side of the agreement. The EIP purposefully leaves this part unimplemented and in the hands of developers working on top of this standard.

Renting using EIP2615

To add additional clarity, let's walk through the rental process of an ERC2615 token. We will assume that a rental contract has been deployed to handle the renting logic and to enforce a rental agreement.

1. Suppose Alice wants to rent an NFT she owns. Alice will create a listing on the rental contract and approve the same contract for setting the tenant (user) role.
2. Bob wants to rent Alice’s NFT. So Bob will fill the rental request, and the tenant (user) role is set to Bob.
3. Alice is now unable to transfer the tenant role.
4. Bob is expected to pay rent for the duration of the rental agreement; this will be handled by the rental contract (the executor).
5. If Bob breaches the rental agreement, the rental contract will revoke the Tenant role from Bob and set it back to Alice
6. If instead, we arrive at the end of the rental period, the tenant role will be transferred back to Alice and both parties walk away satisfied

With ERC2615, the idea that only one person “exclusively owns” an NFT is no longer true. Imagine now that within the ledger in the sky that maps NFTs to addresses, we now have a mapping not just to an owner but to a renter, a lienholder, and an associated rental contract. When a project needs to understand who the current “user” of the NFT is, it can read if the renter exists. If there is a renter that is different from the owner, the project recognizes the renter as the effective “owner” - the wallet that has the right to use the NFT, while if it does not, it defaults to the owner. This is a theme that will come up later.

An example of setting an address as the executor address:

function approveTenantRight(address to, uint256 itemId) public {
        address owner = ownerOf(itemId);
        require(to != owner);
        require(msg.sender == owner || isApprovedForAll(owner, msg.sender));
        _tenantRightApprovals[itemId] = to;
        emit TenantRightApproval(to, itemId);
    }

function setTenantRight(uint256 itemId) public {
        require(msg.sender == getApprovedTenantRight(itemId));
        _tenantRightAddress[itemId] = msg.sender;
        _clearTenantRightApproval(itemId);
        _clearTransferApproval(itemId, 1); //Reset transfer approval
        emit TenantRightSet(msg.sender, itemId, true);
    } 

The smart contracts that implement ERC2615 were deployed on Github in October 2020, however, the EIP has since remained stagnant. We conjecture that this is because the logic required to implement the three roles and who has permission to transfer them is complicated and quite gas inefficient.

On the positive side, EIP2615 NFTs are self-custodied by the owner, reducing concerns of smart-contract risk that is present in the next two solutions.

The Collateralized Solution (reNFT)

One gas-efficient way to tackle lending has been reNFT’s collateralized solution. reNFT is a year-old protocol born out of the Chainlink spring 2020 hackathon and the Avalanche Money Dance hackathon.

Listing your NFT for Rent (Collateralized Solution)

A lender places within the reNFT smart contract an NFT, setting a specified collateral and daily rental fee required to rent the NFT. The renter then provides the commensurate collateral and rental payment upfront for their intended duration to borrow said NFT. Once they return the NFT, all payments are delivered to respective parties.

For a reader who is curious, we’ve included below a high-level but technical overview of rental and lending implementations for the reNFT collateralized solution. Feel free to skip/skim this section and go directly to “Uncollateralized Project-side Integration”. reNFT supports batch lending of multiple ERC721s and ERC1155s but we will assume that we are lending out and borrowing a single NFT.

Table of Contents for Technical Implementation

1. Placing an NFT up for Rent
2. Renting an NFT
3. Return a Rented NFT
4. The Uncollateralized Solution

Alice places an NFT up for rent.

• Alice, who wants to lend out her NFT, chooses a total permitted rental duration, a daily rental price, the required collateral, and a payment token. These inputs are passed as parameters to the lend function.

 function lend(
        address[] memory _nfts,
        uint256[] memory _tokenIds,
        uint256[] memory _lendAmounts,
        uint8[] memory _maxRentDurations,
        bytes4[] memory _dailyRentPrices,
        bytes4[] memory _nftPrices,
        IResolver.PaymentToken[] memory _paymentTokens
    ) ... 

• The function first creates a structure to aggregate inputted information. Then calls handlelend.
• Handlelend creates and stores on the blockchain information about outstanding lends, with each lender’s information - their address, lent amount, the max rent duration that they specified, the daily rent price, the payment token, and the collateral required.

function handleLend(CallData memory _cd) private {
        for (uint256 i = _cd.left; i < _cd.right; i++) {
            ensureIsLendable(_cd, i);

            LendingRenting storage item =
                lendingRenting[
                    keccak256(
                        abi.encodePacked(
                            _cd.nfts[_cd.left],
                            _cd.tokenIds[i],
                            lendingId
                        )
                    )
                ];

            ensureIsNull(item.lending);
            ensureIsNull(item.renting);

            bool nftIs721 = is721(_cd.nfts[i]);
            item.lending = Lending({
                lenderAddress: payable(msg.sender),
                lentAmount: nftIs721 ? 1 : uint8(_cd.lentAmounts[i]),
                maxRentDuration: _cd.maxRentDurations[i],
                dailyRentPrice: _cd.dailyRentPrices[i],
                nftPrice: _cd.nftPrices[i],
                paymentToken: _cd.paymentTokens[i]
            }); ....

• Finally, the NFT is sent to the reNFT contract.

safeTransfer(
  _cd,
  msg.sender,
  address(this),
  sliceArr(_cd.tokenIds, _cd.left, _cd.right, 0),
  sliceArr(_cd.lentAmounts, _cd.left, _cd.right, 0)
);

The NFTs that you see on the platform are held by the reNFT contract. This of course means that there is a risk of losing any outstanding loans if the reNFT contract is compromised. The team is aware of this issue hence building other solutions which we will expand on in the future once they are live.

Bob rents from Alice.

• Bob chooses Alice’s NFT and specifies a rent duration. Upon approving the payment tokens, he calls the rent function.
• Similar to lend this first creates a structure to store information including a lending Id (a nonce that specifies how many times the contract has been called - atm 241), rental duration, and the NFT in question. Then we call handlerent.

    function handleRent(CallData memory _cd) private {
        uint256[] memory lentAmounts = new uint256[](_cd.right - _cd.left);

        for (uint256 i = _cd.left; i < _cd.right; i++) {
            LendingRenting storage item =
                lendingRenting[
                    keccak256(
                        abi.encodePacked(
                            _cd.nfts[_cd.left],
                            _cd.tokenIds[i],
                            _cd.lendingIds[i]
                        )
                    )
                ]; ...

• Handlerent similarly creates and stores on the blockchain information about this outstanding rent, storing information about the renter address, the rent duration, and the time when the rent was executed. Each lending and renting pair are stored in the same place (a mapping of the hash of the information to a lendingrenting struct).

    ...     item.renting.renterAddress = payable(msg.sender);
            item.renting.rentDuration = _cd.rentDurations[i];
            item.renting.rentedAt = uint32(block.timestamp);

• The collateral and total renting fees (daily renting fees * days renting) are then sent to the contract for escrow. To note here is that payment to the contract is done at the start when renting. These payments are later distributed upon completion but renting does require locking up not just the collateral but the total rental fees.
• Finally, the contract transfers the NFT from itself to the renter.

Returning the NFT

Once Bob has finished slaying Elvarg using a borrowed dragon hunter’s crossbow, has sufficiently shown off his CSGO skins, and has fully harvested returns on metaverse land, he returns the NFT by terminating his rental prior to the end of his maximum allowed rental duration set by the lender.

Upon return, all payments are now distributed to related parties. The renter pays only for the total duration that he actually rented the NFT for and receives the collateral back. The lender receives the daily rent price * the total time the NFT loan was outstanding. From this total value transferable to the lender, the protocol takes a small fee. At the moment, this fee is set to zero.

Finally, it deletes the renting record and returns the NFT to the reNFT contract from which Alice can claim her NFT back.

One limitation of this implementation is that if the price of the NFT rises above the price of the collateral, Bob has no incentive to return the NFT. The protocol, therefore, encourages setting a very short max rental duration and very high collateral. Within a highly volatile NFT market, this is a dangerous aspect of collateralized renting for prospective lenders and suboptimal UX for prospective renters.

If you want to learn more about how Alice might claim the collateral in escrow if Bob fails to return the NFT in time, and the specifics of the various functionalities we mentioned above, we highly suggest you check out reNFT’s Github.

Uncollateralized Project-side Integration (reNFT Uncollateralized)

Ideally - as is also true in defi - the golden standard of renting and lending is uncollateralized and trustless. As we saw the ERC721 standard is not by itself complex enough to support these primitives, and though introducing a new standard ala EIP2615, with more functionalities, is the cleanest solution, it incurs high switching costs, and at the moment has not been accomplished at an implementable complexity/cost on mainnet.

To solve this problem within the current paradigm, reNFT has built a registry contract which implements renting logic by holding a lender's NFT in escrow and tracking who is renting the item.

To rent an NFT currently in escrow on the reNFT registry contract, the renter just has to call the handleRent function, which then creates a log in the registry that records the renter's address, the rented amount, the rent duration and the timestamp of when it was rented.

function handleRent....

rentings[rentingIdentifier] = IRegistry.Renting({
  renterAddress: payable(msg.sender),
  rentAmount: uint16(cd.rentAmount[i]),
  rentDuration: cd.rentDuration[i],
  rentedAt: uint32(block.timestamp) ....

It also handles payments for only the renting price * duration (no collateral) which is also escrowed in the contract for distribution later. Crucially, the NFT lives in the registry smart contract until the lender decides to redeem it; the registry simply tells us whether an item is being rented and by whom at any given time.

This has some advantages over the collateralized solution: since the NFT always lives on the contract, we ensure greater gas efficiency - the renter does not have to claim or return the NFT.

Furthermore, the renter is assured by logic coded into the smart contract that if he is currently renting an NFT, the lender won’t be able to redeem it from escrow. Similarly, the lenders are certain that they can maintain ownership of the NFT at all times and can, if the NFT is not rented, choose to redeem it from the smart contract. There is no risk, like in the collateralized solution, that the renter does not give back the NFT even if the NFT becomes very valuable within the renting duration.

The uncollateralized solution, however, requires one new piece: project-side integration. If the lender escrows the NFT to the registry, the ERC721 contract will point to the registry smart contract as the owner. If the NFT is currently out to rent, it is necessary for the NFT project to investigate and see first, whether the NFT is out to rent, and second, who is renting the NFT, to determine the “owner” of the NFT at a specific period in time.

To ensure that this is as seamless as possible for projects, the reNFT team has built an SDK which the projects can use to ping the registry smart contract for who the current “owner” is. To enable uncollateralized renting, projects simply check the ERC721 owner, and if it points to the registry contract, ping the SDK for information on whether the NFT is rented and if so, who the renter is.

We didn’t provide more in-depth technical specifications of the registry contract because it is very similar to the collateralized lending contract. If you would like to learn more check out the registry contract here, or the SDK here.

Natively Integrated Uncollateralized Lending

As we’ve mentioned the two biggest security risks for reNFT are the token collateral and the escrowed NFT that are both stored on their smart contract. The uncollateralized lending solution we described still requires an NFT to be escrowed. reNFT eventually aims to eliminate these risks by utilizing an idea we saw in EIP2615: create an extension of the ERC721 and ERC1155 token standards to increase the functionality of what users can do with their NFTs. This solution is still being worked on and we hope to write about it and similar solutions involving wrappers soon!

Future of reNFT and Renting/Lending

reNFT has recently completed a strategic seed raise of 1.5M USD led by Animoca Brands, with participation from MetaCartel, Scalar, Play, Lattice, Gabby Dizon (Founder of Yield Guild), Sebastien Borget (Founder of The Sandbox), and Eric Aresenalt (Rarible).

In the immediate future, they plan to provide lending and renting infrastructure for NFT games. Today a large part of the Axie ecosystem are players who are scholars. Managers “lend” their accounts to scholars by providing them access to the email/PW/QRcode associated with a Ronin account that owns the 3 Axies required to play the game. The process is entirely manual and relies on mutual trust. The scholar must trust the manager to pay him/her while the manager must trust the scholar to not violate Axie’s terms of service, which can result in a ban.

If reNFT were to integrate with Ronin, Axie owners would now be able to trustlessly manage scholarships - Axie owners would list their Axies to rent for a maximum duration, at a rent price (the scholar split). Scholars can obtain scholarships in the open market and consequently have better price discovery.

Their partnership with YGG, Animoca Games, The Sandbox, and Rarible show that this is the strategic short-term direction that the team is taking. And already they are in talks with multiple NFT games for possible integrations.

In the long run the team is working to become the plug and play economic primitive of the metaverse.

Want to rent land on Embersword, or Decentraland to host a party (scene as a service) - go on a raid in Mirandus with the best weapons you can’t afford - access exclusive airdrops, community events that are NFT gated - gain royalties from 3LAU’s newest album, rent the IP to biotech research? reNFT is working to be the underlying protocol powering all this activity.

Or even in the far future - perhaps when we’re paying our rent in our metaverse homes, vacationing in metaverse log cabins on Airbnb, producing directly within the virtual space metaverse native art/music/NFTs (a metaverse factory?) with rented industrial equipment (metaverse operating leases????), reNFT hopes to power these more complex economic relationships.

Other Potential Use Cases

Already through the collateralized solution, one can short NFT futures. If a renter believes that an already listed NFT will go down in price during the renting period, they can place collateral and pay a funding rate (the daily rental fee) to borrow the NFT, sell the NFT, and buy it back to return it upon termination of the rental period.

Furthermore, in the original EIP721, NFTs were presented to potentially represent loss assets - loans burdens and other responsibilities. For instance, if upon NFT rental or ERC20 LP, an NFT representing this position (similar to an LP token) were created, reNFT could enable bundled lending and borrowing markets on top of these NFTs, creating the possibility for other securitized products.

Another interesting and amusing idea builds on the fact that renting and lending in the real world is constrained by trust. For larger items (cars, houses...etc) we sign contracts that prevent us from certain actions. But when we’re borrowing smaller items - pencils for an exam, tools from your neighbor - this is all based on trust.

I recall reading some years back something along the lines of:

“an average hand drill is only used for 10 minutes in its entire lifetime but more than half of American households own one”.

But even more saliently - how many times have you just bought scissors, staplers, pencils because you were too lazy to borrow them from a friend? Or a camera, guitar...etc. Perhaps with trustless rentals, we’ll have significantly less material waste - if such a concept even exists in the metaverse - as we’re seamlessly able to borrow items from anyone.

As written in EIP721 - ”We considered a diverse universe of assets, and we know you will dream up many more.”

Conclusion:

Renting and lending is a new economic primitive of the metaverse that will enable richer economic relationships in virtual spaces.

If the metaverse is a singular point in time when our virtual lives matter more than our physical lives, the aggregate value of our virtual goods will exceed that of physical goods. The total economic value secured by transactions in virtual goods will then exceed that of “physical” GDP - but to achieve this vision we need innovations in smart contracts that allow us to replicate complex economic relationships available in reality. Overall, we’re very excited for all the protocols that’re creating building blocks for these complex relationships and hope to write about more of them as they come live on mainnet, L2s, or other layer 1s.

In the next installment of this series, we’ll be exploring protocols working on asset-backed financing and mortgage functionalities with NFTs. When EnterDAO and Rentable open-source their smart contracts we’ll be out with pieces on those projects as well. If there are any other implementations we have missed please let us know! We’d love to explore more and compare the merits and demerits of each.

If you would like to support more student writing like this please consider purchasing this as an NFT! If you would like to support more work done at Columbia consider donating to blockchaincolumbia.eth.

---

Credits

We’d like to thank @ballmathew, @AndrewSteinwold, @Cooopahtroopa, @cdixon, @jessewldn, @ShaanVP, @ljxie, @gabusch, @Shaughnessy119, @pierskicks, @dberenzon for helping formulate our understanding of the metaverse and NFTs’ role within it.

We’d especially like to thank @nickev123, @AlgorithmicBot from reNFT who readily provided us with information when we reached out about writing this piece.

Cover image credits to @bestofvidgames and @artemilse_ for the art.

Disclaimer: The above content is for informational purposes only, you should not construe any such information or other material as legal, tax, investment, financial, or other advice.