Decouple NFT Ownership & Utility - Technical Analysis
===

### Introduction

Decoupling the ownership and utility of an NFT is a critical part in NFT financing. Currently the three main use cases are:
1. **NFT Lending**, where users deposit an NFT they own as collateral to get loans via overcollateralization and keep the usage rights (e.g. PFP) of the collateralized NFT.
2. **NFT Renting**, where users deposit a rental fee to the protocol/platform and get usage rights of the NFT for a certain period of time.
3. **NFT Buy Now Pay Later (BNPL)**, where the users deposit a down payment to the protocol/platform and get usage rights of the NFT. The transfer of the true ownership happens when the user completes all the remaining payments, and the liquidation happens when 1. *the user defaults* 2. *the NFT price drops below the health factor*.

This article will primarily focus on the latter two use cases, as both help the users access and enjoy the utility of NFTs, and aims to discuss trade-offs of different solutions from a technical point of view.

At a high level, solutions in decoupling ownership and utility of NFTs can be classified into two main categories: **on-chain** (e.g. wrapped NFTs, smart contracts, smart wallets, new contract standard, etc.) and **off-chain** (e.g. MPC wallet). Generally speaking, on-chain solutions are *permissionless* and *interoperable*, but *less scalable* and *vulnerable to hacking*, while off-chain solutions are more *scalable* and *manageable* (a.k.a secure), but rely on users’ *trust* to a centralized custody.

### NFT Rentals

#### Double Protocol - ERC-4907 token standard
[ERC-4907](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4907.md) is a rental NFT standard proposed by Double Protocol, with its core idea *dual roles*. In addition to the **owner** of the NFT, ERC-4907 proposes an additional role, the **user**, as an extension to ERC721 contracts. The user role has a validity period and the lease will automatically terminate after expiration without any on-chain operations.

At the implementation level, ERC-4907 includes an additional struct `UserInfo` and a mapping `_users`(key = `tokenId`, val = `UserInfo`) to store the address of the user role and the exipration timestamp.

struct UserInfo 
{
    address user;   // address of user role
    uint64 expires; // unix timestamp, user expires
}

mapping (uint256  => UserInfo) internal _users;

<!--  -->

The ERC-4907 interface has three functions.
1. `setUser` to allow the owner of the NFT set the address and expiry of the renter(`user`).
2. `userOf` to get the user of the NFT by `tokenId` if not expired.
3. `userExpires` to get the expiry of the current renter(`user`) by `tokenId`.

The `_beforeTokenTransfer` function in ERC-721 is also overwritten to check if the owner and receiver are different person and delete the current `user` if there is one before the token transfer happens.

<!--  -->
ERC-4907 is a significant innovation in attemping to provide permissionless interoperability for NFT rentals. However, it has notable limitations in its flexibility, especially in the BNPL use case.

1. **Scalability and Adoption**. As a new token standard (extension to ERC-721), ERC-4907's approach is highly dependent on the adaptations of NFT projects and applications. `ownerOf(tokenId)` is a native function in ERC-721, whereas `userOf(tokenId)` is a newly defined function from IERC-4907. For instance, if an NFT project (or dapp) has a check on if the user is the `owner` of the NFT, the `user` defined in ERC-4907 does not have the access until additional checks and adaptions have been made.
2. **Liquidation and Renter Protection**. In overcollateralized lending (e.g. AAVE, Compound) scenerios, liquidation is a necessary mechanism to protect liquidity providers and the lending pool when 1. *the renter defaults* 2. *the price of the collatorized assets drastically drops* (a.k.a Health Factor < 1). The collateralized asset usually gets locks in a smart contract (`owner` be a smart contract) and ready to get liquidated (`transfer()`). Unfortunately the user-expiry model in ERC-4907 is very unfriendly to the liquidation mechanisms because the user immediately lose the rights to use once the liquidation (transfer of NFT onwership) happens, and this can happen anytime before the expiry. In other word the renter's rights cannot get sufficiently protected in this design.

#### reNFT - smart contract
* reNFT uses a fully on-chain smart contract solution in docoupling the ownership and utility via its [registry](https://github.com/re-nft/registry) smart contracts. So far reNFT has released two versions:
- V1 for **collateralized rental** (no integration needed, full custody), where the NFT will transfer the NFT to the wallet of the renter, meaning that the renter can do anything he/she wants with the rented NFT, and hence collateral is required to compensate the lender if the NFT is not returned.
- V2 for **collateral-free** rental (integration needed, non-full custody), where NFT projects or games need to integrate reNFT SDK to check the registry smart contract for the renter role, but is a lot more friendly for users lacking the initial funds.

In collateralized rental, the lender sets the 1. *the daily rental price `dailyRentPrice`* 2. *the NFT collateral price* `lendAmount` 3. *max rental period* `maxRentDuration` for initiating a lending, and the renter sets the duration `rentDuration` in days and pays the rental fee + the collateral fee to the reNFT's escrow smart contract. The reNFT's escrow smart contract holds the renter's collateral and the renter gets full custody of the rented NFT.

In collateral-free rental, the lender sets the 1. *the daily rental price `dailyRentPrice`* 2. *max rental period* `maxRentDuration` (no need for *the NFT collateral price* ) for initiating a lending, and the renter sets the duration `rentDuration` in days and pays the rental fee (no need for *the collateral fee*) to the reNFT's registry smart contract. The reNFT's registry contract holds the rented NFTs and assigns **renter role** to the renter. To use it, the integrated project/protocol will check the renter role from the reNFT registry contract and assign relevant role or benefits to the inherent of NFT to the renter.

A lot more flexible than standards, but
1. Scabalibity and Adoption.
2. Rental periods have been subdivided to a daily basis and offers more flexibility, intrinsicaly still the renting model.
1. Cross-chain interoperability and scalability.
2. Cost in maintaining the smart contracts or getting exploited.

#### Rentable - smart wallet
In [Rentable](https://github.com/rentable-world/rentable-protocol) V2's version, in addition to rentable contracts, Rentable provides an additional layer of WalletConnect competible smart wallets to allow rentals in any WalletConnect enabled dApp with no integration efforts.

Rented NFTs stay secured in the smart wallet because they cannot be withdrawn by the renter and they get back to the Rentable smart contracts when the rental ends. the renter can prove the ownership of its Rentable Smart Wallet via WalletConnect and so effectively use the rented assets in any platform which supports it. But, cannot withdraw.

- attemps to solve proof of onwership instead of additional renter role. Avoid additional necessity of check for extra role (e.g. user).
- solves the dapp integration issues -> better composability

#### Prom - smart wallet

#### Capsid - ERC-721D token standard
Capsid introduces a new concept **Non-Fungible Rights** (which are by themselves NFTs) issued by NFT owners to grant rights to use the NFT.
[ERC-721D](https://github.com/SolitaireNFT/ERC-NFT-with-ACL/blob/master/EIP%20proposal.md)

1. Use a uint256 to represent the new ACL(Access Control List) of NFT to users -> different permission level.
2. Keep the ownership (ownerOf()), but the ability to transfer may need some more permission.

Rationale:
- owner should be able to give other users one or multiple permissions, without transferring the ownership.
- The permission list is encoded into a u256 integer -> flexibility for developers
- “proof of rights” NFTs to the licensee in the “grant” function.

#### Cardinal - smart wallet

### Summary
<!-- | Project | Description | Test Text |
| :----: | :----: | :----: |
| Header | Title | Here's this |
| Paragraph | Text | And more |
| Paragraph | Text | And more |
| Paragraph | Text | And more |
| Paragraph | Text | And more |
| Paragraph | Text | And more | -->

### NFT BNPL
#### Cyan - wrapped NFT
#### Pine - wrapped NFT
#### Cedar - MPC wallet