Kuma Protocol
WebsiteTwitterGovernance Forum
  • Introduction
  • KUMA Protocol
    • How does it work ?
    • Regulated NFTs
      • Real World Assets, onchain
      • Mimo Capital AG, a regulated entity
      • KUMA NFTs
    • Composable Interest-bearing tokens
      • KUMA Swap
        • User Scenario 1: Kuma Bond Token With Swap
      • KUMA Interest-bearing tokens
        • USK
        • FRK
        • EGK
      • Interest accrual
    • DeFi Integrations
      • DEXes Protocols
      • CDP Protocols
      • Lending Protocols
      • Yield Aggregators Protocols
      • Fixed Yield Protocols
      • Bridges
  • DAO & Governance
    • What is MIMO (Governance Token) ?
      • Where can i get MIMO ?
    • vMIMO and Voting Power
    • Governance process
      • Govern with MIMO tokens
    • Proposal Framework
      • KUMA Integration Request (KIR)
      • KUMA Governance Proposal (KGP)
      • KUMA Improvement Protocol (KIP)
    • Multisig
    • KUMA Emergency Guardians
  • developers
    • Developer Guide
    • Smart Contract Architecture
      • KUMA Interest Bearing Token (KIBT)
        • Interest Bearing Logic
        • ERC-20 Compliance and Updates
        • Balance Accounting
      • Decentralized Access Control
        • Pause/Unpause Access Control
      • KUMASwap
        • sellBond
        • buyBond
      • KUMA Bond Clone Tokens (KBCT)
      • Keepers
      • Deprecation Mode
      • Rate Feed
        • Central Bank Rate Validation
        • MCAGAggregator Volatility Check
    • Code Repositories
    • Contract Addresses
      • Ethereum
      • Polygon PoS
      • Linea
      • Mantle
      • Telos EVM
      • Neon EVM
  • Ressources
    • User Guides
      • Setting up
      • Managing transactions on EVM chains
      • Troubleshooting
      • Lock MIMO for vMIMO
    • Links
    • Security & Audits
    • Glossary
    • Press Kit
Powered by GitBook
On this page
  1. developers
  2. Smart Contract Architecture
  3. KUMA Interest Bearing Token (KIBT)

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+annualRate131536000∗1027yield = 1 + annualRate^{\frac{1}{31536000}} * 10^{27}yield=1+annualRate315360001​∗1027

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)elapsedTimenewCumulativeYield = oldCumulativeYield * (1 + yield)^{elapsedTime}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)timeElapsedToEpochnewPreviousEpochCumulativeYield = oldPreviousEpochCumulativeYield * (1 + yield)^{timeElapsedToEpoch}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.

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.

PreviousKUMA Interest Bearing Token (KIBT)NextERC-20 Compliance and Updates

Last updated 1 year ago