Angle roadmap to a fully onchain governance system

[sogipec]

TL;DR

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.

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

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.
• On every chain where the protocol is deployed, there is a Timelock contract 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 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.

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.

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.

Implementation

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

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.

Front end interface

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.

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

Future iterations

This design is obviously a v0 and it presents some specific areas and places for which design could later be improved

Delegation

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.

Storage Proofs

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.

Multiple governance frameworks

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 votingDelay+timelockDelay.

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.

Concluding thoughts

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.

[pscott]

I’m thrilled to see the protocol going for a more “trustless” approach.

I have a couple of comments I want to share, mainly regarding the decision module (not the execution module). I’ll list here my two biggest concerns with the current approach:

1. Users forced out of voting

The original post mentions

veANGLE holders vote on Ethereum

Here’s Uniswap’s Governor contract on Ethereum. It looks like the function castVote costs around ~80k gas to execute.
If we assume Angle would deploy a similar contract, we could realistically assume a voter would incur the same cost for a vote.
At 80k gas a vote, and 30 Gwei gasPrice, then casting a vote would cost 0.0024 ETH. At the current price of $1700 an ETH, this is ~$4 for a vote.

The question we must now ask ourselves is: how many users will be forced out of voting?

This doesn’t impact big holders (aka whales). Indeed, someone with $1M worth of veANGLE will pay $4 per vote because the utility that comes with it is bigger than the cost of the vote. But when does this stop to be true ? At $10k? At $1k? At $100?

I personally think that ~10k is a good mark. But let’s be safe here and imagine that the number is $1k.

To answer this question, I’ve downloaded CSV data of the snapshots for AIP-60 to 68, and compiled them into a single sheet for quick analytics. I’ve also used the Dune query to get some statistics about veANGLE holders. I think the results are interesting (feel free to have a look at them here).

To make sure we are on the same page here:

1. There are on average 143.78 voters on the last 8 proposals
2. The average number of voters that have more than $1000 worth of veANGLE is 4.89
3. This means approximately ~139 (i.e 97%) voters would be FORCED OUT of voting.

Interestingly, only 12% of veANGLE holders hold more than $1000. Which means that the participation rate of “small holders” is higher than the participation rate of “big holders”.

I think the point is made → by moving to an on-chain voting system, we will force out a lot of users.

Now this could get mitigated by an efficient delegation system, so it brings us to the second point:

2. No delegation

Based on the data available to us at Snapshot, delegation is something that is demanded and used by voters. This gets more verifiable as the size of DAO grows, but we see this even for small DAOs. It doesn’t just have to do with the amount of tokens that a user has ; some users can hold substantial amounts of a token and yet decide to delegate their voting power (because of lack of time, or lack of interest, etc…).

Not having a delegation system might prove to be detrimental to the voter experience, lower the participation rate, and would further reduce the percentage of veAngle participating in governance.

–

Overall I think voting we should avoid voting on Ethereum at all cost. The reasoning in point #1 gets even worse if the price of ETH shoots up, or if activity picks up again on Ethereum like it was ~2 years ago ; or if Angle token price drops.

It also penalizes small holders but long term lockers. Imagine a user having locked $15k worth of Angle in February 2022, which would now be worth ~$1500. This user would probably have to stop voting if Angle decides to to move to on-chain Ethereum. I do not believe this would be fair.

Proposed Solution: oSnap!

oSnap is a trustless execution solution provided by Snapshot. The TL;DR is that proposals can have attached transactions that can get executed once a “dispute” period has elapsed. Anyone can “dispute” the resolution, provided they “bond” an amount dispute_bond of token.

What Angle is looking for

• A secure solution → oSnap is secure and used by other DAOs in the space. UMA protocol serves as the “dispute resolution” mechanism. Funds cannot be stolen: the worst case scenario would be griefing.
• Trustless execution → the AngleProtocol multisig does not need to be involved with oSnap.
• An easy to setup solution → a simple setup provided in the snapshot / Safe interface.
• A good UX for voters → keeps the Snapshot interface which users know and love (or at least I hope… :p)
• Does not centralize or force out voters → voting remains free, and delegation is still here!

A few comments about the “griefing” → an attacker could, in theory, dispute the transactions, delaying the protocol’s decision. This has not happened in practice with other DAOs using this. Plus, this could be mitigated by adding support for agEUR in the DVM as an accepted “bond token”. If that was to be the case, maybe we could even imagine doing an AMO for the “bond” required by Angle to create the proposals. This would make it so it literally costs nothing to Angle!

Final words

I would urge the community to think closely about this decision. It looks to me like this decision goes against the desired decentralization. Even in the eyes of the law, it seems to me that fully on-chain voting with only a few participants will not be seen as decentralized as Snapshot and oSnap with the current participation numbers.

With this in mind, I would suggest we give oSnap a try for a couple of months. Very little setup is required from the team: and no changes at all for voters. If this experiment fails, then I believe we should indeed consider moving to GovernorBravo.

[sogipec]

Thanks for all these points @pscott! And thanks for the interesting data!

On the users forced out of voting and the increased voting costs, I do agree that this is an undesired consequence of the design proposed, but I still want to raise a few points:

• the first reason why the system we propose does not have any delegation is for technical reasons: there are currently no viable delegation contracts built on top of ve-tokens (check Curve for instance). Like I know this is an important feature, and if we could have this onchain I think we should absolutely do this, but here I guess we have to wait for an efficient and audited veANGLE delegation mechanism to come in place.
• there is still in some way and thanks to liquid lockers a delegation mechanism. Like all votes created onchain will be replicated on StakeDAO for instance for sdANGLE holders on Snapshot. The Governor implementation we are proposing includes weighted voting so if StakeDAO votes 50-50 then they will have to vote onchain 50-50. The governance multisig is here to veto votes for which StakeDAO would have not respected the intent of sdANGLE holders and voted differently onchain than the offchain result.
  So: the Snapshot delegation and UX will still be available to those who want it. I agree that this brings some centralization in the hands of the biggest liquid lockers but just like UMA would become a centralization vector on the Snapshot solution.

There is one point I’m also not sure to agree on is the fact that: the more voters the more decentralized the DAO is. While I do agree that getting more people to vote is indeed a good sign of a healthy DAO, what matters most I guess is the number of addresses which need to collude for a vote to pass. I think we’ve had some pretty good examples in the past of votes within Angle DAO which got super tight thanks to the pretty widespread distribution of ANGLE tokens. So yes, the more the better, but few voters do not mean that the protocol is not decentralized.

Back on the oSnap solution, I also think that this is a good solution, and it’s definitely something that I personally spent quite some time reviewing. And you put up here the arguments that led me to think that the mechanism we propose is slightly more efficient:

• UMA token holders are the ultimate decision makers
• And yeah the DAO starts to be exposed to grieving attacks even if I understand this does not happen in practice.

In the end, the designs are very similar I guess, with one putting more weight on liquid lockers for small voters, the other one on UMA. And both involve Snapshot and off-chain voting for these small addresses.

Looking forward to seeing what others have in mind

[gnrv]

First thank you for this post and your thorough analysis, always great to see this kind of discussion

A few notes:

• I am more comfortable with a last look by an Angle elected multisig than UMA (another DAO) blocking or not a transaction. They do not have enough skin in the game, to prevent action going against Angle DAO
• On the number of voters with a small veANGLE balance, we also noticed that some of them could be airdrop seekers with a very small balance of ~2 veANGLE

[Tube]

I think a large amount of Angle holders are using the liquid locker, and are therefore able to 1) vote without any gas cost and 2) delegate to anyone. Therefore I think your two very valid concerns are quite mitigated here.

[pscott]

@sogipec thanks for your answer. I’ll recap your post in a few points:

1. Delegation on GovernorBravo technically doesn’t exists, that’s why you’re not using it. I totally agreed and I’m sure if it existed you’d use it. I know Angle wants delegation also. But that is precisly my point! It doesn’t exist. And, I believe no delegation is a bad thing.
2. There is still in some way and thanks to liquid lockers a delegation mechanism. While this is factually true, I believe it to be practically false. I’ve ran a second analysis on stake sdANGLe holders and voters over AIP-60 to AIP-68. You can find the file here.
   
   

The numbers are even more dramatic than on the “regular” veANGLE governance. Almost no one is voting on the liquid locker. And no one with $1000 is voting over there.

Once again I’d like to re-iterate that “there are liquid lockers” is NOT a good solution for users that locked in their ANGLE before sdANGLE existence (or those that don’t want to trust stakeDAO, or decide to lock with the protocol for their own reason). I do not see it as an acceptable solution for the “no-delegation” problem. Moving to on-chain governance would mean saying goodbye to early believers that locked early. Is also means saying goodbye to small holders that would not know about the liquid locker.

3. What matters is the number of people that need to collude. That is a fair argument. I am not a lawyer nor do I work in the legal industry. It seems to me that the more spread the token, the better it is, because if de facto increases the number of people that need to collude. It also seems to me that privileging large holders and disincentivizing small holders to vote is not a good direction to go in.

4. UMA token holders are the ultimate decision makers. UMA tokens holder could, in theory, dispute an outcome, and cancel the associated transactions. To make sure we are on the same page, they would not take control over the Angle DAO, meaning they could not transfer funds or modify a transaction to send it to someone else. The only thing they could do is “delay” some transactions. As you say, this has never happened: and they are definitely not incentivized to misbehave: the whole purpose of UMA is to act as an Oracle. If they fail to do that, the value of UMA would drop significantly and most projects would part away from UMA.

I believe at the end of the day point 4 is maybe where we differ (because I think we can both agree that “delegation on StakeDAO” doesn’t really address the delegation issue). On point 4, my point of view is: Having this infinitesimal risk is better for the protocol than moving on an on-chain and expensive governance mechanism that would squeeze people (that might be genuine, long-term believer, early adopter) out of voting.

–

@gnrv I believe UMA token holders do have skin in the game: they are directly incentivized to behave in case of a dispute, for two reasons:

1. If the UMA protocol misbehaves as a group, then the UMA token would probably incur a heavy loss (see point 4 of my answer to Pablo). I do not believe it is in their best interest to misbehave in case of disputes (especially that they couldn’t even steal any money from Angle’s treasury, but only delay proposals).
2. If you are an individual voter on a dispute, you are incentivized to vote to what you believe is true, because if you are on the “wrong” side, you get slashed. So unless you know everyone will misbehave (in which case we go back to point 1), then you are incentivized to behave.

Regarding airdrop hunters: that is a very valid point. Even if 50% of voters were to be airdrop hunters (I don’t know the exact figures), I believe there are still genuine voters in the community (I personally know some, that I’ve onboarded :p), and I know for a fact that they would feel “rugged” (again, imagine you lock in 10k, now it’s worth 1k, and now we tell you “yeah by the way you can’t really vote anymore cuz you need to use the liquid locker but you locked in before… so yeah sorry. Oh sure we have a solution available but we’re not too sure we want to prioritize small holders because there are airdrop hunters you know…”).

–

@Tube I believe your point is factually incorrect, see my analysis on staked sdANGLE holders. The average number of voters is 2. The total number of holdesr is 282, about ~4 times less than veANGLE holders (taken from this query on dune).

–

Thank you @sogipec @gnrv @Tube for your replies. I hope I’ve addressed your concerns; keen to hear what you think about my words!

I will repeat what I think the Angle DAO should do:

• Give oSnap a try for a pre-determined period of time (say 3 months?) and take the final decision in 3 months. If things do not go well, we can always move to GovernorBravo. This might add a burden on the team, and I’m sorry for that, but I do think it’s worth the hassle. Also, the community gets the added benefit of not having to learn a new interface, gets to keep all the history in the same place, and probably a seamless integration the day Snapshot X finally comes out!

PS: for the curious who want to see what oSnap look like: AcrossProtocol.

[sogipec]

Thanks for sharing all these interesting points! Definitely clarifies a lot of stuff.

On people voting on StakeDAO, I must say that it’s not because not a lot of people are voting now that not a lot will be voting in the future

[Picodes]

@pscott

UMA tokens holder could, in theory, dispute an outcome, and cancel the associated transactions. To make sure we are on the same page, they would not take control over the Angle DAO, meaning they could not transfer funds or modify a transaction to send it to someone else. The only thing they could do is “delay” some transactions.

@pscott I may be missing something here.

• What prevents anyone from posting malicious proposals to the proposal verification module? Like is there a whitelist for proposers?
• What is the smallest set of persons that need to collude to execute a malicious payload? From what I understood from the doc, you could propose a malicious proposal, then dispute it, and then it’d be up to UMA holders, ultimately they could take control over Angle DAO
• Can anyone, provided they have some funds and are fine with paying the bond, delay indefinitely any proposal execution? Like assuming an attacker disputes a proposal everytime it is submitted, there would be an additional delay during resolution? In our case I think unknown execution time is quite an important blocker

Overall I do 100% agree with you on the fact that the UX of snapshot is way better than onchain votes. But I am very very reluctant to handle the keys of the DAO to another entity / set of holders and to have potential drawbacks like a possible unknown execution time.

[alexuma]

Hey everyone! I am Alex from the UMA team. Below are some responses to questions I noticed in the thread but feel free to ask anything I missed!

Are UMA token holders the ultimate decision makers? Can UMA block transactions? Can anyone delay proposal execution?
When proposed transactions are disputed, UMA token holders vote to determine the resolution of the posted bonds between the user asserting the proposed transactions and disputer. The key distinction is that UMA is not determining if the proposed transactions should be executed or not, only the bond resolution between the proposer and disputer. Therefore, UMA can’t vote to transfer the treasury to themselves or execute transactions.

The assertion made for the proposed transactions is deleted. This allows for anyone that believes the disputed transactions were actually valid to re-propose the transactions (requires posting another bond) without waiting for UMA to resolve the existing dispute. This design makes delaying execution of the transactions extremely costly for a malicious disputer as they would be required to keep posting and losing their bond. The same is true for a malicious proposer.

What prevents anyone from posting malicious proposals to the proposal verification module?
oSnap requires posting a bond that is lost when a malicious proposal is disputed. In addition, oSnap integrations typically use a longer challenge window (~48 hours) which gives disputers a significant amount of time to verify proposals. For context, questionable Polymarket proposals tend to be disputed within 30 minutes, and those proposals are harder to evaluate than oSnap proposals.

Proposals are also included in bot monitoring systems members of our competitive validator network have set up, and you can use our open source code (Monitoring Bot Setup - UMA Protocol) to set up Slack, Discord, and PagerDuty alerts. The Risk Labs engineering team is continuously improving our monitoring and is currently developing a bot that will not only alert on proposals but could automatically dispute if an obviously bad proposal is identified.

Is there a whitelist for proposers?
The default configuration is that anyone is able to propose and dispute. You can use escalation managers to whitelist proposers and disputers if you’d like. However, an appropriate bond value has proven to be an effective mechanism in preventing malicious proposals.

Here is the the function that allows proposers and disputers to be whitelisted:

• https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/optimistic-governor/implementation/OptimisticGovernor.sol#L211

[Picodes]

Hi @alexuma, thanks for these details. So assuming someone keeps on disputing near the end of the dispute window (say 48 hours), then the cost of freezing proposals would be 1 bond per 48 hour period, right?

[alexuma]

Yes, the attacker would lose their bond each dispute during the 48 hour period.

If the transactions are time sensitive and the safe has not transferred all ownership to oSnap, the safe could decrease the challenge window and/or increase the bond amount which would apply to all future proposals. After the proposal was executed, the safe could change the challenge window/bond values back to the previous value.