We Need to Re-Think Decentralized Governance, by Blake West of Goldfinch

Hello Defiers! Today we are diving into the all-important topic of governance. In DeFi, governance refers to the way decisions in a protocol are made. The common goal in this new and rising financial ecosystem is that control over protocols and applications will be in the hands of a wide user-base so that they are community-run. This is in stark contrast with traditional finance —and really with almost any other industry— where all decisions are made in a centralized way, that is, within a small management team inside a corporation.

The goal is that in a Web3 future, individuals will have ownership and participation in the platforms they use, in the same way that they are in control of their assets and information. But this is no easy feat. Projects have tried to solve this by creating token-based voting mechanisms, where holders can cast token-weighted votes. The mechanism has been hailed as something akin to token democracy. Blake West, co-founder of Goldfinch, argues why that’s not true. He says the current system isn’t a democracy; it’s a plutocracy, And while that’s become an increasingly common criticism in DeFi, West’s response is a lot more original: He has come up with actual formulas to measure a protocol’s level of decentralization, and also it’s level of governance liability. read on to figure out what they are and how some of the most popular Ethereum DeFi projects stack up.

Both paid and free subscribers receive the full guest post, but paid subscribers got it early. Paid subscribers also get complete access to The Defiant content and archive, and access to The Defiant Discord chat. Join the club! Pay with Dai on this link (100 Dai/yr) or in fiat ($100/yr, $10/mo) at the link below.

Subscribe now

🙌 Together with Zerion, a simple interface to access and use decentralized finance.

A Token Doesn't Make You Decentralized. So What Does?

By Blake West, Goldfinch co-founder

On Sept 17th, 2020, Uniswap air dropped 150M tokens — worth ~$450M at the time — to anyone who'd ever interacted with the protocol. Many viewed this as a move towards decentralization. In fact, The Defiant, perhaps my favorite publication in the space, wrote that day, "UNI is now held by more than 50k Ethereum addresses, making it instantly one of the most decentralized tokens in DeFi". Another commenter on Twitter said, "Uniswap gave a $1200 ownership stake to anyone who ever used the protocol... this is decentralization." I disagree.

Strong blockchains like Ethereum — having been built on decades of cryptographic research, years of implementation effort, and deep communities — are already highly decentralized. Applications and protocols built on top of them inherit this decentralization for free! So is adding plutocratic token governance really going to help decentralization? I'm doubtful. But protocols are products and products need to change (through some kind of governance), so we're left with a tension that I want to explore here.

Decentralization ≠ Democracy

For a while, the notion of "community governance as decentralization" has bugged me. The idea seems to be that the more people who own your token and have voting rights, the more "decentralized" it is. But by that metric, Google would be much more decentralized than Uniswap, since it's a publicly traded company with technically millions of shareholders who can all vote and appoint managers. Granted, most shareholders do not actually vote because most all public companies use voter delegation. By default, your vote goes to a voter proxy advisory firm such as ISS who votes on your behalf. And funny enough, this type of delegation system is exactly what Uniswap is trying to push as well!

But if Uniswap — and most other protocols — are slowly just re-creating the American corporate governance system, then it may be time to take a step back and consider how we think about protocol decentralization. How do you measure it? When are you moving closer and when are you not? Which projects today are truly decentralized and which are overselling their claim?

Regarding on-chain governance specifically, I view governance as the duct tape that goes over holes in your decentralization design.

Decentralization is Public, Valuable, and Stable.

True, idealized decentralization for a protocol or app means anyone can repeatedly gain value from a system where the rules won't change (ie. "public, valuable, stable"). To break that down, 1.) I say "anyone" because a user may have a smart contract wallet on Ethereum that they own, but that's not decentralized because only the user can get value. 2.) I say "gain value" because I want to exclude things like a rock sitting on the ground, or a broken smart contract. Sure, anyone can use it, and it won't change, but it's not valuable, so it's just not interesting to include in a discussion of "decentralized systems". 3.) I say "repeatedly", because we should also exclude obviously unsustainable things, like a one-time airdrop, or some free-money smart contract. 4.) But the "where the rules won't change" part is probably the most interesting and least well understood for decentralization. There are countless products and services where anyone can repeatedly gain value (eg. Google, Twitter, your local pizza shop etc.), but the key reason these services aren't decentralized is because any rule can change at any moment, and the user generally cannot just opt-out of those changes without losing access to the original product.

I would in fact say that this idea of stability in digital systems is the unique breakthrough that crypto offers. For millennia we've been able to use public parks for exercise, sports, or market places and be reasonably sure the park isn't going to erect walls or charge you a fee tomorrow. But our digital spaces have had no such equivalent. We could only build private property online, and as such interests get misaligned and we could never be quite sure what would happen next. But blockchains finally offer us the ability of creating public, valuable, and stable digital spaces. We can build more than just space too — we can build digital libraries, colosseums, and entire decentralized industries — if we choose to.

The Protocol Decentralization Spectrum

The tenets of decentralization above are not absolutes. Nothing can be 100% public, 100% stable, or always valuable. And protocols can only ever be as decentralized as the blockchains they are built on. This is ok. Our job as builders in crypto is to get as close as we can. It's an iterative process. Even BTC and ETH themselves are constantly making changes. So it would be helpful if we had a framework for both measuring decentralization across projects, and how to move closer to the right side. While the framework I present is not objective, and reasonable people could disagree on where a particular project falls, I believe it can help us frame potential changes, and provide directionally accurate judgments. In it's most simple form, we can think about decentralization as:

$Decentralization = P * V * S$

Where P is how public it is on a scale of 0-1, V is a binary 0 or 1 of whether it provides repeatable value to its users, and S is how "stable" it is on a scale of 0-1 (ie. likelihood that important rules change against you). The higher the number, the more "decentralized" a project is.

Being public is pretty easy, and being valuable is table stakes. So I want to focus on "S" and how we measure stability because it's the most difficult part to get right — and also the one where most projects fall short.

Governance As A Decentralization Liability

Governance of any kind, by definition, has the power to change at least some rules of the game. Thus it directly hurts the idea of stability. But I want to be clear there is always some form of governance. Even if it's implicit, like "hard fork governance" for BTC and ETH, it's there. And incidentally, hard forking is probably the least bad type of governance because it cannot actually impose rule changes. All it can do is offer a new game, and invite you to join.

So all decisions made by any form of governance — or usage of oracles — are decentralization liabilities. But that liability can range from essentially zero, with an ownerless ERC20 contract, to rather large, like when Andre Cronje still had unilateral control over the yEarn contracts. To ascertain a project's "governance liability", it's useful to start by asking two key questions about each decision it makes:

1. How important is this decision to the ongoing success of the protocol?
2. How often must these decisions be made?

Think of these like two variables between 0 and 1, and the product of these numbers is how much of a liability that decision is. For example, take the decision to have a fixed supply of 21M BTC. This was a very, very important decision, but it was made exactly once at the beginning and never touched again, so the frequency is zero, thus total liability is zero. But now imagine if there was a coin weighted vote every week on the total supply of BTC. Would you be as willing to HODL BTC? I'm guessing maybe not, because intuitively, you can just feel that adding the ability to change something that important, even through a coin-weighted vote, makes it less stable, and therefore less decentralized, not more. On the other extreme, imagine every week BTC does a coin weighted vote and the only thing this governance can possibly do is decide to send a pizza to one lucky address of their choosing. This decision would be very frequent, but also very irrelevant, and so this would — aside from being weird — likely not change your perceptions too much. A good example of something in the middle is ETH miners are allowed to vote to change the block gas limit — a factor of minor importance — and only by 0.1% each block, which limits the rapidity of change, and therefore mitigates stability risks to the system.

We can think of the full governance liability of a protocol as the sum of the individual liabilities for each decision governance makes:

$GovernanceLiability = \sum Freq_d * Importance_d$

The higher the governance liability of a project, the lower the value of "S" and thus the less decentralized. We can visually think of the governance liability as simply moving you further away from decentralization, like this:

Applying to Maker Vs. Uniswap

This is why I consider a protocol like Maker to be not very decentralized. I believe their governance liability is fairly high due to the fact that governance has to keep adjusting the DAI savings rate, the stability fee, and risk parameters, all according to market conditions. These are all very important and frequent decisions. Also, because of their design, it is unlikely to ever stop. There is no "correct" or "stable" savings rate which can be found that would render unnecessary any future changes. It is a huge liability for their decentralization story. Contrast this with say, Uniswap, where they have a fee paid to LPs. This is also a very important parameter, and also market-driven, but it's never changed, and it has a much smaller range of acceptable values (eg. never 0, and likely never > 3%). Further, you could imagine ways to automate it (eg. always pick the median fee among peer exchanges with > X volume), or you could imagine the community just forking and setting a new number if it really became a problem. The spirit of what I'm getting at is around "how often is difficult collective human decision making or work required for continued usage of the protocol, and could you ever see it being automated or happening without any governance at all?" The more of the former, the worse, and the less of the latter, the worse.

Mitigating the Governance Liability

If a decision must be made by governance, then you can mitigate some (but never all) of that liability depending on the type of governance, and the mechanism. This is where democracy, plutocracy, councils, futarchy, time-locks, and all other on-chain governance mechanisms come into play. When comparing governance options, the key questions to ask are:

1. Does this form of governance make the frequency of decisions go down? (ie. increase stability)
2. Does this help ensure a high "net promoter score" for a decision? ie. percent that benefits minus percent harmed is usually a high number.

Democracy tends to help with both! It's slow and tough to pass changes (which helps stability), and requires a majority, which is (usually) directionally correct for the second part. Projects on crypto, however, can't really implement actual democracy right now, because there is no viable ID system yet. Instead, they reach for plutocracy (coin-weighted votes). Which is markedly worse than democracy, as a wealthy few typically control the protocol. That concentration of power directly harms both of the above tenets. A few with concentrated power can more speedily push through changes, and the odds that the change is in conflict with others is higher.

So to me, it's clear that our current forms of on-chain governance can't **be the answer. As stated before, at best they are duct tape to paper over holes in your decentralization design. You should always try to solve the problem first with better design, and governance as a last resort.

Visually, you can think about the mitigation like this:

Comparing all different forms of on-chain governance in terms of how they affect decentralization is beyond the scope of this article, but I hope the questions above can spark productive conversation.

Applying To Current Projects

Putting all this together, here's a map of how I see some current projects (both crypto and non-crypto) on this axis of decentralization. Please note this is rough, and not meant to be exhaustive by any stretch. The point isn't to quibble over whether Uniswap is more or less decentralized than Compound. The point is to start conversations and building intuitions by applying the framework above in a concrete way that I think is at least in the right ballpark. Also note, I'm leaving out blockchains themselves because this article is about app and protocol decentralization, not blockchains, which already have had much written about measuring their decentralization.

To explain my thinking, I put yEarn and Maker on the "less decentralized" side, because they have many important decisions that get made frequently. Some of Maker's were already discussed, but with yEarn for example, all the strategies have to be voted on by governance. So do funding mechanisms, and fees, and dev salaries and all sorts of important things that are liable to keep changing. Worse still, yEarn is a plutocracy, with highly skewed distributions and low participation. As an example, this yEarn proposal from last year to "formalize operations funding", had 118 participants (~0.5% voter turnout), with fully 2/3 of the "yes" voting power coming from eight addresses. That's not much mitigation of their governance liability in my opinion. I view yEarn as essentially running a company, and if the SEC pressed them, I have a feeling it would be deemed a security (ie. not "sufficiently decentralized").

My reasoning for putting Compound and Uniswap further on the decentralized side is that, while they also have highly skewed plutocratic governments, they at least have systems where, if governance simply ceased to exist, both would continue to provide value for likely years to come. yEarns lifeblood, however, is always being up on the latest to ensure it's generating the highest yield. Maker is in a similar boat, if they don't keep updating to market rates, the system could unravel quickly, which reveals their lack of decentralized stability.

Decentralization is Inefficient

I wish there was an easy 1-2-3 for making your project more decentralized, or a simple way to reduce all the key governance decisions. But I don't think that's the case. Taking Maker as an example, it's not like Maker wants to have all these important governance decisions. If they could just automate or eliminate them, I'm sure they would. Maybe they could automate the DAI savings rate, or maybe they could come up with a staking mechanism that allows for a market dynamic to arrive at the correct rate. These would be more decentralized, but that's not just flipping a switch. Those are big changes and who knows if they would work. Same with yEarn or other aggregators. There's no "decentralize" button to hit.

As an example of how that plays out, let's consider another crypto project, the Graph. The Graph is the "query layer" for blockchains, and they allow you to quickly access transformed data about any protocol. They were firmly a centralized product for the first 3 years of their existence, and just recently launched their decentralized protocol. They have many "indexers" on the platform who people need to trust in order to get query data from them. The easy way would be to have governance vote on a trusted set of indexers. But that's not decentralized! You have to dig deeper to get there. So instead, they have a staking mechanism where anyone can be an indexer and stakes their GRT token on a "subgraph" (set of queries), which can be slashed if they misbehave. That is more decentralized. But that's also "inefficient". Each indexer now needs to buy GRT, and pick an amount to stake, and you have to build in a slashing mechanism, and have some way to judge what really counts as misbehavior, etc. All of those things add cost, complexity, and time.

But in the long run, none of that matters. In the long run, crypto's staying power will come from the public, valuable, and stable systems that we build as a community. Projects that aren't working towards this aren't building the future, they're just building a company.

The truth is decentralization is hard and expensive. And I mean that literally. As the example of the Graph demonstrates, decentralization often comes at the expense of short term efficiency. This linkage is fairly iron-clad. So if you have a design that reduces governance decisions, but your first impulse is it couldn't work because it's expensive or slow, you should catch yourself, because you might be onto something! Monstrous gas costs, and absurd electricity usage is the price that Ethereum and Bitcoin have paid for their decentralization, and truly decentralized applications must pay a similar cost for their domain. What they gain, however, is long term stability and credible neutrality. With that comes a global community willing to use, and build on them for decades to come.

Subscribe now

The Defiant is a daily newsletter focusing on decentralized finance, a new financial system that’s being built on top of open blockchains. The space is evolving at breakneck speed and revolutionizing tech and money. Sign up to learn more and keep up on the latest, most interesting developments. Subscribers get full access, while free signups get only part of the content. Click here to pay with DAI (for $100/yr) or sub with fiat by clicking on the button above ($10/mo, $100/yr).