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

TL;DR

This is a vote 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 occurrences 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.png]] 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, we propose here 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 then vote to remove the implication of the protocol's governance multisig as a governor in the protocol. On that note, we suggest that the guardian multisig responsible for pausing the protocol in case of unforeseen events keeps its roles within the protocol, even with a fully onchain governance system.

Voting Options

1. For, transition to onchain governance
2. Against, do nothing