# 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.

In 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:

$(ibtRate_{new} - ibtRate_{old}) * ytBalance_{user}$

If 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 modified 13d ago