Protocol - Renting

Introduction

This protocol is targeted at LOTM from Yuga Labs. The protocol serves as a trustless way for LOTM players to rent game assets from users.

Overview

Version	Language	Reference implementation
V3	Vyper 0.3.10	https://github.com/Zharta/lotm-renting-protocol-v1

There are two major domains in the protocol:

• the vaults

• the renting logic

The renting of an NFT in the context of this protocol means that:

1. an asset owner deposits the NFT in a vault, setting the terms of the rental: price and minimum/maximum rental duration

2. a user (renter) selects the NFT put for rental and starts the rental by paying for the rental upfront

3. the vault where the NFT asset is escrowed delegates it to a renter's specified wallet for a specific duration

4. once the duration of the rental is reached, the rental finishes

In addition, the vaults can be represented as NFTs which can be exchanged between users, either directly or through a marketplace. This also means the vaults can be used by other NFT-FI protocols as collateral.

General considerations

The current status of the protocol follows certain assumptions.

The assumptions are the following:

1. delegation is supported using warm.xyz

2. the current version of warm.xyz if the same as the last verified version seen here

3. because warm.xyz does not support NFT-level delegation and only supports wallet-level delegation, the protocol needs to create one vault per NFT

4. since the protocol is running using $APE as the payment token, the protocol also supports the use of APE Staking by users

Architecture

As previously stated, there are two domains of the protocol:

• the vaults implemented in VaultV3.vy

• the renting logic implemented in RentingV3.vy

• the ERC721 interface of the vaults is implemented in RentingERC721V3.vy

Users and other protocols should always interact with the RentingV3.vy contract. The RentingV3.vy contract is the entry point of the protocol and it is responsible for:

• NFT owners depositing NFTs in the protocol, which means the protocol creates a vault for each NFT

• renters starting rentals

• renters extending rentals

• renters closing rentals before the due date

• NFT owners claiming rental fees

• NFT owners withdrawing NFTs from the protocol

• NFT owners can stake their APE tokens in the official APE Staking protocol to earn rewards

• NFT owners can exchange and trade their vaults

Vaults and NFT deposits

Each NFT put for rental needs to be in its own vault (see the 3rd point in General considerations). This means that when an NFT owner wants to deposit an NFT in the protocol, the NFT owner may need to create the vault prior to depositing the NFT. If the vault for that specific NFT has already been created before, it can be reused.

NFT owners do not need to create the vaults themselves, the protocol will create the vaults when needed.

The protocol creates the vaults using minimal proxies and the CREATE2 opcode. This means that when a vault for a specific NFT needs to be created, the protocol is able to compute the destination address of the vault before creating it and the user may approve the NFT to be transferred. Therefore, creating the vault and depositing the NFT can be done atomically.

Listing conditions

The listing conditions are signed by the NFT owner and stored offchain. The listing conditions are composed by the price per hour and the minimum and maximum rental duration. Whenever there is a protocol interaction that requires them, Zharta's infrastructure signs the owner-signed listing conditions:

• RentingV3.start_rentals

• RentingV3.close_rentals

• RentingV3.extend_rentals

• RentingV3.withdraw

• RentingV3.claim

In order to help owners secure their assets, there is an addition method RentingV3.revoke_listing that allows the owner to set a timestamp after which listings set before it are no longer valid.

Rentals

Whenever a rental starts, the renter pays the full amount of the rental upfront. This amount is locked in the RentingV3.vy contract until the end of the rental. Once the rental finishes, the rental amount is released to the NFT owner for claiming. Since the protocol is using warm.xyz which supports setting a specific timestamp for the end of the delegation, the protocol computes the amount of fees that are claimable taking this into consideration. Unclaimed fees are only set explicitly for certain actions:

1. RentingV3.claim: the NFT owner claims unclaimed fees

2. RentingV3.withdraw: the NFT owner withdraws the NFT from the vault, along with any unclaimed fees

3. RentingV3.start_rentals: a renter starts the rental and the previous rental fees, if not claimed, are set explicitly as unclaimed

4. RentingV3.close_rentals: a renter may finish a rental before its due date and pays only for the time used, and unclaimed fees are explicitly set

5. RentingV3.extend_rentals: a renter may extend an ongoing rental and has to pay the rental fees for the extension upfront, and unclaimed fees are explicitly set

Roles

The protocol does support an admin role with the following purposes:

• enabling/disabling the protocol fee and its

• setting the protocol wallet that receives the protocol fee

• validating the signature passed in the RentingV3.start_rentals method

The roles are the following:

• Renting.vy:

  • admin: the protocol admin with permissions limited to set the value of protocol fees (up to a fixed limit) and the protocol wallet that receives those fees. The admin value can be changed via the propose_admin and claim_ownership functions.

  • owner: the owner of the NFT that is escrowed in the vault, which means that only this address can perform certain actions against the vault

  • vault owner: the owner of the NFT that represents the vault itself. When a vault changes ownership, the new vault owner can claim ownership of the NFT escrowed in the vault, thus changing the value of owner.

Delegation

The protocol uses warm.xyz to perform wallet-level delegation of the vaults. At any moment, at most one delegation can be active, meaning that setting a new hot wallet cancels any ongoing delegation. The usage of delegation happens as follows:

• Renter:

  • RentingV3.start_rentals: when initiating a rental, the renter specifies a delegate which will be used as the vault hot wallet for the specified rental duration.

  • RentingV3.close_rentals: if the renter cancels the rental, the delegation is also removed.

  • RentingV3.extend_rentals: if the renter extends the rental, the delegation is also extended.

  • RentingV3.renter_delegate_to_wallet: at any time that a renter has an ongoing rental is not ongoing, the renter can specify a different wallet for the delegation.

• NFT Owner:

  • RentingV3.deposit: as part of this operation, an optional delegate can be set. If not empty, it is set as the vault hot wallet without an expiration period.

  • RentingV3.delegate_to_wallet: at any time that a rental is not ongoing, the vault owner can use this function to set a new delegate as the vault hot wallet without an expiration period.