Rethinking Decentralized Governance: The Shortcomings of Maker and Yearn

This article was published in The Defiant, authored by Blake West, and compiled by Echo.

Does having more token holders and higher community voting frequency lead to a higher degree of decentralization for a project?

Recently, The Defiant published an article by Blake West titled "We Need to Re-Think Decentralized Governance," which reflects on and questions the aforementioned viewpoint, arguing that stability is also an important indicator of a project's decentralization. Frequent token-weighted voting can reduce the degree of decentralization of a project, as seen with Maker and Yearn, where governance responsibilities are excessively high. 1. Issuing tokens does not make a project more decentralized

On September 17, 2020, Uniswap airdropped 150 million tokens to everyone who had used the protocol, valued at approximately $450 million at the time. Many believed this was the beginning of a move towards decentralization. That day, my favorite publication in the space, The Defiant, wrote: "UNI now has over 50,000 Ethereum addresses, making it one of the most decentralized tokens in DeFi." Another commentator on Twitter said, "Uniswap gave away $1,200 worth of ownership to anyone who had ever used the protocol; that’s decentralization." But I disagree.

Powerful blockchains like Ethereum are already built on a highly decentralized foundation, established on decades of cryptographic research, years of implementation work, and a deep community base. Applications and protocols built on them automatically inherit decentralization characteristics, so does adding a feudal-style token governance mechanism really help decentralization? I have my doubts. Protocols are products, and products need to be upgraded through some form of governance, so I want to explore the tension in this relationship.

2. Decentralization ≠ Democracy

For a while, the concept of "viewing community governance as decentralization" troubled me. The idea seems to be that the more people who hold the token and have voting rights, the higher the degree of decentralization. However, by this metric, Google is far more decentralized than Uniswap, as it is a publicly traded company with technically millions of shareholders, each with voting rights.

Of course, most shareholders do not actually vote, as most public companies use a delegated voting system. By default, voter votes go to voter proxy consulting firms that represent voter votes, such as ISS. Interestingly, this type of delegation system is precisely what Uniswap is trying to promote.

However, if Uniswap and most other protocols are slowly rebuilding the U.S. corporate governance system, perhaps it’s time to step back and consider how we view decentralized protocols, which projects are truly decentralized, and which ones are over-marketed?

Specifically, I view on-chain governance as "super glue" covering the gaps in decentralized design.

3. Decentralization is public, valuable, and stable

Admittedly, for a protocol or application, idealized decentralization means that anyone can repeatedly derive value from a system where the rules do not change (i.e., "public, valuable, and stable").

First, I say "derive value" because I want to exclude certain things, like a broken smart contract. Of course, anyone can use it, and it won’t change, but it has no value, so including it in the discussion of "decentralized systems" is not interesting.

Second, I say "repeatedly" because we should also exclude obviously unsustainable things, like one-time airdrops or some free smart contracts.

Third, the "rules do not change" part may be the most interesting and least understood aspect of decentralization. There are countless products and services from which anyone can repeatedly derive value (like Google, Twitter, your local pizza shop, etc.), but the key reason these services are not decentralized is that any rule can be changed at any time, and users typically cannot opt out of these changes without losing access to the original product.

In fact, what I want to say is that the idea of stability in this digital system is a unique breakthrough provided by cryptography. For thousands of years, we have been able to utilize parks for exercise, sports, or market activities and ensure that the park won’t erect walls or charge you tomorrow. But our digital space has no such equivalent; we can only establish private property online, and with these misaligned interests, we can never be sure what will happen next.

But blockchain ultimately gives us the ability to create a public, valuable, and stable digital space. If we are willing, we can build not just space—we can build digital libraries, arenas, and entire decentralized industries.

4. A framework for judging the degree of decentralization

The aforementioned principles of decentralization are not absolute; nothing can be 100% public, 100% stable, or eternally valuable, and protocols can only be as decentralized as the blockchains they are based on. The work of crypto builders is to get as close to this goal as possible; it is an iterative process, and even BTC and ETH themselves are constantly changing.

Therefore, having a framework that can measure the decentralization of projects and gauge how closely they align with the right direction would be very helpful. Although the framework I propose is not objective, and rational people may disagree on the specific positioning of a given project, I believe it can help us identify potential changes and provide accurate judgments. In its simplest form, we can view decentralization as:

Decentralization = P * V * S

Where P refers to its degree of publicity on a scale from 0 to 1, V refers to the repeatability of value for users on a scale from 0 to 1, and S is its stability on a scale from 0 to 1 (i.e., the likelihood of important rules being unfavorable to users). The higher the resulting value, the more "decentralized" the project is.

Publicity is easy, while value depends on luck. Therefore, I want to focus on "S" and how we measure stability, as this is the most challenging part and the aspect most projects fail to reach.

5. Governance as decentralized responsibility

As the name suggests, any form of governance has the power to change at least part of the rules of the game. Therefore, it directly undermines the idea of stability. But it is certain that some form of governance always exists, even if it is implicit, such as the "hard fork governance" of BTC and ETH. Hard forks may be the worst type of governance because they cannot actually enforce rule changes; all they can do is provide a new game and invite users to continue joining.

Thus, all decisions made by any form of governance are decentralized responsibilities. In the case of ERC20 smart contracts with no owners, this responsibility can be virtually zero, but sometimes it can also be quite significant, such as when Andre Cronje still had unilateral control over the Yearn smart contracts. To determine a project's "governance responsibility," two key questions should be asked for each decision made:

First, how important is this decision for the ongoing success of the protocol?

Second, how often must these decisions be made?

You can imagine them as two variables between 0 and 1, and the product of these two numbers represents the size of the responsibility borne by the decision-maker. For example, determining the total supply of BTC at 21 million is a very important decision, and once established, no other decisions have been made since, so the frequency of change is zero, and total responsibility is zero.

But imagine if the total supply of BTC were voted on weekly based on token-weighted voting; would you want to hold BTC long-term? I guess probably not, because intuitively, you can feel that even if token-weighted voting can increase the ability to change important things, it would reduce the stability of the project, and thus the degree of decentralization would also decrease.

We can view the total governance responsibility of a protocol as the sum of the individual responsibilities borne by each decision:

The higher the governance responsibility of a project, the lower the "S" value, and correspondingly, the lower the degree of decentralization. We can intuitively view governance responsibility as distancing users from decentralization, as shown below:

6. Application to Maker and Uniswap

This is also why I believe protocols like Maker have a low degree of decentralization. I think their governance responsibility is quite high, and governance must constantly adjust the DAI savings rate, stability fees, and risk parameters based on market conditions, all of which are very important and frequent decisions. Moreover, due to the design of the protocol, it cannot stop forever. There is no "correct" or "stable" savings rate, which will lead to any unnecessary changes in the future. This is a huge responsibility in their decentralization narrative.

In contrast, Uniswap pays a fee to LPs, which is an important parameter driven by the market, but it has never changed and has a much smaller acceptable range (e.g., never zero, and likely never more than 3%).

Additionally, you can imagine ways to achieve automation, such as always choosing a median ratio fee, or you can imagine the community forking and setting new numbers. The question to solve is, "How long does it take for collective human decision-making or work to continue using the protocol? Can users see that it is automated and can operate without any governance at all?" The more of the former, the worse it is; the less of the latter, the worse it is.

7. Mitigating governance responsibility

If decisions must be made based on governance, some (but not all) responsibilities can be mitigated depending on the type and mechanism of governance. This is where democracy, oligarchy, parliament, futarchy, time-locks, and all other on-chain governance mechanisms come into play. When comparing governance schemes, the key questions to ask are:

First, can this form of governance reduce the frequency of decisions? (i.e., increase stability)

Second, does it help ensure a high "net promoter score" for decisions? For example, the percentage of benefits minus the percentage of harms is very high.

Democracy often helps with both. Changes are often slow and difficult and require the support of a majority of users, but this helps with stability. However, due to the lack of a viable user ID system, cryptocurrency projects currently cannot truly achieve real democracy. And they pursue oligarchy (token-weighted voting based on the number of tokens). This is clearly worse than democracy, as the minority controls the protocol, and centralization directly undermines both principles mentioned above, allowing a few power holders to push for changes more quickly, with a higher likelihood of conflict with others.

Clearly, the current forms of on-chain governance cannot be the answer. As mentioned earlier, they are at best just using tape to cover the gaps in decentralized design; we should always prioritize better design to solve problems before considering governance as a last resort.

As shown in the figure below, you can think of mitigation measures this way:

Comparing the impact of various forms of on-chain governance on decentralization is beyond the scope of this article, but I hope the above questions can spark productive dialogue.

8. Application to current projects

In summary, this is how I view some current projects from a decentralization perspective. Please note that this is rough. The point is not to argue whether Uniswap is more decentralized than Compound, but to apply the above framework in specific ways to start a dialogue and build intuition. It is also important to note that this article is about decentralized applications and protocols, not blockchains.

I place YFI and Maker on the "lower degree of decentralization" side because they frequently make many important decisions. However, in the case of YFI, all strategies must be voted on by the governance layer, including funding mechanisms, fees, developer salaries, and various important things that are prone to change. Worse still, YFI is ruled by an oligarchy, with a highly skewed distribution and low participation.

For example, last year, the proposal regarding "formal operating funds" for YFI had 118 participants (with a voter turnout of about 0.5%), and two-thirds of the "yes" votes came from just 8 addresses. In my view, this does not mitigate their governance responsibility. I believe YFI is essentially running a company, and if the SEC pressures it, I think it could be viewed as a security (i.e., "not sufficiently decentralized").

The reason I place Compound and Uniswap on the "higher degree of decentralization" side is that although they also have highly skewed oligarchic rule, at least they have a system where they will continue to provide value in the coming years even if governance does not exist at all. But YFI's lifeline is always in a state of flux to ensure the highest returns. Maker's situation is similar; if they stop updating market prices, the system could quickly collapse, indicating a lack of stability in decentralization.

9. Inefficiency of decentralization

I wish there were a simple step to make projects more decentralized or a straightforward way to reduce all key governance decisions. But I don't think that's the case.

Take Maker as an example; Maker does not want to have these important governance decisions. If they could automate or eliminate them, I believe they would do so. Perhaps they could automate the DAI savings rate or propose a staking mechanism that dynamically reaches the correct interest rate in the market. This would be more decentralized, but it’s not just a matter of flipping a switch; these are huge changes, and no one knows if they will work. Like Yearn or other aggregators, there is no "decentralization" button to click.

Another example is The Graph, which is the "query layer" of the blockchain, allowing users to quickly access transformation data about any protocol. In the three years of its initial existence, they were always a centralized product and have only recently released a decentralized protocol. They have many "indexers" on the platform, and people need to trust these "indexers" to get query data from them. The simplest way is to vote on governance for a set of trusted indexers.

But that is not decentralized; you have to dig deeper to get there.

Thus, the project has a staking mechanism where anyone can become an indexer and stake their GRT tokens on a "subgraph" (query set). If they behave improperly, their tokens can be deducted as a penalty. This method is more decentralized but also inefficient. Each indexer now needs to purchase GRT and choose an amount to stake, and you must establish a significant penalty mechanism and have some way to determine what constitutes true misconduct. All of this adds cost, complexity, and time.

But in the long run, none of this matters. The durability of cryptocurrency will come from the public, valuable, and stable systems we build as a community. Projects that do not strive for this are not building the future; they are merely building companies.

The fact is, decentralization is arduous and expensive. Decentralization often comes at the cost of short-term efficiency, and this connection is absolute. So, if you have a design that reduces governance decisions, your first impulse may be to dismiss it because it is expensive or slow.

The enormous gas costs and absurd electricity costs are the price Ethereum and Bitcoin pay for their decentralization; truly decentralized applications must pay similar costs for their domains. But in return, they will gain long-term stability and trusted neutrality, along with a global community willing to use and build upon them for decades to come.