# Protocol Math

as of 01/04/2023

Most numbers are represented as a

*mantissa*, an unsigned integer scaled by 1 * 10 ^ 18, to perform basic math at a high level of precision.The

**cash**represents the availability of**underlying**in the**money market**. It is discretely updated at every of the following interactions: deposits, withdrawals, loans requests and loan repayments.

Which can be translated to the following difference equation if we apply the explicit Euler discretization scheme:

Each

**money market**tracks the total**borrowed amount**. However, each Smart Account must track the**account’s borrowed amount**. In that context, we can also track an**Interest Rate Index**given by:

With initial condition Notice that this index is just the dynamics of a borrow of one unit. This is what is usually called the

**money market**equation. This index can be use to update any**borrowed amount**at time to any point in time such as:

In other words, the quotient among indexes define the well known

**discount factor**:

such that:

Finally, notice that the borrows increase or decrease at specific time points depending on loans being taken or repaid. These two scenarios imply that the total borrows present discontinuities at such time points.

In which represents the

**reserve factor**, i.e. the fraction of the interest that goes to the**protocol****reserves**. Notice that this equation can be discretized in a similar fashion as we did with the total borrows.Finally, a portion of the liquidation incentive being paid to liquidators will probably be redirected to the

**protocol****reserves**. This means that might increase and present a discontinuity at liquidation time points.The borrow and supply rates are defined through a mathematical model that relies on fixed parameters and the

**utilization factor**. At any point in time, the**money market****utilization factor**is defined as:

Where represents the

**total borrowed**amount and is the amount of**underlying****liquidity available**, given by:

In which is the

**available cash**and are the**protocol****reserves**. Nowadays, the state of the art model is a piecewise linear model with an**optimal utilization**.At this point, it is important to discuss some edge cases. When there are no borrows, i.e. , the

**utilization is zero**. On the other hand, when liquidity is zero, we cap the utilization as the first utilization that yields the maximum borrow rate, such that:

Finally, the supply rate is given by:

The protocol will implement an interest bearing token in order to distribute the accrue interest from borrowers among lenders (similar to Compound cTokens). The token will have an

**exchange rate**with respect to the**money market**or pool**underlying**given by the following equation:

In which represents the token total supply and with an initial condition . Lenders will receive these tokens when they deposit

**underlying**into the pool. On the contrary, they will have to redeem back those tokens in**exchange**for more**underlying**than what they have previously deposited. The conversion is performed as follows:

We might need to distribute rewards either to incentivize the use of our

**money markets****or for yield in our safety modules. For that purpose, we propose a rewards mechanism based on a speed of rewards (an amount of tokens being distributed per second for all beneficiaries) and the fraction of ownership for each individual account. Namely, the total amount of tokens being distributed as rewards per is:**

In which is the speed of rewards. An account gets rewards based on its supplied, borrowed or staked amount and the total amount being supplied, borrowed or staked:

In which is the account’s rewards, is the account supplied, borrowed or staked amount and is the total supplied, borrowed or staked amount. This previous equation can be written as:

where

can be considered as the price of an index, stock or share. This allows the account’s rewards computation to be performed as the amount of shares times the share price. This trick decouples the problem and requires re-computing only the index price at each protocol interaction but does not require updating rewards for all accounts at all interactions (these kinds of loops are computationally prohibited in smart contracts development). Now, we can implement the same discretization scheme as before, such that:

Notice that the times are a subset of times . In other words, a particular account needs to be updated at a given date while the index price is updated at all protocol interactions .

Last modified 2mo ago