AIP - 83: Implement a fully onchain governance for the protocol

Angle Improvement Proposals
1

TL;DR

This is a proposal in echo of the discussion we had opened here.
We propose here to switch to a full onchain/trustless governance for the protocol.
The proposed architecture comes with 2 main modules:

  • a decision module: that is to say a voting mechanism
  • an execution module capable of safely bridging decisions to all the chains the protocol is deployed on
    To implement this, we propose to use GovernorBravo with some additional functionalities for the decision module and LayerZero combined with a timelock where a multisig can veto orders for the execution module.

Context

Angle Protocol is a DAO governed by veANGLE holders. These are voting on decisions going from parameters tuning or accepting new collateral types to treasury management and protocol upgrades.

Except for gauge votes which are already fully taking place onchain, the protocol relies on a dual mechanism where veANGLE holders vote on governance proposals through the offchain Snapshot solution before their votes are implemented onchain by a multisig composed of community members.

Full details on how Angle governance works can be found here.

While the gasless and free voting system turns out to be an efficient method to onboard as many people as possible in the DAO and while the governance multisig has always and in all conditions respected the decisions of veANGLE holders, the current design still assumes some trust in the current multisig signers.

We’re thus proposing a fully onchain governance mechanism for Angle where no trust in any entity is needed to pass and execute governance proposals.

Proposed architecture

There are many occurences of protocols which have an onchain governance. One complexity for Angle with respect to others is that the protocol already exists in multiple different chains, and an onchain governance system for the protocol needs to factor in the fact that decisions may be taken for elements that concern a wide number of different chains.

With this in mind, the onchain governance mechanism we propose is the following:

  • veANGLE holders vote on Ethereum on a GovernorBravo implementation (similar to what Compound, or Uniswap use) with a predetermined quorum, voting delay, voting period and proposal threshold. We’ll detail below, but we suggest to add other audited properties from the base GovernorBravo implementation
  • If they don’t want to pay the gas price of votes every time, veANGLE holders can delegate their votes to some other address.
  • On every chain where the protocol is deployed, there is a Timelock contract which is admin of all the protocol contracts (Borrowing module, Transmuter, …) of its chain.
  • While only onchain votes can lead to payloads being included in the Timelock contract of a chain before execution, Angle 4/6 Governance multisig (deployed on all chains as well) has a veto power on the payloads in Timelock contracts. This is meant to enable the multisig to cancel governance attacks where someone would start controlling a large share of the total veANGLE supply and force a vote that would seize all the protocol’s funds for its own address.
  • For successful votes on non-Ethereum proposals, payloads to execute are bridged to the chain of interest using LayerZero message passing technology before being sent to the Timelock contract of their chain.

DAO
DAO2385Ă—1310 222 KB

Precisely speaking, once a vote succeeds (majority of positive votes + quorum), the flow is the following:

  • If the vote concerns an Ethereum action:

    • The payload to execute is sent to the Ethereum Timelock contract. The Ethereum Timelock contract only accepts payload from the AngleGovernor contract
    • After the timelock period ends, if the payload is not veto-ed by Angle Governance multisig on Ethereum, it can be executed on Ethereum.

  • If the vote concerns an action on another chain:

    • The payload to execute is sent to a contract on Ethereum that uses LayerZero to pass the message to the destination chain.
    • Once the payload is received on the destination chain, it is sent to the Timelock contract of this chain, before being executed.

Implementation

Refinements from GovernorBravo

On top of the base GovernorBravo implementation, the voting system we propose comes with several audited add-ons:

  • GovernorCountingFractional: you don’t have to vote 100% for yes or 100% for no on a proposal. Typically liquid lockers will be able to conduct votes on their Snapshot space and replicate the vote on their end on our onchain system
  • GovernorShortCircuit: if a proposal reaches a certain threshold of voters (like 70% of quorum), it can be short circuited in the sense that we don’t have to wait till the end of the voting period for this
  • GovernorPreventLateQuorum: if someone votes on a proposal and causes it to reach quorum right before the end of the voting period, then voting period can be extended
  • GovernorVotesQuorumFraction: quorums are fractions of the total veANGLE voting power

Parameters

Like most onchain governance mechanisms, this system would rely on several parameters, among which:

  • timelockDelay: this is the amount of time before which proposals that are positively voted can be actually executed. This has two main purposes: preventing governance attacks so the governance multisig has enough time to veto anything that is a notorious attack, and giving time for people to execute their position within the protocol if they disagree with the outcome of a vote. Our idea would be to have it equal to 1 day.
  • proposalThreshold: amount of veANGLE tokens needed to create an onchain governance proposal. This must be high enough to prevent people spamming Angle governance but at the same time low enough to make sure proposing new improvements is available to as many as possible. Our current idea is to have it around 100k veANGLE.
  • quorum: This is the % of veANGLE tokens which must be voting on a vote for it to be actually valid. Like the proposalThreshold, this parameter shouldn’t be too small to prevent attacks where few voters decide on big outcomes of the protocol but at the same time not too big to prevent the case where governance is freezed because no proposal can actually reach quorum and pass. In this governance vote, it was chosen to increase the quorum to 10% of the veANGLE supply. Here we suggest to further increase the quorum to 20% of the veANGLE balance
  • votingDelay: amount of time between which a proposal is posted and vote on it starts. This can be increased to leave time for users to buy voting power before votes actually start. We suggest setting it to 24 hours.
  • votingPeriod: period of time during which it is possible to vote. We suggest leaving it to 4 days.
  • voteExtension: how long a vote can be extended if someone causes it to reach quorum right before the end of the vote. We suggest to set it to 3 hours.
  • shortCircuitThreshold: if the share of voters is higher than this short circuit threshold, then proposal does not have to go through the whole voting period before being executable. We suggest to set it to 75% here.
    These parameters are in all case mutable, and governance could vote (onchain) to update it.

Smart contracts

The big advantage of the design proposed above is that it does not require developing new contracts:

  • the GovernorBravo and Timelock contracts are super standard contracts with reference implementations by OpenZeppelin
  • LayerZero developed and audited contracts designed specifically for the passing of messages resulting from GovernorBravo votes.
  • FRAX has released an audited delegation system for veTokens
    We have compiled all this in a repo that you can find here.

Front end interface

We have been working with Angle Labs on implementing a front end interface that veANGLE holders will be able to use.
We will be working with Tally so they support a frontend for people to vote on top of Angle.

Transition phase

In order not to lock the protocol in a state where no instance has control over it, and leave some time to fully test the robustness of the setup, idea would be to keep a small transition period where:

  • the Governance multisig keeps ownership of the protocol contracts in parallel to the new governance system.
  • only the governance or guardian multisig can execute the transactions on the Timelock contracts across different chains

Whenever some proposals have been executed on different chains, we could remove the implication of the protocol’s governance multisig as a governor in the protocol, while leaving it as guardian. On that note, the guardian multisig responsible for pausing the protocol in case of unforeseen events could keep its roles within the protocol, even with a fully onchain governance system.

Concluding thoughts

The way a DAO organizes itself when it come to passing proposal and voting is critical. So this is definitely not a lightweight proposal and we’re welcoming any feedback on this.

There were many other options that were evoked in the first discussion. Ultimately I think that this option is the best tradeoff in terms of flexibility, implication for every veANGLE holders.

3 Likes
2

I salute the team’s stance on the transparency of the protocol as well as its governance process. I fully support the introduction of on-chain governance, I just question whether the proposed system is the only one possible, as it corresponds to all relevant points with one big exception: inclusivity. There is no technical option that would ensure the only negative point of this proposal? I repeat: inclusivity.

Best regards.

Note: I insist (following previous interventions) that, despite all the work carried out by the team, it is necessary to address the necessary changes to the tokenomics of the protocol.

1 Like
3

Thanks for your suggestion @pedrolopes.vng!

How do you think the system could be made more inclusive?

Note that what is suggested here is fully modular in the sense that if a more inclusive system (allowing voting from L2s) takes shape, we could also add support to it with the protocol’s governance.

Also curious to hear your thoughts on what a tokenomics revamp could look like.

1 Like
4

So, it will be possible to vote on L2, with staked angle on L1?

1 Like
5

Regarding the tokenomics revamp i´ve already made post (link below).
A discussion on this topic should be initiated or, at least, some information about possible future plans for the usefulness of the $ANGLE token.

1 Like
6

A possible correction to my old post about $ANGLE tokenomics consists of the possibility of carrying out $ANGLE buyback and partial burn (share buyback), redistributing the percentage of not burned $ANGLE to stANGLE holders as a means of valuing stANGLE holders. stANGLE holders should have a growing voice in protocol governance. What do you think?

1 Like
7

Sorry seeing this just now. It won’t be possible at launch but goal is to implement such a system at some point yes

1 Like
8

I see the point, but with which revenue should the buybacks be conducted?
Do you think it’s more efficient to use this revenue rather than using it to grow agEUR and the protocol

1 Like
9

Therefore, from what I understand and as I mentioned, the voting system will not be inclusive at its start.

1 Like
10

Obviously, as an investor in the protocol, I understand that the revenue must be used to develop agEUR and expand the protocol. I only ask that you present a tokenomics system that will be activated in the future (such as the fee switch from Uniswap) through which the present and future usefulness of the $ANGLE token is perfectly clear.

1 Like
11

One thing that I think is important to address is liquid locker tokens (sdANGLE in the present case). We need to work with the StakeDAO team and have them implement a minimum quorum and voting duration that matches the Angle governance requirements. Currently, a single small sdANGLE voter could in theory decide the outcome of a governance proposal since StakeDAO does not currently implement a quorum requirement on votes. And their vote duration is always quite a bit shorter than the “normal” voting period. I would even go so far to say that if liquid lockers don’t satisfy some mandatory voting mechanics defined by Angle governance, their locker address should be blacklisted from governance.

3 Likes