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
GovernorBravowith some additional functionalities for the decision module and LayerZero combined with a timelock where a multisig can veto orders for the execution module.
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.
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
GovernorBravoimplementation (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
- 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
Timelockcontract 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
Timelockcontract 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
Timelockcontract of their chain.
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
Timelockcontract. The Ethereum Timelock contract only accepts payload from the
- After the timelock period ends, if the payload is not veto-ed by Angle Governance multisig on Ethereum, it can be executed on Ethereum.
- The payload to execute is sent to the 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.
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
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.
The big advantage of the design proposed above is that it does not require developing new contracts:
Timelockcontracts are super standard contracts with reference implementations by OpenZeppelin
- LayerZero developed and audited contracts designed specifically for the passing of messages resulting from
- FRAX has released an audited delegation system for veTokens
We have compiled all this in a repo that you can find here.
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.
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.
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.