Governance FAQs

web3 aims to disperse power online. Well-designed decentralized and democratically oriented governance systems are vital to its evolution. These systems can help to protect projects, encourage buy-in from users, and increase trust for developers, business partners, and others considering building on top of platforms they would like to remain neutral. 

But designing good governance for web3 is hard. 

To make it somewhat easier, I  wanted to offer answers to some of the most frequently asked questions on the topic. The answers are rooted in my research as an academic political scientist with a long-running interest in democratic systems as well as my experience over the last several years studying and working in web3 governance. Some of these are questions I regularly hear from web3 projects when I meet with them. Others are questions I think founders should ask more often. Together, they are intended to give anyone thinking about building in the web3 space helpful guidance on what they should be thinking about when they set up their governance. I’ll continue to add new questions and answers to this document as they arise. If you have suggestions, please get in touch.

There is no single, optimal design for web3 governance. It all depends on the nature of your project and your specific goals. Designing your governance structure means confronting crucial tradeoffs related to things like inclusion vs. expertise, speed vs. robustness, and fairness vs. effectiveness. How you manage these tradeoffs will depend heavily on what your goals are.  

Most web3 projects have some sense of why they want at least some decentralized governance: they know that they want to build a community-owned and credibly neutral project that is progressively run by the community. But it is useful to get more specific and figure out exactly what your goals for governance are. 

In conversations with teams, we often land on two potential goals that might necessitate decentralized and democratic governance:

1. Build trust among community members and partners by representing key stakeholders’ interests and creating a credibly neutral platform that no one actor controls or can subvert. (A good example where this goal is paramount might be Optimism or other layer-2s where platform neutrality is helpful to encourage others to build on their stack.)
2. Create buy-in and user demand by providing a genuine sense of ownership. (A good example where this goal is paramount might be a cultural or artistic community like NounsDAO, where people want to buy Nouns to be a part of the community.) 

Each of these ideas has antecedents in the physical world, where people often argue that democracies are more robust because they diffuse power, generate buy-in among citizens, and encourage economic growth by offering a neutral platform based on property rights and free markets for commercial activity. 

These goals are not mutually exclusive, and understanding how you prioritize each is helpful for suggesting design principles for your governance. Focusing more on creating neutrality might point toward aggressive governance minimization as, for example, in a DeFi protocol where the main functionality is baked into the code and the DAO has only limited decision-making power. On the other hand, encouraging new community members to join might require you to build more complex structures that empower the community to do things like allocate revenue to public goods, decide on the strategic future of the project, and drive other key decisions. 

web3 projects exist along a spectrum: at one end are financial businesses whose goal is to provide value to customers. On the other, projects that might focus on building public goods for communities or ecosystems. Decentralized governance can be important all along this spectrum, but the form it takes will vary, so it’s helpful to know where you stand.

Many projects in web3 have some kind of civic motivation. In these cases, a primary stated goal is to represent the community as a whole in decision-making. But what does “the community” want? Different members of the community may have different preferences, and we need a way to aggregate these preferences into a collective decision. Under certain conditions, the “median voter theorem” tells us that majority voting provides a socially desirable aggregation in which decisions reflect a compromise favoring the more centrist voters. To make voting like this work, however, we need each community member – rather than each token – to receive a vote so that we aggregate across the community rather than across tokens. This is why there has been sustained interest in moving beyond token voting. 

For projects more focused on business interests, the primary governance goal is to maximize value while maintaining decentralization. This means making the collective decisions that help the business succeed as much as possible while preserving neutrality and censorship resistance. In the study of voting, we call these “common value problems.” Explored by Condorcet in his jury theorem, these problems lend themselves to “the wisdom of the crowds.” In these contexts, we’re not concerned with including all voices or representing the community but rather in obtaining the best possible information to make the best possible decision. People who hold more tokens are likely to be most motivated to understand the details of the project. As a result, it may be reasonable to rely on basic token voting, where people who hold more tokens get more voting power. 

The single most common question I get from projects is, How can we increase participation in governance? This means both getting existing tokenholders to participate more in governance – by voting, delegating, posting, discussing, and so on — and also drawing in new tokenholders to do these things. 

Projects care about this question for many reasons. Low rates of participation can leave the project vulnerable to capture by adversaries or concentrated interest groups, can lead to poor decisions, and can threaten to erode the project’s egalitarian ethos.

To understand how to increase participation, it’s helpful first to understand how we think participation in democratic systems works. 

The calculus of voting is an important framework for thinking about how people might choose whether to participate in governance:

Probability of Voting = 

(Probability of your vote changing the outcome * Value of outcome) – Cost of Voting + Psychological Rewards to Voting

Your probability of choosing to participate increases when:

1. You are more likely to change the outcome if you vote,
2. You care more about the outcome of the vote,
3. It is less costly for you to vote, and
4. You derive more psychological benefits from participating.

Based on this equation, participation in web3 might occur for a variety of reasons.

• For many smaller token holders, their probability of affecting the outcome of the vote may be low
• To the extent many votes are abstruse or far from the expertise or interests of many smaller tokenholders, they may not care much about the outcome
• Similarly, people deep in the space who may be genuinely interested in participating may hit hard constraints on their time when they are a member of multiple DAOs all holding votes at high frequencies on many issues
• Gas fees for on-chain voting, difficulties in navigating technical obstacles to on-chain voting, and the cognitive complexity of votes, which are often highly technical, increase the cost of voting and may deter people from voting
• The lack of a broader information ecosystem for web3 governance means that many tokenholders may be unaware of when votes are occurring, and have not developed habits conducive to regular participation
• For smaller token holders not already actively immersed in a community, participating in governance may not deliver any psychological benefits since they cannot connect the act of participating to a social experience that matters to them personally

(Essentially all of these explanations were identified in a brilliant MakerDAO post by 0xdeniz in 2021.)

This list of factors above suggests natural ways to try to increase participation, all of which projects have been experimenting with in different ways. Three main strategies are

1. Simplifying the voting process and making it less time consuming and complex. This can include:

• Encouraging tokenholders to delegate, focusing their attention on one big decision to delegate rather than many small voting decisions
• Reducing the total number of votes taken and focusing votes on the biggest decisions
• Providing easily accessible information relevant to voting and delegation decisions

In the future, AI-based tools could recommend votes to you based on your past voting history and elicited values. 

2. Increasing the benefits of voting and reducing the costs. This can include:

• Designing your governance token to directly reward voting monetarily (for more, see below)
• Shifting early polls off chain and reimbursing gas fees for on-chain voting
• Making the act of voting itself easier through, for example, UI development

3. Encouraging community and psychological association. This can include:

• Developing and communicating a clear mission for your project that attracts people who buy into the mission
• Making sure that the powers given to governance fit this mission – for example, if the project is about producing public goods for an ecosystem, make sure that governance is in charge of awarding grants
• Investing in building an active community with good communication outlets like a forum, chat server, and so on
• Rewarding participation in symbolic ways, such as by granting NFTs or non-transferrable badges to community members who lean in 

Directly rewarding participation is a valuable tool that you can build into your governance tokens. To do this, the first two questions to answer are: how much participation are you aiming to secure? And how much are you willing to pay, in terms of your project’s native token or otherwise, to secure this participation? Given answers to those questions, we have developed an optimal procedure for paying rewards to secure this participation in the most efficient manner possible.  

But blindly rewarding participation can risk encouraging mindless rewards harvesting or bot attacks – at least in some contexts. You might be tempted to attempt to mitigate these issues by targeting rewards to addresses that consistently vote in the majority (or conversely, to slash addresses that vote in the minority), but our research suggests this approach is unworkable. 

Instead, we suggest limiting voting rewards to token-holding addresses that meet certain threshold requirements: length of time holding the token, whether they have locked up tokens in different ways, or whether they have participated in the project in other ways, for example. 

To date, projects have more actively experimented with airdrops that aim to retroactively reward desired behaviors like governance participation. Airdrops lack the immediate effect of a direct reward scheme, and it is harder to determine what the optimal size of an airdrop should be or who exactly should qualify to receive it. Despite these limitations, they hold significant promise. They are probably especially valuable in contexts where you worry that direct rewards can be too aggressively gamed. (I discuss them again below with respect to delegation, a form of participation that has been heavily incentivized in recent airdrops.)

Rewards do not need to be only monetary in nature. You could also experiment with awarding non-transferable badges or NFTs to people who participate more in the project to create social rewards for helping with governance.  

Including more voices in decisions can lead to worse decisions when the decisions are highly technical in nature or require deep study. This is one of the fundamental tradeoffs in decentralizing governance. Businesses wouldn’t want to put critical business decisions up to a vote by people who have no knowledge of the business, obviously. 

Projects are exploring methods to solve this problem in ways that leave the community in charge but encourage smart collective decision-making. Some of the basic ideas include:

• Delegation – many projects have delegation built into their voting systems. It is enabled in GovernorBravo, the default governance contract for many DAOs. But some projects are going further, creating initiatives to recruit known delegates, to help them communicate with voters, and to encourage tokenholders to delegate. 
• Councils – some projects have built on top of delegation, empowering groups of delegates to sit on councils that can study key issues and make decisions on them. 
• Sub-DAOs – another way to encourage specialization is to organize a DAO into sub-DAOs organized around specific tasks. 

Delegation is a logical way to harness expertise and encourage participation. It also avoids asking tokenholders to do too much, cognitively speaking. Paralleling the transition from direct to indirect democracy in the physical world, allowing addresses to assign voting power to others can empower those who are paying attention to vote on behalf of those who do not wish to themselves. 

But delegation is not a panacea. Although basic governance contracts like GovernorBravo allow any address to delegate its voting power to any other address, this doesn’t mean that most people will do so. To spin up meaningful delegation, tokenholders must want to delegate, and a core group of people must be interested in serving as delegates. 

The decision to delegate can be analyzed through the same “calculus of voting” framework from above. For example, making it easier for users to delegate – by, say, building a nice front-end service for finding delegates — is an important step. Optimism Agora and Uniswap Agora are helpful examples in this direction. 

Moreover, you could also experiment with rewarding addresses for delegating. In fact, evidence suggests that Optimism’s recent airdrop, which retroactively rewarded addresses that delegated their votes, led to a sizable increase in subsequent delegation. This increase reflected not only addresses delegating their newly awarded tokens but also other addresses delegating more in anticipation of future airdrops. 

Voters are not going to delegate meaningful amounts of voting power if there aren’t good delegates to delegate to. Programs that encourage people to serve as delegates are an important part of the governance ecosystem. Educating people about the opportunity to be a delegate and compensating them for doing so are basic first steps in developing sustainable delegation systems. 

Delegation is effective when delegates make good decisions on behalf of their delegators. The principal-agent problem between delegates and delegators is much like that between representative and voter in electoral systems in the physical world. As such, we know there are two important factors to increasing accountability:

1. Delegates must want to remain as delegates and to attract delegated tokens, and
2. Tokenholders must care enough to pay attention and allocate their tokens to delegates who they support.

Thus far, some projects have made good progress both attracting and retaining delegates, and getting some people to delegate. Going forward, we will need to put more effort into encouraging more addresses to delegate and in getting them to do so in an informed fashion. 

A logical step in this direction, which I have advocated for in the past, is to create specific election days on which the community is encouraged to come together and evaluate their delegation decisions. Uniswap has recently announced something like this.

web3 communities can use governance to make all kinds of decisions if they want, including:

• deciding what to spend treasury funds on, 
• agreeing to changes to protocols, 
• developing business partnerships or hiring third-party services,
• responding to issues that arise (e.g., security incidents), and
• aligning on changes to the long-term strategy of the project.

Governance smart contracts encode the constitution for any web3 community. Once projects have in mind a clear goal for their governance structure, a logical next step is to decide what decisions they want their constitution to put in the community’s hands. Three considerations are key.

1. 1. Governance minimalism. If a decision doesn’t absolutely need to be decided democratically, it probably shouldn’t be. Democracy is an extremely powerful tool, but it is also slow, inefficient, and risky. Moreover, voters can do their job best when they are not asked to do more than is realistic. 
   2. Give voting power based on the project’s goals. If the goal is to ensure neutrality and resist censorship, projects may want to ossify as many things as possible. This might include locking in basic functionality (like Uniswap’s liquidity pools) or even hard-coding in how fees are collected or shared. But projects also need to be realistic about where changes will need to be made in the future and how to govern those changes. To create credible commitment to platform neutrality, projects may need to make sure that the people building on top of the platform are included in this process. Finally, if the goal is to generate community buy-in, projects may want to expand the scope of governance and empower the community to make more kinds of decisions that they care about. 
   3. Maintain agility. Some issues simply move too fast to rely on a voting process that requires days of discussion and consideration before proposals and voting. Imagine, for example, responding democratically to an ongoing security incident in the DAO, as some projects have had in the past. For fast-moving issues like this, it can make sense for the DAO to elect a person or group of people to hold certain “emergency powers.” This is just one example of a general principle: elections can serve as a slow-moving tool to allocate temporary power to faster-moving groups of people.

Once you know what you want the community to be in charge of, you also need to decide when to put them in charge. It’s unrealistic to go from 0 straight to full-fledged democracy. Fortunately, that’s unnecessary. Projects have to build the community, achieve sufficient levels of buy-in and participation, and create shared goals and norms before it can expect to have a critical mass of seriously engaged voters who care about the future of the project and are sufficiently informed to govern it together.

Oftentimes, this means starting small – experimenting with voting while a foundation or other entity oversees initial governance. As the project grows and expands the scope of items that are voted on, the foundation or other entity might continue to possess a veto over important decisions, to prevent disaster. But the ultimate goal is to dissolve the foundation and remove this veto once the community is sufficiently active.  

As I discussed above, sometimes simple token governance is insufficient because projects have civic goals that can only be credibly pursued if the community and not only large tokenholders have power in governance. 

The first step in moving beyond token voting is being explicit about who you want to represent. Who is your community? The right way to think about your governance structure is to think not only about who is in your community today but also who you expect to be part of the community in the future. Governance decisions made today will affect future members, and could drive them off if not made with their interests in mind. 

The most obvious way to move beyond token voting is to assign non-transferable voting power to addresses that represent members of the community. This issue is how to do this in a decentralized manner. There is no firm answer yet, but projects are experimenting with a progressive model: today, maybe the project’s foundation (if it has one) or another temporarily trusted actor picks the voters but with a plan for how today’s voters will be given some of the power to choose tomorrow’s voters, and so on, until in the future the legislature’s membership is no longer determined by the foundation at all. 

Bicameralism – using two decision-making bodies instead of one, like the U.S. House and Senate – is one way to balance civic and economic interests through specialization and divided powers. Optimism has pursued this model, building a “Token House” responsible for basic protocol governance using token governance, and a “Citizens’ House” responsible for funding public goods using a one-person, one-vote mechanism. 

You could alternatively simply award voting power to “citizens” but place them in the same governance chamber as the token holders. This approach may be logical if you want the two groups to work together to make all decisions in a way that reflects some compromise between them. In many cases, though, it is probably natural to divide their responsibilities. When business interests are paramount in the “common value problem” framework, token-based voting makes sense. When public goods are paramount in the “aggregate preferences” framework, one-person, one-vote makes sense. The more these problems can be separated from one another, the more sensible bicameralism becomes. 

web3 offers an extremely flexible design space for voting, which has led to a great deal of experimentation. For new projects, though, it probably makes sense to keep things simple. Here are two basic principles.

• Learn from best practices in the space. Make sure to implement sufficient proposal thresholds, quorum requirements, and time delays so that people cannot sneak through proposals “in the dead of night.” This is an old trick in the history of parliamentary skullduggery that has, unsurprisingly, made its way to web3. Early projects will likely want to hold onto an emergency veto, as offered in GovernorBravo, for similar reasons. 
• Keep it simple. For most projects, the key margin to improve in governance is increased participation. Changing the voting rules to something more experimental (e.g., using quadratic voting) is not going to help with this problem, and is likely to exacerbate it because such schemes put even more time and cognitive burdens on voters. Keeping things simple is usually wise, at least at first. 

Because this is meant to serve as a conceptual overview, I’m not going to go deep on tactics or toolings. But projects must understand that governance attacks are a major threat and that governance design needs to anticipate it. There are a number of best practices – including using the proposal thresholds, quorum requirements, time delays, and emergency vetoes as mentioned above, as well as increasing governance participation in general – that projects can use to make governance attacks harder. 

***

Andrew Hall is the Davies Family Professor and Professor of Political Economy in the Graduate School of Business and a Professor of Political Science at Stanford University. He works with the a16z research lab and is an advisor to tech companies, startups, and blockchain protocols on issues at the intersection of technology, governance, and society.

***

Views expressed in “posts” (including articles, podcasts, videos, and social media) are those of the individuals quoted therein and are not necessarily the views of AH Capital Management, L.L.C. (“a16z”) or its respective affiliates. a16z is an investment adviser registered with the U.S. Securities and Exchange Commission. Registration as an investment adviser does not imply any special skill or training. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. In addition, this content may include third-party information; a16z has not reviewed such material and does not endorse any advertising content contained therein.

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities, digital assets, investment strategies or techniques are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments or investment strategies will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investments/.

Additionally, this material is provided for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. Investing in pooled investment vehicles and/or digital assets includes many risks not fully discussed herein, including but not limited to, significant volatility, liquidity, technological, and regulatory risks. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures/ for additional important information.