Protocol - Renting


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

There are two major domains in the protocol:

  • the vaults

  • the renting logic

The Renting a game asset in the context of this protocol means that a user deposits the asset in a vault and the




Reference implementation


Vyper 0.3.9

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 the renter's wallet for a specific duration

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

General considerations

The current status of the protocol follows certain assumptions that must be validated as more information about LOTM is released.

The assumptions are the following:

  1. delegation is supported using

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

  3. because does not support NFT-level delegation and only supports wallet-level delegation, one vault per NFT needs to be created


Below are the smart contract audits performed for the protocol so far:







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

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

  • NFT owners deposit NFTs in the protocol, which means a vault is created for each NFT

  • NFT owners define the terms of the rentals: price and minimum/maximum rental duration

  • renters starting rentals

  • renters closing rentals before the due date

  • NFT owners claiming unclaimed fees

  • NFT owners withdrawing NFTs from the protocol

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, 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.


Whenever a rental starts, the renter pays the full amount of the rental upfront. This amount is locked in the NFT vault 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 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. claim: the NFT owner claims unclaimed fees

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

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

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

Last updated