An overview of the framework for designing governance tokens

By: Alana Levin

Source:variant.fund

For a long time, I have struggled with the concept of liquidity governance tokens. I view the mental model of a protocol as a quasi-state, so I tend to think of each governance vote as similar to a vote in an election. In this framework, the idea that you can buy votes by buying liquidity tokens seems absurd - buying votes in elections is illegal, so why should it be the main method of gaining influence in web3?

Importantly, the above logic relies on several core assumptions:

A protocol is a network state and thus similar to a state

Governance influence is largely determined by the method of acquiring tokens

Governance gives token holders a large degree of control over the future direction of the protocol

However, many projects in web3 don't actually follow these assumptions. So designing governance for these projects is, not surprisingly, a more nuanced topic. The problem is that we see a one-size-fits-all governance model for many projects in this space, when in reality token design should be more context-driven.

Therefore, the purpose of this post is to help outline a framework for designing governance tokens. There are a few key decision points that teams must align with, and how each team chooses should affect the buy-in and reach associated with their governance tokens.

When designing governance tokens, teams should ask themselves:

Is our project more like a company or a country?

How willing are we to hand over control of the project's direction to governance?

Do we even need to launch a token?

Let's analyze them one by one.

Company vs. State

Determining whether a project is closer to going the corporate or national path is the backbone of the decision tree. Corporations are profit-seeking, and therefore optimize shareholder value; those in power are motivated primarily by finance, so a system that leans toward plutocratic governance (i.e., one in which capital determines influence) may be more consistent with corporate goals.

On the other hand, while financial motives certainly drive some decisions, states have a more diverse set of values. In particular, states are often optimized for creating and maintaining public goods. In this sense, protocols designed to minimize extraction and facilitate broad ecosystem development resemble such states — to the extent we’ve seen Ethereum and Optimism’s focus on public goods financing . From this, it follows that country-like projects tend to serve a larger number of stakeholders and thus should strive for a more democratic governance system.

A team’s answer to this question—whether their project acts like a company or like a nation—should largely determine whether governance tokens are earned through capital or non-financial contributions. The more corporate it is, the more logical it is to allow users to buy governance rights: both token holders and projects are motivated primarily by economics, so purchasing through economic means is consistent with incentives. The more a project resembles a country, the more necessary it is for governance tokens to be earned rather than purchased.

degree of control

The next question projects should ask themselves is the sphere of control they are willing to submit to governance. This tip is mainly about the risks associated with acquiring governance tokens, and how to protect against these threats.

Liquidity tokens expose projects to a host of new attack vectors — hostile takeovers, shareholder activism, short squeezes, and more. We see that what some stakeholders do with public equity will eventually trickle down to web3. Projects need to consider their defense strategies, and limiting the set of decisions at the disposal of token holders may be one way to do this.

In contrast, the barrier to entry using earned tokens is much higher: Influence may be earned over weeks, months, or even years by completing a series of tasks that demonstrate long-term impact on the project. Promise of. Earned tokens cannot be bought and sold within a day, which means that the relationship between the project and its managers has been established for some time. The result is a deeper level of trust, which in turn should expand the scope of control projects are willing to grant token holders.

Extending the scope of control has its own drawbacks. Reaching consensus by committee can be time and effort consuming, which may not be appropriate for projects that need to optimize agility in the fast-paced environment of the crypto space. Of course, there are ways of mitigating this: time limits on voting implement necessary deadlines, dynamic delegation improves the range of options available to the governance, and many mechanisms exist to resolve deadlocks. But for those areas that do require speed and adaptation, ultimately the best option may be for the founders to retain power over those decisions.

Does the project need a governance token?

Notably, projects can gather community input without granting governance rights. Launching a token for the sake of owning it can inadvertently distort product signals and distract the team from the core focus of the project.

Our thesis is that tokens are the foundation of user-owned networks, and these community-driven networks create stronger and thriving ecosystems in the long run. However, governance tokens are not the only way to make users owners. Tokens can be used to create shared security and stake in protocols, grant users access to communities or events, distribute revenue, and more . The design space for creating new ownership experiences is still an open field, and teams should not feel compelled to empower tokens with governance just to add additional utility.

progressive democratization

In the end, there is no wrong choice between corporations and states. At the end of the day, both parties are looking to maximize value creation. The main difference is that companies do so through value capture, while countries do so through broader value addition.

Furthermore, choosing to start as a "company" does not preclude the development of the project towards the "national" end. Projects are dynamic, tokens should be iterative, and the needs and desires of the user community are changing. Projects can be progressively democratized over time (an improvement on Jesse Walden's progressive decentralization ). Projects can always choose to grant users a subset of extended administrative privileges based on their reputation or historical contributions. In fact, this may be a path worth exploring - creating a liquid governance token with some basic level of rights, but users can go through tasks or steps to gain governance rights in more specific areas.

The point is, there are many shifts a team can make when navigating a decision tree. The purpose of this article is not to tell the team what changes to make. Instead, its purpose is to help clarify what a decision tree looks like. There is still a lot of room for exploration and innovation. If you're experimenting with these types of designs -- or need help thinking through these types of token decisions -- I'd love to be your thought partner. My private messages are always open.