👨‍🚒Risk Mitigation Model

A Lending & Borrowing Platform has many risks associated with it. Here are a few risk mitigation techniques Cedro Finance uses to protect the protocol from unfortunate events.

Fractionalizer

using CULT, we virtually merge the liquidity of assets across different chains. There could arise a scenario where one of chains or a particular asset that is a part of CULT could collapse. This would lead to depegging of the ceToken which could be hazardous.

When an asset collapses, there are going to be losses to multiple parties involved. With the fractionalizer algorithm, we maximize the fairness of loss distribution across all the parties involved.

Even though we unify the multichain assets deposited from multiple chains and mint the same ceToken, we still keep an internal balance variable named balancePerChain[user][chainId] where user is the user address and chainId is the id associated with a particular chain.

Lets take a few scenarios.

Deposit

If a user deposits x amount from a chain with chainId A, then after minting the ceToken, we update the variable as

balancePerChain[user][A] += x

Withdraw

If a user wants to withdraw x on chain A, then there can be a few possibilities.

Case 1: When balancePerChain[user][A] > x,

balancePerChain[user][A] -= x

Case 2: When balancePerChain[user][A] < x,

Say the initial condition is,

balancePerChain[user][A] = a

balancePerChain[user][B] = b

balancePerChain[user][C] = c

balancePerChain[user][D] = d

Total deposited = (a + b + c + d)

First we deduct all of the deposit made from A,

balancePerChain[user][A] = 0

Then, we proportionately deduct the liquidity from each chain,

balancePerChain[user][B] = b - (x-a) * (b/(b+c+d))

balancePerChain[user][C] = c - (x-a) * (c/(b+c+d))

balancePerChain[user][D] = d - (x-a) * (d/(b+c+d))

Lets say the asset on chain B starts depegging. Now we need to make sure it doesn't affect the whole system. To do this, the protocol declares the asset on chain B as dead which is essentially a circuit breaker for a token.

Taking the same scenario as above, but with chain B be declared as dead, we have,

balancePerChain[user][A] = 0

balancePerChain[user][B] = b

balancePerChain[user][C] = c - (x-a) * (c/(c+d))

balancePerChain[user][D] = d - (x-a) * (d/(c+d))

The asset can either be later declared undead or can be separately withdrawn using withdrawDeadTokens() method.

Supply and Borrow cap

During the event of an asset collapse or a big dump leading to an asset collapse, the liquidity pools in our protocol are largely affected. To mitigate this, a supply and borrow cap is introduced which ranges from 0 to 1. It is the ratio of the total amount of an asset supplied/borrowed to the total liquidity of the protocol. This cap is decided based on the safety ratings given to an asset by the protocol.

Volatility cap

In case an asset price starts getting highly volatile i.e. outside the range of the volatility cap, the asset operations will be temporarily frozen. The investigation committee will quickly look into the case and analyze the situation. The operations will be unfrozen once they confirm that the volatility isn't caused by the protocol fault. This cap is decided for each asset based on it time-weighted price, stability, reputation, market cap, etc.