# Yield Calculations

To understand how yield is calculated within the protocol, it is important to understand the following:

The Principal Token effectively acts as collateral.

The value of the Principal Token is the same for every user and determined by the

`ptRate`

, i.e. the price of the Principal Token in the underlying asset.The

`ptRate`

can only decrease.The

`ptRate`

starts as 1 and decreases if the`ibtRate`

(i.e. the price of the IBT in the underlying asset) decreases.

## If `ibtRate`

increases

`ibtRate`

increasesIn this scenario, the yield attribution per user is simple. The Principal Token value in the underlying asset never de-pegs (i.e. 1 PT = 1 underlying asset).

In simple terms, the yield calculation is:

## If `ibtRate`

is volatile

`ibtRate`

is volatileIf the `ibtRate`

alternates between increasing and decreasing, then the calculation is more complex.

The reasons for the added complexity is that:

the

`ptRate`

is the same for every user,when any user interacts with the protocol, it triggers a

`ptRate`

update.

This results in the Principal Token's price in the underlying asset to change for every user.

The following example will illustrate the challenge:

If Alice and Bob both deposit 10 underlying tokens at time

*t0*when the`ibtRate = ptRate = 1`

, then both will receive 10 PT and 10 YT.At time

*t1*, the`ibtRate`

decreases to 0.5, and Alice decides to withdraw all of her funds. This will trigger a`ptRate`

decrease of 50%, i.e.`ptRate = 0.5`

. Alice will then receive 5 underlying tokens, which is expected.At time

*t2*, the`ibtRate`

increases to 0.75, and Bob decides to withdraw all his funds. Intuitively, Bob should get 7.5 underlying tokens back.However, since the

`ptRate`

can only decrease, the`ptRate`

still remains at 0.5.From Bob's perspective, the

`ibtRate`

decreased from 1 to 0.75, so there has been no positive rate for Bob.Bob was impacted by the decrease in yield from 1 to 0.5, but wasn't rewarded for the increase in yield from 0.5 to 0.75.

Therefore the protocol needs to balance the loss in Principal Tokens value with appropriate positive yield.

This balancing between negative and positive yield is performed in the internal `_computeYield`

function. It works by calculating how much a user should have gained or lost compared to what has actually been lost in Principal Tokens value (via`ptRate`

decrease). The yield attributed to the user is thus:

`actualLoss - expectedLoss`

if the`ibtRate`

decreased from the user's perspective (e.g. the example above), or`actualLoss + expectedProfit`

if the`ibtRate`

increased from the user's perspective (e.g. if in the example above at time*t2*the`ibtRate`

had increased to more than 1).

Note that the `actualLoss`

above is due to the `ptRate`

decrease and `expectedLoss < actualLoss`

.

Last updated