# 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` is strictly increasing

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 `ibtRate` is not strictly increasing

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`](https://dev.spectra.finance/contract-functions/principal-token#_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`.