# Interest Bearing Logic

### Interest Bearing Logic

**Yield**

`yield` is represented as cumulative per-second rate in 27 decimal format. The rate is calculated as follows:

$$yield = 1 + annualRate^{\frac{1}{31536000}} \* 10^{27}$$

`cumulativeYield` represents the aggregate interest accrued over time. It is calculated with a 1-second precision based on the block timestamp. `cumulativeYield` is updated whenever the `_refreshCumulativeYield()` internal function is called, to update the `cumulativeYield` to the current time

`cumulativeYield` is calculated as follows: Cumulative Rate is calculated as:

$$newCumulativeYield = oldCumulativeYield \* (1 + yield)^{elapsedTime}$$

Setting `yield` to `RAY` (1e27) - which is also its initial value at deployment - sets yield to zero. A positive yield will increase the `cumulativeYield` over time.

Here `timeElapsed` refers to the time elapsed between the last `_cumulativeYield` refresh and the current timestamp.

`previousEpochCumulativeYield` also represents the aggregate interest accrued over time with a 1-second precision but is based on the `cumulativeYield` calculated at the `previousEpochTimestamp`. `previousEpochCumulativeYield` is also updated whenever the `_refreshCumulativeYield()` internal function is called.

`previousEpochCumulativeYield` is calculated as follows:

$$newPreviousEpochCumulativeYield = oldPreviousEpochCumulativeYield \* (1 + yield)^{timeElapsedToEpoch}$$

Here `timeElapsedToEpoch` refers to the time elapsed between the last `cumulativeYield` refresh and the `previousEpochTimestamp`.

Setting `yield` to `RAY` (1e27) - which is also its initial value at deployment - sets yield to zero. A positive yield will increase the `cumulativeYield` over time.<br>

**Epoch**

Although interest accrues each second, balances only increase each epoch. This is done to :

* Provide keepers with enough time to expire a bond (see Keepers)
* Avoid leftover residual dust amounts when transferring all of a user's balance, since most frontend wallets do not refresh a user's balance on a per second basis.
* Enable adapting epochs to bond term lengths if the DAO votes to do so. For example a 1 year T-Bill might have a 4 hour rebase while a 30 year bond could have a daily or weekly rebase.

Thus `balanceOf` and `totalSupply` both rely on the internal function `_calculatePreviousEpochCumulativeYield()`. The `_calculatePreviousEpochCumulativeYield()` is called in `_refreshCumulativeYield` to update the `_previousEpochCumulativeYield` state.

Even though only `_previousEpochCumulativeYield` is used to return external `KIBT` balances , the more accurate `cumulativeYield` state is required to track the yield earned between epochs.

Epochs add a layer of flexibility that enables `KIBTokens` to adapt to investment strategies with different time horizons.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.kuma.bond/kuma-protocol/developers/smart-contract-architecture/kuma-interest-bearing-token-kibt/interest-bearing-logic.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.