# Mochi Whitepaper
## Autonomously Governed Decentralized Stable Currency Protocol Fully-Backed by Long-Tail and Yield-Bearing Asset Markets
### [Twitter](https://twitter.com/MochiDeFi) | [Discord](https://discord.mochi.fi) | [Telegram](https://t.me/MochiDeFi) | [Website](https://mochi.fi)
⚠️⚠️⚠️ **WORK IN PROGRESS** ⚠️⚠️⚠️
---
## Abstract
*Mochi Protocol is a cross-chain, autonomously governed decentralized stable currency protocol fully-backed by a wide variety of crypto assets, including long-tail and yield-bearing assets. Mochi offers governance-free listing and condition-based stable currency minting capacity. Mochi adjusts collateral specific vault parameters such as collateral factor, liquidation factor, credit cap and stability fees automatically based on liquidity depth (calculated using a variety of reliable and stress-tested data sources) and credit utilization to provide the most capital efficient overcollateralized loans to users, while minimizing risk of shortfall for the protocol to protect and maintain solvency. Mochi unlocks productivity in a diverse variety of collateral, including long-tail, staked, wrapped, and yield bearing assets, to unlock new value and accelerate DeFi innovation.*
---
# Table of Contents
- [Introduction](#Introduction)
- [Mochi Vaults](#Mochi-Vaults)
-- [Stablecoin: USDM](#Stablecoin-USDM)
-- [Supported Collateral](#Supported-Collateral)
-- [Listing Collateral on Mochi](#Listing-Collateral-on-Mochi)
-- [Autonomous Vaults](#Autonomous-Vaults)
- [Vault Parameters](#Vault-Parameters)
- [Risk Factor Categories](#Risk-Factor-Categories)
-- [Collateral Factor (CF)](#Collateral-Factor-CF)
-- [Liquidation Factor (LF)](#Liquidation-Factor-LF)
-- [Stability Fees](#Stability-Fees)
--- [Origination and Accrual Fees](#Origination-and-Accrual-Fees)
- [Credit Caps](#Credit-Caps)
-- [Formulae](#Formulae)
- [Liquidations](#Liquidations)
-- [Liquidation Trigger](#Liquidation-Trigger)
-- [USDM Flash Loans](#USDM-Flash-Loans)
-- [Collateral Realization](#Collateral-Realization)
- [Chain State Storage Relay (CSSR)](#Chain-State-Storage-Relay-CSSR)
-- [Adapter CSSRs](#Adapter-CSSRs)
- [Mochi in a Whitepaper](#Mochi-inside-a-Whitepaper)
# Introduction
Mochi is a decentralized stablecoin protocol which enables ungated, condition-based listing of collateral assets. Mochi users can leverage listed collateral to mint the USDM stablecoin through Mochi Vault smart contracts. Collateral specific vault parameters such as collateral factor, credit cap, liquidation factor and stability fees are algorithmically defined and dynamically updated based on total on-chain liquidity and credit utilization - therefore, Mochi vaults are autonomous. This allows a much wider variety of crypto assets, including long-tail and less liquid tokens, with otherwise healthy markets, to get listed, enable collateralization, and mint the USDM stablecoin.
The USDM stablecoin is soft pegged to the USD and Mochi helps maintain the peg with dedicated, highly capital efficient stable pegged-asset pools. This value is fully-backed by overcollateralized vaults with credit parameters assigned based on total on-chain liquidity and credit utilization.
# Mochi Vaults
A vault is a smart contract which allows users to deposit accepted token collateral and mint the USDM stablecoin. Only users depositing listed collateral types may open vaults. To avoid liquidation, vaults must maintain their collateral ratio above the liquidation ratio.
## Stablecoin: USDM
USDM is a decentralised stablecoin which uses overcollateralization to maintain its value and peg; it is backed by the TVL in all Mochi vaults.
Autonomously governed vaults will ensure all debts can be safely liquidated to repay loans.
## Supported Collateral
At launch, ERC-20 and ETH network LP tokens will be accepted. In the next iterations, Mochi aims to offer support for a wide range of assets.
## Listing Collateral on Mochi
New protocols with over a minimum amount of combined liquidity (as decided by the DAO) across decentralized exchanges in accepted pairs (WBTC, ETH, DAI, USDC, USDT, USDM) can request to be listed after at least 4 weeks of maintaining that liquidity. The minimum liquidity through the past 4 week period must be maintained above the minimum amount (which can be set by the DAO).
Further, promotion and demotion through the Risk Factor Categories will also be based on the minimum liquidity through the past 4 week period, and all credit parameters will be updated accordingly.
## Autonomous Vaults
DeFi requires a protocol that can match the rapid pace of development and innovation in the space. It should be dynamic enough for its users to practice unencumbered, flexible finance.
Mochi fills this need by expanding access to credit to a much wider range of protocols and automating decision making by algorithmically setting listing requirements and vault parameters.
Mochi vault parameters are algorithmically set and dynamically updated based on Chain-State Storage Relay and other data sources.
Protocols are grouped into Risk Factor Categories which determine the Collateral Factor, Liquidation Factor, and (along with utilization) the Stability Fees.
# Vault Parameters
Mochi Vaults are separated into 6 different Risk Factor Categories with the parameters listed in the table below:
| RFC | Credit Cap | CF | LF | Min SF | Max SF | Liq Fee | Liquidator Fee |
| --- | ----------------- | --- | --- | ------ | ------- | ------- | ---------- |
| 1 | 5% circ. market cap | 90% | 95% | 2.33% | 3.50% | 4.5% | 0.5% |
| 2 | Calculated based | 80% | 85% | 2.33% | 4.00% | 10% | 1% |
| 3 | on safe slippage | 75% | 80% | 2.33% | 4.50% | 12.5% | 1.5% |
| 4 | analysis. Refer to | 65% | 75% | 2.33% | 5.00% | 15% | 2% |
| 5 | "Mochi Credit | 55% | 65% | 2.33% | 5.25% | 17.5% | 2.5% |
| 6 | Cap Calculation" | 45% | 60% | 2.33% | 5.50% | 20% | 3% |
# Risk Factor Categories
Mochi relies on empirical data of aggregate on-chain on liquidity depth to determine the level of credit default risk. Protocols will be classified into Risk Factors Categories (RFC) on a scale of 1-6. Where 1 is the lowest risk, and 6 the highest.
Classification | Risk Factor Category (RFC) | Conditions |
| -------- | -------- | -------- |
STABLE | 1 | Assets based on or derived from a $1:1$ USD peg |
ALPHA | 2 | ETH/BTC or >$100M$ liquidity depth to cause $25\%$ slippage across aggregated on-chain liquidity |
GAMMA | 3 | >$20M$ liquidity depth to cause $25\%$ slippage across aggregated on-chain liquidity |
DELTA | 4 | $5-20M$ liquidity depth to cause $25\%$ slippage across aggregated on-chain liquidity |
ZETA | 5 | $1-5M$ liquidity depth to cause $25\%$ slippage across aggregated on-chain liquidity |
SIGMA | 6 | $0-1M$ liquidity depth to cause $25\%$ slippage across aggregated on-chain liquidity |
## Collateral Factor (CF)
Collateral Factor, or Loan-to-value (LTV) is the amount of USDM debt as a percentage of deposited collateral a user/protocol has accrued. It is capped based on the Token’s Risk Factor Category(RFC) (refer to Collateral Factor/Ratio Max on this table). The CF for a vault can be calculated as:
<font size="5">
$$CF(\%)=100\ ×\ \frac{USDM\ borrowed}{Value\ of\ Collateral\ in\ USD}$$
</font>
This is the loan-to-value (LTV) and calculated in real time. For example, if the current collateral deposited has a market value of $1000$\$, and the user borrows $400$\$. then the CF is $40\%$.
CF for a vault must always be maintained below the Liquidation Factor (LF) to keep the vault from being liquidated.
At loan initiation, the max CF is achieved when the user withdraws the largest loan possible against the deposited collateral. A safety buffer is maintained between max CF and LF to protect users against liquidations due to normal volatility.
Max CF, safety buffer and LF are defined for each RFC as per section 2.10.
## Liquidation Factor (LF)
The Liquidation Factor is the Collateral Factor at which the vault will be liquidated. It is the ratio of debt/market value of collateral at which collateral assets will be liquidated to recover the amount borrowed by the user. CF should be maintained below LF to maintain the Vault.
As an example:
- User deposits $1000 worth of Coin X (based on current price of coin) as collateral into their Coin X Vault, which has a Liquidation Factor of 75%
- User borrows/mints $650 of USDM
- User has a Collateral Factor of 65%
- The value of deposited collateral drops to $867 (based on current price of token)
- The CF at this point becomes = LF
- Users coin X vault is liquidated, debt is repaid and any excess amount goes to the liquidator.
If CF >= LF, assets will be liquidated.
The Liquidation Factor for each RFC is set in a conservative manner such that Mochi can rapidly recover debts in the worst case scenario where the market value of the asset crashes.
## Stability Fees
Stability Fees are an annual amount in USDM owed on minted USDM to maintain protocol robustness.
Some current DeFi lending protocols utilize a static fee structure similar to Maker. Mochi provides an improvement over the static fee structure by employing dynamic stability fees which adjust according to market conditions. This allows the protocol to maximize utilization and revenue while providing the most competitive rates to users, as well as help stabilize the USDM peg.
Mochi implements a variable stability fee mechanism that adjusts according to the Risk Factor Category and Utilization.
Utilization (u)- represents the ratio of borrowed USDM to the maximum USDM debt that can be assigned to a protocol (credit cap).
<font size="5">
$$Stability\ Fee\ =(minFee+(maxFee-minFee)×min(1,u))$$
</font>
The minFee and maxFee are set by the DAO for each RFC.
*Stability fee versus utilization for the various RFCs*
**Discussion**
The stability fee function aims to satisfy the following conditions:
**Impact of Utilization (u):**
- When the Utilization of a Vault is low, the stability fees are low. This is to incentivize users to lock-in their assets and drive adoption of Mochi.
- As utilization goes up and a Vault gains adoption, the stability fees go up linearly.
**Impact of RFC:**
- Higher risk categories are charged higher fees.
### Origination and Accrual Fees
* On loan origination, a fee of $0.5\%$ of the total loan amount is applied.
* Mochi then begins to accrue stability fees, adding to the user’s debt amount, based on the current vault utilization %, from which the fee between min-max SF is derived in real time.
# Credit Caps
Credit Cap represents the maximum amount of USDM debt which can be assigned to a protocol or collateral type across all vaults. It is algorithmically set for each protocol as a proportion of the combined liquidity depth (LD) across the major decentralized exchange (DEX) pool pairs.
- Accepted DEXes: Uniswap, Sushi, 1inch, PancakeSwap
- Accepted pairs: WBTC, ETH/WETH, BNB, USDT, USDC, DAI
The Credit Cap of a protocol is defined initially as:
* Stablecoins: $5\%$ of market cap
* All other tokens: The value of a sell order across aggregated on-chain liquidity which will cause a $25\%$ reduction in token value.
* LP Tokens/Wrapped Tokens/Derivatives: $30\%$ of the credit cap of the main asset.
## Formulae
This document contains safe slippage analysis for the purpose of credit cap calculation. Slippage control to determine safe credit caps is a key factor in ensuring safe liquidations.
Based on empirical data collected from liquidity aggregators, the following line of best fit equation was obtained for slippage and number of tokens sold ($R_2>0.99$):
$$
y(x)=A*exp(B*x)+C*exp(D*x)+E
$$ (1)
where:
$x$ - price decrease; it cannot be less than $0\%$ or greater than $100\%$,
$y$ - total number of tokens sold,
And, $A$, $B$, $C$, $D$ and $E$ are constants specific to the coin.
When collateral is liquidated, the asset price decreases and the final price is given by formula $(1)$. However, the average price at which tokens are sold will be higher than the resulting market price at the end of liquidation. We assume slippage does not depend on whether the swaps are split in parts or sold all at once.
Since liquidations are not instantaneous, say, before liquidation could be completed, ya tokens are sold in the market, and in accordance to formula $(1)$ the price slipped by $x_a$. (natural slippage).
After that, due to vault liquidation, $y_b-y_a$ number of tokens are sold (total number of tokens sold (natural+liquidation) is $y_b$), and therefore net price slippage is $x_b$.
Blue line represents dependence between slippage fraction and number of tokens sold in accordance with formula $(1)$.
Total slippage loss during liquidation can be graphically represented as the area of the red shape. If the amount of tokens sold $(y_b-y_a)$ was small then we could consider that slippage is constant and losses would be a product of the amount of tokens sold and current slippage.
Since slippage changes, we have to use integration. However, the area of red shape can’t be found by direct integration, because the inverse of function $(1)$ cannot be solved in simple terms.
Green shape represents the definite integral of $(1)$ within segment $[x_a,x_b]$.
$$
\int_{x_a}^{x_b} y(x)\mathrm{d}x
$$
This value has no clear economic meaning, but can be used as an intermediate result for further calculations.
Finally, the net price loss can be found using the formula below:
$$L=\frac{1}{x_b-x_a}\Bigg(x_by_b-x_ay_a-\int_{x_a}^{x_b} y(x)\mathrm{d}x\Bigg)$$
This value can be calculated without iteration only if values $x_a$, $x_b$, $y_a$, $y_b$ are known. In our modelling, we already know what fraction of an asset price can be safely lost $x_m$ (max.safe price loss), $x_a$ (natural slippage), $y_a$ (calculated using formula $(1)$) and values $x_b$ and $y_b$ have to be found.
The final goal of the iterative process is to converge $L$ to $x_m$.
In order to obtain $y_b$, introduce an iteration algorithm.
Superscript added to variables that depend on iteration number.
Assume that dependence between slippage and number of tokens is close to linear, therefore if we know the maximum safe loss $x_m$, and $x_a$, then $x_b$ can be calculated during first iteration by formula below:
$$x_b^{n+1}=x_a+\frac{x_b^{n}-x_a}{L^n-x_a}\Big(x_m-x_a\Big)$$
Iteration process converges when $|L_n-x_m|\leq0.0005$
After the above iteration process we obtain value $x_b$, and then use it to find the number of tokens that can be sold to keep slippage within a safe range.
The number of tokens that can be sold during liquidation to keep it breakeven is calculated as $y_b-y_a$.
Therefore, the safe credit cap is given by:
$Credit Cap = [y(x_b)-y(x_a)]*p*LF$
This value ensures that based on the model proposed, liquidation will be safe.
Model constraints and comments:
1. Input data should contain natural slippage
1. For stablecoins, the slippage simulation breaks down with even small movements away from the peg. Therefore, this analysis is not suitable for calculating stablecoin credit caps.
* Credit cap of stablecoins may be denominated as a percent of market cap.
| Variable | Column 2 |
| -------- | -------- |
| $x$ | Fraction of price decrease; it can be not less than $0\%$ or greater than $100\%$ |
| $y$ | Number of tokens sold |
| $x_a$ | Fraction of price decrease after natural slippage |
| $x_b$ | Fraction of price decrease after natural slippage and liquidation |
| $y_a$ | Number of tokens sold during natural slippage |
| $y_b$ | Number of tokens sold during natural slippage and liquidation|
| $x_m$ | Maximum safe slippage |
| $x_b^{n+1}$ | Estimation of $x_b$ on $n$-th iteration. |
| $L$ | Fraction of value lost during liquidation (if all tokens sold at price before natural slippage, it would be $0\%$) |
| $L^n$ | Value of $L$ calculated on $n$-th iteration |
| $LF$ | Liquidation factor |
| $p$ | Price of coin |
### Sample Calculations
**Step 1**: RFC determination for $AAVE (based on sell order which causes $25\%$ slippage)
Number of tokens to cause $25\%$ slippage is given by line of best fit equation:
$y(25\%)=A*exp(B*x)+C*exp(D*x)+E)$ (1)
Where $x = 25\%$ and $A$, $B$, $C$, $D$ and $E$ are constants.
Value of sell order @ $25\%\ slippage = V(25\%) = Price * y(25\%) * (1-0.25)$
For Aave, this equation yields $V(25\%) = 43 Million$
Using table below, RFC is then assigned as $Gamma = 3$
| Classification | Risk Factor Category(RFC) | Conditions |
| -------- | -------- | -------- |
| STABLE | 1 | Assets based on or derived from a $1:1$ USD peg |
| ALPHA | 2 | ETH/BTC or $>100M$ liquidity depth to cause $25\%$ slippage across aggregated on-chain liquidity |
| GAMMA | 3 | $>20M$ liquidity depth to cause $25\%$ slippage across aggregated on-chain liquidity |
| DELTA | 4 | $5-20M$ liquidity depth to cause $25\%$ slippage across aggregated on-chain liquidity |
| ZETA | 5 | $1-5M$ liquidity depth to cause $25\%$ slippage across aggregated on-chain liquidity |
| SIGMA | 6 | $0-1M$ liquidity depth to cause $25\%$ slippage across aggregated on-chain liquidity |
**Step 2**: Calculate max.safe price loss $X_m$
Import params for RFC from table:
| RFC | 1 | 2 | 3 | 4 | 5 | 6 |
| -------- | -------- | -------- | -------- | -------- | -------- | -------- |
| LF(liquid_CF) | $95.00\%$ | $85.00\%$ | $80.00\%$ | $75.00\%$ | $65.00\%$ | $60.00\%$ |
| liquidator_Fee | $0.50\%$ | $1.00\%$ | $1.50\%$ | $2.00\%$ | $2.50\%$ | $3.00\%$ |
| liquidation_Fee | $4.50\%$ | $10.00\%$ | $12.50\%$ | $15.00\%$ | $17.50\%$ | $20.00\%$ |
Assume the vault is about to be liquidated $CF = LF$,
Loan value = $80\%$
Then, total value of loan that must be recovered to prevent $loss = loan$ value with $liquidator fee = loan value * (1+liquidator fee) = 80\% * (1+1.5\%) = 81.20\%$
Therefore, maximum safe price loss $X_m = 1 - 81.20\% = 18.80\%$
**Step 3**: Calculate max.safe slippage using iteration
Assume natural slippage $X_a = 25\%$ of maximum safe price loss (assumption based on RFC)
Therefore, $X_a = 0.25*18.80\% = 4.70\%$
For iteration 1,
$x_b^1=2*x_m-x_a$
Therefore, $x_b^1 = 2*18.80\% - 4.70\% = 32.90\%$
Next, find the effective market price lost using the formula:
$L^n=\frac{1}{x_b^n-x_a}*\Big(x_b^ny(x_b^n)-x_ay(x_a)-\int_{x_a}^{x_b^n} y(x)\mathrm{d}x\Big)$
$x_a=4.70\%; x_b^1=32.90\%$
$y(x_b^1)$ and $y(x_a)$ can be calculated using the omni equation from $(1)$ above.
We get,
$y(x_a)=Y_a=6.96·10^4$
$y(x_b^1)=Y_b=2.57·10^5$
The definite integral $\int_{x_a}^{x_b^n} y(x)\mathrm{d}x)$ is calculated as follows:
$\int_{}^{} \Big(A\exp(Bx)+C\exp(Dx)+E\Big){d}x=\frac{A\exp(Bx)}{B}+\frac{C\exp(Dx)}{D}+Ex+Constant$
Since it is a definite integral with given bounds $x_a$ and $x_b$, we can ignore the constant.
Therefore, the result is given by:
$Antiderivative\ (x_a) - Antiderivative\ (x_b)$
$Antiderivative\ (x_a) =$ substitute $x= x_a$ in equation $(2)$
$= \frac{A}{B} *\exp(B*x_a) + \frac{C}{D} * \exp(D*x_a) + Ex_a = 2.02·10^4$
$Antiderivative\ (x_b$) = substitute $x= x_b$ in equation $(2)$
$= \frac{A}{B} *\exp(B*x_b) + \frac{C}{D} * \exp(D*x_b) + E*x_b = 6.13·10^4$
Thus,
$Green integral =
\int_{x_a}^{x_b^n} y(x)\mathrm{d}x)=Antiderivative\ (x_a) - Antiderivative\ (x_b)=6.13·10^4 - 2.02·10^4
= 4.11·10^4$
And,
$x_ay_a = 4.70\% * 6.96·10^4$
$x_by_b = 32.90\% * 2.57·10^5$
And, $y_b - y_a = 2.57·10^5 - 6.96·10^4 = 1.88·10^5$
Then,
$Red integral = x_by_b - x_ay_a - Green integral = 2.57·10^5 - 6.96·10^4 - 4.11·10^4 = 4.03·10^4$
Finally,
Effective market price lost = $L^1= Red integral/(y_b-y_a)= 4.03·10^4/1.88·10^5 = 21.46\%$
Find the residual error = absolute value of **Effective market price** lost $L^1$ - maximum safe price lost $x_m=
21.46\% - 18.80\% = 9.63\% = 0.0963 > =0.0005$
Therefore, iteration must continue as long as residual error is not below $0.0005$.
For second iteration,
$x_a = 4.70\%$
$x_b$ is given by the formula $x_b^{n+1}=x_a+\frac{x_b^n-x}{L^n-x_a}\Big(x_m-x_a\Big)$
Therefore,
$x_b^{2}=x_a+\frac{x_b^1-x}{L^1-x_a}\Big(x_m-x_a\Big)=28.43\%$
Complete iteration $2$ using $x_a$ and $x_b^2$ using the same methodology as the first iteration, to get $L^2=18.46\%$
**Calculate residual error** $= |L^2- x_m| = |18.46\%-18.80\%| = 0.34\% = 0.0034 > =0.0005$
Therefore, another iteration is required.
For third iteration,
$x_a = 4.70\%$
$x_b$ is given by the formula $x_b^{n+1}=x_a+\frac{x_b^n-x}{L^n-x_a}\Big(x_m-x_a\Big)$
Therefore,
$x_b^{3}=x_a+\frac{x_b^2-x}{L^2-x_a}\Big(x_m-x_a\Big)=29.02\%$
Complete iteration 3 using the same methodology, find the residual error.
Perform additional iterations until the residual error is $<0.0005$.
For AAVE, the iterative process yielded a negligible residual error $<0.0005$ at iteration $5$, giving estimated safe slippage = $x_b^5= 28.95\%$
**Step 4**: Calculate Safe Credit Cap
Natural slippage = $4.70\%$
Token amount for natural slippage (calculated using 1) $= 69602$
Max.safe slippage = $29.95\%$
Token amount for maximum safe slippage (calculated using 1) $= 216309$
Safe token liquidation amount after natural slippage $(Token.safe.liq.amount) = 216309 - 69602 = 146707$
$Finally, safe credit cap = Token.safe.liq.amount * Min.monthly price * Liquidation factor (LF)$
$$=146707*\$258.47*80\%=\$30,336,713$$
# Liquidations
Liquidation divests collateral assets to USDM to maintain protocol solvency. It happens when the collateral factor becomes equal to the liquidation factor.
In Mochi protocol, every USDM is overcollateralized which minimizes shortfall risk and ensures peg stability.
If the Collateral Factor (CF) rises to become equal to the Liquidation Factor (LF), the user's vault will be subject to liquidation. Anyone can trigger a liquidation directly via the smart contract interface, by sending a trigger transaction. There are also liquidation bots that consistently monitor Vaults and trigger liquidations if the Token Price meets the User’s Vault Liquidation Price or lower.
## Liquidation Trigger
### When $CF = LF$, the Vault is triggered for liquidation:
A Dutch auction starts for underlying collateral with a linear decrease in price.
* Where the auction of the collateral starts at market price (the price reduces every block until bought)
* Where USDM debt is equal to the borrowed USDM amount plus the Liquidation Fee calculated as a percent of this amount.
* Where users can buy the collateral for the current price by paying the USDM debt for a liquidated Vault.
<font size="4">
$$USDM\ debt=Borrowed\ USDM× \Bigg(1+\frac{Liquidation\ Fee(\%)}{100}\Bigg) $$
</font>
For example, if there is a 100 USDM debt, which includes the 10% liquidation fee; when a liquidator buys the collateral for 100 USDM, 90 USDM is burned to repay the user’s debt, and the remaining 10 USDM goes to the treasury.
Table 4. Dutch auction algorithm
<Font size=4>
**While** **True**:
**Calculate** *CF* **and** *LF*
**IF** *CF***⩾***LF*:
**Initialize** *blockprice* **with** (*spot* **+** *liqfree*) **value**
**Set** *pricestep* **to** *liqfee* **/** *numblocks*
**For** *block* **in** *Blocks*:
**While** *block* **is NOT sold**:
**Try to sell** *block*
**IF** *blockprice* **>** *spot*
**Set** *blockprice* **to** (*blockprice* **-** *pricestep*)
</Font>
## USDM Flash Loans
All Mochi Vaults will support flash loans of USDM which enable smooth, reliable, safe and consistent liquidations. Liquidator keepers will receive a variable fee from $0.5\%$ to up to $3\%$ of the vaults debt - based on the vaults token class. Learning from the experience of Black Thursday, Mochi liquidations process is much more resilient and stress tested to deal with extreme circumstances.
With flash loans, a liquidator doesn't need to source USDM to buy collateral. Instead, they can flash borrow USDM @ 0.1337% fee to buy the collateral, liquidate the collateral and repay the USDM debt in a single transaction. This ensures efficient liquidations where the users/bots do not need to wait for the "right pricing" to liquidate, which protects the protocol from shortfall risk.
## Collateral Realization
After collateral realization (when the debt position has been successfully sold to a bidder):
- All outstanding balance left after repaying the borrowed USDM amount plus the Liquidation Fee and flash loan fee is kept by the liquidator.
- The User’s USDM debt is burned; and
- The liquidation fee is sent to the treasury
# Chain-State Storage Relay (CSSR)
The Mochi Chain-State Storage Relay (CSSR) model ensures that any relevant token state is committed to on-chain data availability. It does so by separating the process into:
- Saving the StateProof.
- Observing the data.
Bifurcating the process ensures that StateProof can open up access to chain-states, saving the state of previous blocks to help support a diverse range of token data. This expands the limitations of current forms of historical data access since a pair can only submit data once in every 256 blocks.
Below describes how the StorageProof CSSR works:
* A queries to get the data of X in block #10000 when the latest block is #10100. This will record a small hint (block state) about block #10000.
* B wants to access the data of Y in block #10000 when the latest block is #10300 (which is not possible in other approaches as it is more than 256 blocks).
* B can use A’s hint stored in the CSSR and find the right price.
With the StorageProof CSSR, it is easy to access accurate historical on-chain data of long-tail assets, which has not been possible before.
## Adapter CSSRs
Since Mochi allows users to deposit LP tokens as collateral, calculating the LP token's critical data is required. We can use the CSSR Router to route through multiple layers and unwrap the data of the underlying token.
Let’s say we want to calculate the price of the “ETH<>BTC Uniswap V2 LP token.”:
* CSSR Router routes the query request to “Uniswap V2 LP Adapter CSSR.”
* The Uniswap V2 LP Adapter CSSR finds the total locked ETH and BTC amount in the “ETH<>BTC Uniswap Pair” and queries ETH and BTC price data to the CSSR Router.
* CSSR Router routes the ETH and BTC price data query request to the Chainlink oracle and returns the result.
* “Uniswap V2 LP Adapter CSSR” calculates the total price of assets locked in the LP pool and calculates the LP token price based on it.
# INBOX: Additional Notes
- Bounties for veCRV votes in Curve DAO and CVX votes in Convex Snapshot will be funded initially, sustainably through protocol revenue.
# Mochi inside a Whitepaper
<iframe
src="https://mochi.fi/"
style="width:100%; height:1000px;"
></iframe>
# Join
## [Twitter](https://twitter.com/MochiDeFi) | [Telegram](https://t.me/MochiDeFi) | [Discord](https://discord.mochi.fi) | [Website](https://mochi.fi)
Sign in with Wallet
Connect another wallet