Protocol Overview

FluidNFT Protocol V1
FluidNFT Protocol V1 is deployed as a peer-to-pool (P2Pool) NFT Lending protocol. This is a decentralised, non-custodial protocol designed to democratise NFT lending for any collection.
System Diagram

Main Contracts

The main contracts in FluidNFT Protocol V1 and their purposes are:


The main entry point into the FluidNFT Protocol. Most interactions with FluidNFT will happen via the LendingPool, including:


The main address register of the protocol, for particular markets. The latest contract addresses should be retrieved from this contract by making the appropriate calls.


Contains a list of active AddressProvider addresses, for different markets.


The yield-generating, tokenised deposits used throughout the FluidNFT protocol. They implement most of the standard EIP-20/ERC20 token methods with slight modifications, as well as FluidNFT specific methods including:
All fTokens also implement EIP-2612, which via the permit() function enables gas-less transfers and single transaction approve + actions.

Stable and Variable Debt Tokens

The tokenised borrow positions used throughout the FluidNFT protocol. Most of the standard EIP-20/ERC20 methods are disabled, since debt tokens are non-transferrable.
For more information, see the Debt Tokens section.

Supporting Contracts

The following contracts should generally not be interacted with directly, but are used throughout the FluidNFT protocol via contract calls.

Collateral Manager

Implements actions involving the management of collateral in the protocol, including:
The above functions should only be called via the main LendingPool contract.


Provides configuration functions for the LendingPool contracts. It also has a number of important functions:
  • Activates / Deactivated reserves
  • Enables / Disables borrowing for a reserve
  • Enables / Disables using an NFT as collateral
  • Enables / Disables variable rate borrowing for a reserve
  • Freezes / Unfreezes reserves
  • Updates a reserves's Loan-to-Value(s)
  • Updates a reserve's liquidation threshold
  • Updates a reserve's liquidation bonus
  • Updates a reserve's grace period(s)
  • Updates a reserve's auction duration
  • Updates a reserve's interest rate strategy address
  • Activates / Deactivates all functions of a LendingPool in emergencies
For all of the above functions, relevant events are emitted to the blockchain. Anyone can monitor these changes to know when values have been modified or added/removed.

Interest Rate Strategy

Holds the information needed to calculate and update the interest rates of specific reserves.
Each contract stores the optimised base curves using the corresponding parameters of each currency. This means that there is a mathematical function which determines the interest rate of each asset pool, with interest rates able to change based on the amount of borrowed funds and the total liquidity (i.e. utilisation) of each reserve asset pool.
The parameters for the optimised base curves are:
  • baseVariableBorrowRate
  • variableRateSlope1
  • variableRateSlope2
  • stableRateSlope1
  • stableRateSlope2
The interest rates are calculated depending on the available liquidity and the total borrowed amount.

NFT Price Oracle

A trust-minimised proprietary oracle designed to optimise trust-minimisation and update costs; operating at approximately 20% of the cost of integration with Chainlink, with support for any collection, trait and tailored token-level pricing.

Obligation Receipts

Obligation Receipts are smart redeemable NFTs that grant the holder rights to the underlying collateral of a loan once its associated debt balance has been repaid. These can be freely held, sold or transferred.

Library Contracts

Various libraries are also used throughout the FluidNFT Protocol (to be made available in our Github).

Risk Mitigation Strategies

Due to the nascency of the space, FluidNFT has been designed to support even the most volatile assets. This requires a few constructs at the protocol level. These are as follows:

Isolation Pools

Isolation pools are used to protect against risk contagion from one collateral or asset effecting lender funds in other pools. These are lending pools that restrict reserves to one single collateral-asset pair and are fundamental to our risk model and protocol design.

Dutch Liquidity Auctions

In the case of loans going into default, outside of the grace period, liquidation auctions may be called to avoid bad debt accumulating to the pool. We use Dutch auctions to avoid potential liquidation cascades by potentially flooding the market with below-floor NFTs. In addition, to avoid MEV attacks, lenders receive a significant discount to the current Dutch auction price.