top of page
  • Chandler

Governance Attack Vectors

#16 Governance Series


TLDR: Governance risk can come from many areas, social, economic or technical risk — sometimes a combination of all three. To build a governance system for the future, understanding how to mitigate the risks is paramount for the future we build towards. Most importantly, not everything needs to be a vote!


Decentralised contracts have a sense of permanence. Any changes in the contracts are done through a managed governance process. Governance processes are human in nature and, thus far more complex.


This article will explore some dangers of the governance process, offering a generalised framework for thinking about governance risk. In general, any effective governance process is meant to prevent decisions that move a project or protocol in a different direction than its mission.


Here we outline three main risk categories, technical, social and economic. Added to that are a few key lessons in effective governance processes.


The process of governance minimisation

Governance systems that minimise governance actions are more robust and defensible. The less you change, the better. However, protocols need to be upgraded, funds need to be spent, and direction needs to be taken.


Extensive governance systems also include many non-protocol-specific questions, for example, how much to commit to a grant, which arguably is a critical decision but does not fundamentally affect the protocol. A system that can delineate between a protocol-specific choice vs a social-level choice reduces the overall scope of the governance actions.


Autonomous organisations were meant to be autonomous, and reducing their governance footprint makes them less human-reliant.


Many tools are being developed as we speak designed to help the protocols have a different approach to governance actions of a social or human coordination nature vs those that affect the protocol. Examples are the emergence of the Zodiac Module, which allows users to submit transactions and have them verified optimistically. Instead of each on-chain action requiring a vote, transactions can be submitted and only in the event there is disagreement on the nature of the transaction is a vote required.



The Zodiac module for a Safe Multi-sig
The Zodiac module for a Safe Multi-sig

Technical exploits

Time and time again, smart contract bugs have been the headache of many protocols — including governance protocols. Many governance contracts exist as an on-chain voting mechanism to execute a given set of instructions. The minute there is any code on-chain, a technical exploit is possible.


One of the notable examples of this risk was a $22 million Compound governance exploit. The Compound system had a flaw with the contract responsible for distributing liquidity mining rewards.


The only contract authorised to change the affected contract was the Governor contract, meaning only a governance vote could affect a change that patched the faulty contract.


The slow governance process acted as an inhibiter to being able to patch the bug and stem the flow of funds. Luckily for the Compound team, the response was as swift as possible, and the governance system reacted in as quick of a manner as it could.


From another viewpoint, the contracts did precisely what they were designed to do, bugs and all. The only difference was that what humans thought the contracts were meant to do did not align with what the actual contract was coded to do. Many people do not buy that argument, specifically Robert Leshner.


This has been, without a doubt, the worst day in the history of the Compound protocol, — Robert Leshner.

No matter what each of us thinks is right or wrong, the fact remains that there will always be a difference between what a human thinks a bit of code can do vs what it means to do. The shocking reality is that we often do not realise it until it is too late.


Social exploits

Moving past the technical side, the social side of governance has its own challenges. Humans are naturally more complex than code.



Snapshot: A popular off-chain voting tool
Snapshot: A popular off-chain voting tool

This section can include an entire thesis worth trouble, so instead of diving into each, I picked five items I see as trending social risks.


  1. On-chain vs off-chain voting: As stated above, protocol governance actions should be minimised to the absolute basics. On-chain votes should affect on-chain contracts and off-chain votes are designated for items that people can socially agree on. I often see hundreds of on-chain votes for things that can easily get to soft consensus. This naturally diminishes the magnitude of an important vote vs a standard operating line item.

  2. The mechanism and process of voting: While not all voting processes follow this trend, there are enough to be weary of methods. In some cases, off-chain “temperature” checks lead to an on-chain vote, which gets executed by a multi-sig. This makes little sense as the step from on-chain voting to. Either ditch the on-chain part and have a trusted multi-sig manage on soft consensus or have the on-chain vote trigger the necessary actions.

  3. The most valuable item in a governance process is the attention of eligible voters: More votes lead to voter apathy and lower long-term turnout. Ensuring voices are meaningful, to the point and up to the calibre of a full-scale vote makes sure your voting turns out.

  4. Quorum and how much participation is required: There is a trade-off between voter participation and organisation size, as we wrote about in a previous article. However, there is also a trade-off between decentralisation and the ability of a small group of founding team members to simply override a vote. If the token is not sufficiently dispersed, a team can reach the quorum requirements for a vote.

  5. Voter expertise: One of the highest governance risks is the level of expertise a voter has to make an informed choice. There are many cases where users get governance tokens cheaply (e.g. airdrops, liquidating mining programs) and are eligible to vote. Voters are unsure of what they are voting on and either abstain or make the most popular call based on others’ leanings. This does not lead to a sufficiently decentralised and representative vote.

Economic exploits

An economic exploit is one where an attacker can deploy capital to take over the voting process. In most cases, governance is done via a token that can be bought. This means a cost to acquire a passing vote share (e.g. 51%).


If we look at some theoretical numbers, a treasury would need to have at least 50% of the voting supply value of any other protocol to pull off this exploit. With the size of some treasuries being orders of magnitude larger than others, the scope of this type of risk is not far-fetched.


Luckily, many protocols have enough of their tokens locked up with insufficient circulating supply for an attack like this to be realistic. However, with this token, an economic attack becomes plausible to unlock schedules and to circulate supply increasing over time.


Over time this attack may not be financial. It could be to break down a competitor, gain control to affect a contentious vote or even create a stalemate.


An example of exploiting a protocol through an economic attack can be found in a lesser-known protocol: True Seignorage.e


The TLDR version is that an attack bought 51% of their voting token as their market cap was small enough. After acquiring the tokens, the attacker created a vote to mint 11.5 quintillion tokens to their address. The vote naturally passed, and the user could sell as many tokens on Pancake swap.


The attacker made more from the sale of the tokens than it cost to purchase the passing votes, and the Dev wallet did not have enough funds to block him.


The CertiK Security Team recommends the following: “starting from the DAO mechanism, the project party should have the right to vote to ensure that the government proposal is not “kidnapped”, there, they can avoid the recurrence of the attack.”

Closing thoughts

Governance is here to stay, and we owe it to ourselves to build a governance process that pushes us to a future we all aim to be in. Understanding the risks of a governance system and how we might address them is an ever-evolving process. One aspect clearly stands out: governance systems have drawbacks that need thoughtful work to deliver on their promise.


Decentralized governance is still in its infancy, and so is the technology behind it. As the space matures, the governance attack vectors will naturally subside. Feel free to reach out to us for support or advisory on how to build decentralized governance frameworks that minimise attack vectors while allowing for DAO sustainable growth.

 
Get in touch,
  • If you would like to support us in our governance efforts,

  • If you and your team need guidance on governance related matters, or

  • If you are a founder who is building something interesting in web3

ctabanner-bg.png

Building Decentralized Governance?

bottom of page