In our current effort towards resilience and decentralization, we propose to switch to a full onchain / trustless governance. To do this, we need 2 things: a decision module, that is to say a voting mechanism, and an execution module capable of safely bridging decisions to all the chain the protocol is deployed on. To implement this we propose to use
GovernorBravo for the decision module, and LayerZero combined with a timelock where a multisig can veto orders foe the execution module.
This is a temporary draft and we’re looking for feedback / remarks.
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 opening this discussion to propose 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.
- On every chain where the protocol is deployed, there is a
Timelockcontract which is admin of all the protocol contracts (Borrowing module, Transmuter when it’s live) 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.
You can note that the system we’re proposing here can be abstracted among a decision module (
GovernorBravo contract) and an execution module. Both are modular, and so any could later be changed at any time in the future.
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 amount 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. Intent here is to stick to this and set the quorum to 10m veANGLE.
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 6 hours.
votingPeriod: period of time during which it is possible to vote. We suggest leaving it to 5 days.
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
While we would need to run some tests for it, there would also be no need to develop a specific front end interface as this should be integrated by Tally.
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.
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.
This design is obviously a v0 and it presents some specific areas and places for which design could later be improved
Contrarily to some big governance mechanisms, there would be no onchain delegation mechanism available in the system we propose.
While this is obviously a desired feature as many small holders cannot afford to pay the gas required to vote onchain whenever there is a proposal, the way the veANGLE contract is built makes it difficult to build such delegation systems. The Curve DAO is encountering the same issue with their governance token.
One way to circumvent this is to consider that there are also liquid lockers which are owning veANGLE tokens and which mission is to replicate the governance votes on Snapshot before voting onchain. In the absence of delegation mechanism, it is still possible for people to vote for free on StakeDAO with their sdANGLE tokens.
One drawback as well with the infrastructure proposed is that it’ll require people to vote on Ethereum where gas can make it expensive to vote.
In an ideal setup, people can vote on a chain where it’s cheap to vote using their Ethereum veANGLE balance and vote results can be bridged to the chain they concern.
The solution enabling people to vote with their Ethereum veANGLE balance on another chain is storage proofs. While some companies are starting to develop APIs to easily build storage proofs, these are not technologically ready to be used at scale yet.
On top of this, the cost of running storage proofs on L2s, especially for veANGLE where multiple storage slots would need to be proven, is quite expensive.
So while the solution is appealing technically, it is also too early for it to be adopted. The system’s voting module can be changed, and it could later to switch to a solution of this kind.
In the architecture we proposed, there was only a single set of parameters for votes: like one voting period and quorum.
This means that for each change there is going to be an incompressible timeline of
The voting module could be made in a way that two systems exist in parallel: one with a small quorum and a long voting period, and one with a big quorum and a short voting period. This would enable passing emergency proposals, and give more flexibility to the DAO.
The way a DAO organizes itself when it come to passing proposal and voting is critical. So as this is not a lightweight proposal, we’re welcoming any feedback about this architecture and proposed setup for Angle governance.
In its current state, the system which does not require any specific smart contract development and interfaces to be ran efficiently could be released in production quite rapidly. That being said, this does not mean that we should rush this transition to a more resilient mechanism.