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
  • Preparation
  • Submission
  • Voting
  • Build
  • Execution

Was this helpful?

  1. GENERAL
  2. Yield Generation Process

How do we determine which Yield Farms to use?

The users who have supplied assets into the vault determine which yield farming strategy the vault should use. This is achieved through Yield Allocation Proposals, where each successful proposal will go through the following life-cycle:

  • Preparation: preparing the yield allocation proposal

  • Submission: users that hold supply tokens can submit proposals on Snapshot

  • Voting: users that hold supply tokens can vote on these proposals on Snapshot

  • Build: creation of changes needed to execute a proposal

  • Executing: any successfully approved proposal will be executed

We will go over each stage in more detail here.

Preparation

In order to be executed, each successful proposal therefore needs to have:

  • Risk assessment: an assessment of the risks associated with the allocation proposal

  • Yield projection: a projection of yield that can be generated if the allocation proposal is executed

  • Optional: with a view of speeding up the build stage the following may be provided also:

    • Smart contract changes: changes to smart contracts required to implement the proposal

    • Configuration changes: changes to the configuration required

Submission

Once the proposal has been prepared, any users with enough supply tokens can submit proposals to change the allocation of yield farming funds. All relevant information should be included in the proposal to enable informed voting.

Number of supply tokens needed to submit a snapshot proposal = 1 token

For Vault 1, the proposals is located here:

Voting

All users with supply tokens can vote on Yield Allocation Proposals, where the following parameters are applicable to proposals.

Quorum

Minimum percentage of votes cast on a proposal before it is valid and can be executed

1%

Voting period

Minimum duration during which a proposal can be voted on

24 hours*

*Two exceptions:

  • in the event of extreme market conditions we reserve the right to reduce the time period which Supply Token holders have in which they can vote on an Allocation Proposals

  • if the holders of a sufficient number of votes vote in favour of an Allocation Proposal option, such that it is not possible for other vote holders to outvote those in favour of that option, the Allocation Proposal shall be deemed passed.

Build

There are two categories of changes; each will require a different level of effort at this stage:

Config

Development

Config type proposals are proposals that can be executed with configuration changes only. As such they will typically only require:

  • Detailed configuration changes

Development proposals require further development before they can be executed. As such they will typically require:

  • New or updates to smart contracts

  • Detailed configuration changes

  • Smart contract security audits

At this stage Altitude Protocol Inc. will lead the build process for the proposal and prepare it for execution.

Execution

Once a proposal has been approved and built, it will be executed by Altitude Protocol Inc, but only if the following conditions are met:

Expired

No more than 1 working day has passed since the proposal was approved.

Note: due to the build time required it is likely that all ‘development’ proposals will expire before they can be executed. In these cases a new ‘config’ proposal will be required to be passed once the build stage is complete.

Superseded

There are no new proposals that have superseded this proposal (for example if approval a new proposal was submitted and approved)

Assessment(s) invalidated

Information provided in the Risk and or Yield Assessment has subsequently been invalidated

Extreme market conditions

The market isn’t subject to extreme market conditions at time of execution

In case a proposal doesn’t meet these criteria it may be required to submit a refreshed proposal for execution.

PreviousHow are yields distributed?NextThe ALTI Token

Last updated 1 day ago

Was this helpful?

https://snapshot.org/#/allocation-wsteth-usdc.altitudefi.eth