Conditional Lending Pool (CLP)

Perpetual Instrument

Problem Statement: There are two incumbent lending pool models, both of which offer less valuable product experiences for all parties. The problem stems from the supply side, which trickles up to the demand side

1. Protocol developers do their diligence and accept collaterals they deem fair. Ex: compound,aave, etc. Problem: Devs can't possibly underwrite ALL kinds of assets, which fails to generate liquidity on many. It also fails to align incentives with LPs and assessors

2. LPs price risks & supply to lending markets that they think are fairly priced. Ex: Euler Finance, Rari Fuse. Problem: Most LPs aren't sophisticated to do so. And when less is known, (generally)less is supplied.

We can see both models can't scale in the advent of a vibrant digital asset economy. They result in less capital being supplied, which in aggregate increases inefficiency and the cost of capital for the demand side.

Our core thesis is that our underwriting system solves these problems and creates grounds for capital supply to efficiently meet demand. It efficiently allows decentralized entities to underwrite all kinds of assets in an incentive-compatible manner and allows LPs to delegate the difficult task of risk pricing to these entities in exchange for a premium.

A conditional lending pool is a lending pool where its collateral could be any set of conditions. An exotic set of collateral such as illiquid tokens or NFTs is one instance. Another could be a certain credit criterion(assuming a composable identity layer).

A RAMM's vault could host a lending pool where its collateral is either a singleton or a combination of long-tail assets such as NFTs or illiquid tokens. A lending pool that satisfies the approval criterion will be supplied by the vault, and capital can additionally be supplied/withdrawn by the managers after its inception.

Diagram for Conditional LendingPool instrument after it is approved. Black line is capital flow of underlying of vault(i.e USDC, WETH)

A utilizer will propose a new lending pool to be created along with a set of conditions that are required to borrow from the pool. In the long-tail assets instance, he/she will propose a set(could be a singleton set) of collateral that is going to be accepted by the lending pool, along with the pool parameters, where borrowers can then collateralize their loans with these assets. Specifically, he will propose the following parameters

// 1. CollateralInfo[], for each collateral. Includes params
// such as maxBorrowAble amount per unit collateral, collateral address, etc
struct CollateralInfo

// 2. Interest Rate Parameters
struct RateParams

// 3. Tranche Parameters applicable for all perpetual instruments, parametrizes the junior vs senior profit split 
struct PoolData

Note that the field inputs are simplified via a UI, and many parameters are automatically chosen.

The managers' key goal will be to identify whether the pool will stay solvent, and the risk(liquidity of collateral(s)/creditworthiness) given the potential reward(interest rate curve). In the case of judging the soundness of collateral, he will decide whether a proposed LTV and interest rate parameters are suitable for its given liquidity. If he does so, he will buy longZCB for this pool instrument.

Whenever he issues longZCB, the collateral used for that issuance + capital from the vault will be allocated to the lending pool. Whenever he redeems or sells longZCB, the protocol withdraws funds from the lendingPool back to the vault, and the manager will realize his profit. See postApproval for an illustration.

The exact amount of withdrawn and supplied capital for longZCB redeemed and issued is computed as below;

$$Withdrawn/Supplied \space Collateral$$

$$= (1 +LeverageFactor ) * longZCB Amount *longZCBPrice$$

Where LeverageFactor is a PoolData parameter, and determines the degree of leverage longZCB holders incur, which is inversely related to the amount of first-loss capital.

longZCB returns

The redemption price of longZCB is going to be determined by the interest accrued by the lending pool compared to the promisedReturn, where promisedReturn is the amount of returns allocated to the senior tranche and is a function of the pool's utilization rate. The more the pool accrues compared to the promisedReturn without incurring bad debt, the higher the yield of longZCB will be. However, if the pool accrues less yield compared to the promisedReturn(which occurs with unliquidated defaults), longZCB 's APR will be less than the promisedReturn. More information in longZCB returns section.

Managers as Oracles

A third-party oracle is not a necessity as the managers themselves would be responsible for accurately pricing the risk of the collaterals. At a fundamental level, a manager would not supply liquidity to a pool, and would instead withdraw from the pool, when the maxBorrowableAmount per collateral exceeds their perceived price of the collateral. The maxBorrowableAmount would also dynamically adjust as a function of the amount of longZCB issued/redeemed. More information is in the Managers as Oracles section.

Decentralized Interest Rate Dynamics

Recall that as more managers buy longZCB for a lending pool, more capital would be supplied to the lending pool by its parent vault. All else being equal, this would decrease the utilization rate and consequently lower the price of capital. Likewise, as more managers redeem longZCB for a lending pool, capital would be withdrawn to its parent vault. All else being equal, this would increase the utilization rate and the price of capital.

Liquidity Efficiency

Under this system, active participation from the managers will allow all lending pools connected to a vault to reach an equilibrium state with similar risk-adjusted returns, which mitigates inefficiencies associated with liquidity fragmentation. If one lending pool has a higher utilization rate compared to its risk(high apr vs risk of collateral), managers will redeem(withdraw capital) from another lending pool with a lower risk-adjusted return(either low utilization rate or more risky collateral) and supply to the higher pool. This allows the lending pools to have a completely isolated structure(one collateral per token to be borrowed) without sacrificing efficiency.

What happens during defaults?

In collateralized lending pools of money market protocols, defaults don't lead to a loss from a pool's perspective as the collateral can be liquidated in open markets. RAMM's system does not assume such liquidity for all collateral; if a proposed collateral is indeed illiquid, a manager would have to decide if there would be enough external auction interest when defaults do occur. Otherwise, the redemption price of longZCB would be significantly lower than the price at which they bought them.

When a liquidation threshold is met, an auction will be triggered to liquidate the collateral. Any value captured by the auction would be directed back to the lending pool, and the redemption price of longZCB would be adjusted in accordance with this added value.

Ultimately, it is the interest of the manager to determine whether the pool will stay solvent, given its accepted collaterals or conditions, and whether its interest rate curve fully prices their risk

Read more about how our Conditional LendingPool innovates upon existing lending pools in our blog .