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:

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

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

8 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.

Last updated