I’ve long struggled with the notion of liquid governance tokens. My mental model for protocols is to think of them as quasi-nation states, and thus I tend to view each governance vote as akin to voting in an election. Under this framing, the idea that you can buy votes by buying liquid tokens seems absurd – buying votes in elections is illegal, so why should it be the main method of acquiring influence in web3?

Importantly, the logic above relies on a few core assumptions:

1. Protocols are network states and therefore resemble countries
2. Governing influence is determined in large part by the method of acquiring tokens
3. Governance rights give token holders a significant degree of control over the protocol’s future direction

Yet many projects in web3 actually don’t adhere to those assumptions. As a result, designing governance for such projects is, unsurprisingly, a much more nuanced topic. The problem is that we’re seeing many projects in the space adopt a one-size-fits-all governance model, when in reality the token designs should be much more context-driven. 

As such, the goal of this piece is to help outline a framework for designing governance tokens. There are a set of critical decision points teams must align on, and how each team chooses should impact the acquisition profile and scope of influence associated with their governance token.

When designing governance tokens, teams should ask themselves:

1. Does our project more closely resemble a corporation or a country?
2. What level of control over the project’s direction are we willing to grant to governance holders?
3. Do we even need to launch a token yet?

Let’s walk through each one-by-one.

Corporation vs. Country

Determining whether a project more closely follows the path of a corporation or country is at the trunk of the decision tree. Corporations are profit-seeking and therefore optimize for shareholder value; the motivations among governing parties are primarily financial, so a system that tends toward plutocratic governance (i.e., a system in which influence is determined by capital) might be better aligned with a corporation’s goals.

On the other hand, while financial motivations certainly drive some decisions, countries have a more pluralistic set of values. In particular, countries often optimize for the creation and sustenance of public goods. In this sense, protocols that aim to be minimally-extractive and foster broad ecosystem development resemble such countries – and to some extent, we’ve seen this with Ethereum and Optimism’s focus on public goods funding. It follows that country-like projects tend to serve a more diverse set of stakeholders, and as such should strive toward more democratic systems of governance.

Teams’ answer to this question – whether their project resembles a corporation or a country – should in large part determine whether governance tokens are acquired via capital or non-financial contributions. The more like a company, the more reasonable it is to allow users to buy governing power: the motivations of the token holders and the project are both primarily financial, so acquisition via financial means aligns the set of incentives. The more closely a project resembles a country, the more imperative it is that governance tokens are earned and not bought.

Level of Control

The next question projects should ask themselves is the scope of control they’re willing to submit to governance. This prompt is primarily about the risks associated with the acquisition of governance tokens and how to protect against such threats.

Liquid tokens expose projects to a plethora of new attack vectors – hostile takeovers, shareholder activism, short-squeezes, and more. The playbooks we see some parties run with regard to public equities will eventually creep into web3. Projects need to think about their defense strategies and limiting the set of decisions governable by token holders may be one way to do so. 

In contrast, the bar for entry with earned tokens is much higher: influence may be gained over weeks, months, or even years through completing sets of tasks that demonstrate commitment to the long-term growth of a project. That earned tokens can’t be bought and sold in a day means the relationship between the project and its governors has been built over time. The result is a deeper level of trust, which in turn should increase the scope of control a project feels comfortable granting to token holders.

Broadening the scope of control has its own downsides. Consensus by committee can be time consuming and laborious, which may not square well for projects that need to optimize for agility within crypto’s fast-paced environment. There are, of course, ways to mitigate this: time limits on voting implements necessary deadlines, dynamic delegation improves the spectrum of choices governors can select from, and many mechanisms exist to resolve gridlock. But for those areas that do require speed and adaption, ultimately the best choice may be for founders to retain authority 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 having a token may inadvertently skew product signals and distract teams from their project’s core focus. 

Our thesis is that tokens underpin a user-owned web and that, in the long-run, these community-driven networks create more robust and thriving ecosystems. But governance tokens aren’t 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 yield, and more. The design space for crafting new ownership experiences remains an open frontier, and teams shouldn’t feel forced to imbue tokens with governance rights simply for the sake of adding additional utility. 

Progressive Democratization

Lastly, there is no wrong choice within the corporation vs. country spectrum. At the end of the day, both sides seek to maximize value creation. The primary difference is that companies do so through value capture, whereas countries strive to be at the base of broader value accrual. 

Furthermore, choosing a starting point of being a “corporation” doesn’t preclude projects from evolving toward the “country” end of the spectrum. Projects are dynamic, tokens should be iterative, and the needs & wants of user groups change. Projects can progressively democratize over time (a riff on Jesse Walden’s Progressive Decentralization). There is always the option to grant subsets of users expanded governing rights based on their reputation or history of contributions. In fact, this is probably a path worth exploring – create a liquid governance token that has some base level of rights, but layer on tasks or steps users can do to earn governance rights over more specific areas. 

The point is, there are many turns teams can make when navigating the decision tree. The goal of this piece isn’t to tell teams which turns to make. Rather, the intent is to help clarify what the decision tree even looks like. There’s still significant 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 a thought partner. My DMs are always open.

***

Thank you to Jesse Walden, Li Jin, Mason Nystrom, and Adam Delehanty for reading drafts of this piece and providing valuable feedback.

For further reading on governance and token design: 

1. Dynamic Delegation: https://alana.mirror.xyz/uriXVtPV5yk0NbTVqu6sJguZNQ9SsgiUf5l-pL_ue9w
2. Public Goods in Crypto: https://alana.mirror.xyz/rdFoHkJ8jTheTwW3o0kgeQhS6gXrvVAA1ybzLpPvPCc
3. A framework for when to launch a token: https://twitter.com/AlanaDLevin/status/1551301204835270656?s=20&t=-00QtTr9XnNDuClAXGJ32Q