Altitude Docs
Launch App
  • GENERAL
    • Protocol Overview
      • Optimizing Borrowing Rates
      • Actively Managing Idle Capital
      • How do users interact with a vault?
        • Deposit
        • Borrow
        • Withdraw
        • Repay
        • Claim Rewards
        • Other user functions
      • Vault Health
      • Ingress Control
    • Yield Generation Process
      • What is a vault?
      • How much is deployed into yield farms?
      • When do we interact with Yield Farms?
        • Migrations
        • Liquidation of vault
      • How are yields recognised?
      • How are yields distributed?
      • How do we determine which Yield Farms to use?
    • The ALTI Token
    • FAQ
      • Early Rewards Program
      • About Altitude
      • What milestones have been hit so far by the Altitude Team?
      • What are the advantages of using Altitude?
      • How does it work?
      • What Oracles is Altitude using to determine the health of the vault?
      • When will Altitude enable more vaults?
      • How are yields generated?
      • How do my rewards change when I interact with the vault?
      • Who determines where unutilized assets are deployed?
      • How will Altitude work at times of high volatility?
  • Integrations
    • Lenders
  • Yield generation
  • Decentralized Exchanges
  • Smart Contracts
    • Vaults & Contracts
    • Audits
    • Security
    • Governance
  • Oracles
  • Resources
    • Risks
    • Terms of Service
    • Disclaimer
  • Contacts
Powered by GitBook
On this page

Was this helpful?

  1. GENERAL
  2. Yield Generation Process

How are yields distributed?

PreviousHow are yields recognised?NextHow do we determine which Yield Farms to use?

Last updated 1 year ago

Was this helpful?

Generated yields are fully distributed to users after they (or someone else on their behalf) interacts with the protocol. At this point, any balance changes, resulting from previous harvests, are committed to the users’ account.

Distribution from each harvest performed based on the following calculation:

uCh=(uSh∗Ph∗vLTh−uBh)∗nCh/(vSh∗Ph∗vLTh−vUBh)uCh = ( uSh * Ph * vLTh - uBh ) * nCh / ( vSh * Ph * vLTh - vUBh )uCh=(uSh∗Ph∗vLTh−uBh)∗nCh/(vSh∗Ph∗vLTh−vUBh)

where:

  • uCh = user change resulting from the harvest

  • uSh = user supply at time of the harvest

  • Ph = price of the borrow asset at time of harvest

  • vLTh = vault liquidation threshold at time of harvest

  • uBh = user borrows at time of harvest

  • nCh = net change in harvest (farm earnings - farm losses)

  • vSh = vault supply at time of harvest

  • vUBh = vault user borrows at time of harvest

The value of uCh is either subtracted from the users’ loan balance, or where no loan is due allocated to the user as claimable rewards. These can be claimed by the user at any time. These changes are all tracked in the borrow asset currency (e.g. USDC).

Possible adjustments

In order to remove any incentives for users to not contribute throughout the whole harvest period any rewards meeting the following criteria are allocated to the vault reserve:

  • Rewards from users who’s loan-to-value is higher than the target threshold at the time of harvest

  • Rewards accrued by users before their last interaction with the vault in this harvest period

For the avoidance of doubt, interest still accrues on the users’ original position until they have been committed. Therefore it may be beneficial for a user to directly commit their position by calling the commit function directly.

Why does the users original debt still accrue interest? Of the net amount recognised during a harvest we don't know what percentage will be used to:

  1. reduce user loans → with implications for debt interest on user positions

  2. as claimableEarnings for users without a loan → no implications on debt interest for the user positions

As such without committing everyone after each harvest, we don't know how much debt that accumulates each harvest should be covered by individual users or the vault.