Protocol design
Regarding our objective of building a scalable, decentralized and easy-to-use credit solution, we have taken design decisions for our protocol to perfectly match our vision.
Peer-to-Pool approach
In general, two primary models have gained traction in the NFT/RWA lending spaces, each with its own advantages and considerations:
Peer-to-Peer (P2P) lending : individual lenders directly engage with individual borrowers. This approach eliminates the need for an oracle or a protocol to determine the NFT price and/or the appropriate loan amount. Lenders assume the responsibility of assessing the associated risks and deciding the loan amount they are willing to provide. While this model allows for flexibility and tailored-made loan terms, it presents two majors downsides: (i) challenges in risk management for lenders due to limited diversification and poor liquidity management and (ii) very limited scalability as it requires a lot of active individuals lenders to make the protocol work.
Peer-to-Pool lending : lenders request loans from liquidity pools. The loan amount is determined by the protocol, based on the floor price which is determined by a price oracle. This approach offers a more standardized process for lending which is sufficient for most users, but can be less performing for rare and illiquid NFTs, or less optimized for leverage traders. But it offers great liquidity and risk management (due to diversification), and high scalability.
We have chosen a peer-to-pool approach because we want to build a scalable and standardized credit solution. Each pool is dedicated to one collection, which gives LPs the choice to select the collections they're willing to finance.
Loan characteristics
Loans are defined by three characteristics: the amount, the tenor (length) and the rate.
Loan amount
For secured loans, the loan amount is often defined by the LTV ratio.
The Loan-to-Value (LTV) ratio corresponds to the amount lent, divided by the assessed value of the collateralized asset. As an exemple, when one wants to buy a house, he will pay upfront 10% of the price and borrow 90%, which leads to a LTV of 90%. LTV is a key ratio in financing because it is one of the most important metrics for risk management.
In Nemeos protocol, the LTV depends on the product and is fixed for each liquidity pool, allowing LPs to manage their risk. For split payment products, the LTV is set to 25% of the floor price.
Tenor
In most of DeFi protocols, loans operate on a perpetual basis, which is particularly beneficial for NFT traders, allowing them to select the optimal moment to exit their positions. Interests are compound daily until the loan is paid back. In most cases, monthly payments are not set up for these loans, meaning that borrowers are required to repay the entire loan amount to get the asset back.
In Nemeos, the duration of the loan is pre-determined by product, like in a mortgage. For a pay in four installments service, the loan lasts 6 weeks.
Interest rate
Both fixed and variable interests exist in DeFi, and there is multiple mechanisms and rules. As most of consumer-oriented loans are at fixed rate, we have kept this characteristic for each loan. Two consecutive loans can have a different rate, but once the loan is issued, its rate remains fixed. The interest rate is determined by LPs, and corresponds to weighted average of LPs' preferred rate by deposited liquidity.
Liquidity management
Deposits can be done at anytime in each liquidity pools, except for specific operations.
Withdraws depend on two things:
The vesting, depending on the rate decided by the LP ; the higher the rate is, the longer the vesting is. The objective is encourage LPs to deposit their liquidity at a lower rate.
Once the vesting period over, each LP can withdraw its full position, as long as there is available liquidity in the pool. As an example, if the pool is worth 200$ thanks to 2 deposits of 100$, and if a loan of 150$ has been made, each LP can withdraw up to 50$ (first come first served). The rest of the liquidity will be available with the repayments of the user.
Last updated