Governance Tokens - The Good, the Bad, The Ugly
Part II of "Fork Law Meditations"
Intro/Recap
In Fork Law Meditations: Part 1, we teed up some concepts about how property rights can relate to blockchain systems and identified four main blockchain ecosystem components in which persons might have property-ish rights or interests:
tokens
smart contracts
networks
protocols
This will enable us to discuss governance tokens and start to ask better versions of the question—what do “governance tokens” govern (or what are they supposed to govern), exactly? —and perhaps start to offer some answers.
Some Governance Token Types
“Governance tokens” appear to fall into a number of actual and potential categories, based on which types of interests they govern or protect. In reality, governance tokens could govern many things, including dimensions beyond the four I have identified above—for example, governance tokens can also govern aspects of consensus (assuming we view e.g. staking delegation as a form of ‘voting for validators’)—but for now I want to stay focused on the aspects of blockchain systems most directly implicating property-ish rights and thus will indulge in some simplification by classifying governance tokens based on the four dimensions of blockchain systems identified above.
Anti-Governance. Tokens like BTC and ETH may be described as ‘anti-governance’ tokens because they do not natively confer any governance rights or powers. BTC and ETH do not natively vote (though of course can be extrinsically polled, e.g. through so-called “carbon votes”) or govern anything. It does not require a vote of ETH holders to permit a smart contract to be deployed to Ethereum, nor does it require a vote of ETH holders to decide whether to censor such a smart contract or reorg the blockchain in a manner that might affect the results of operations of such a smart contract. The networks are governed directly by node operators and indirectly by users—which software a node runs, and thus how the peer-to-peer network is governed, is not determined by a vote of BTC holders or ETH holders, but by each individual node operator. The protocols are governed directly by ‘core developers,’ but more indirectly are governed through a complex interplay between node operators (and their users) and core developers. Because node operators can decide whether to upgrade to a new version of the protocol client, and because the default decision is not to upgrade (i.e., protocol client changes are opt-in, not opt-out), core developers must develop features of the protocol client in quasi-dialogue with node operators and users—a protocol client change that will not be adopted by node operators will probably be pointless. Such anti-governance tokens also do not govern other tokens, since there is no voting of BTC or ETH to determine how BTC or ETH are distributed or minted, inflated or deflated, etc.
Protocol/Network/Partial Token Governance. The Tezos token (TZS) is described as empowering holders to govern the Tezos protocol through “self-amendment” effected by token voting. As a result, “Tezos [can] upgrade itself without having to split (‘fork’) the network into two different blockchains.” This effect is achieved by requiring TZS votes on client upgrades and making approved client upgrades automatic and opt-out rather than (as they are on Bitcoin and Ethereum) manual and opt-in. Client upgrades also govern the inflation schedule, supply and other features of the TZS token and thus have a measure of token governance. We assume, however, that based on the ‘anti-fork’ principle seemingly embedded in Tezos’s governance descriptions, TZS holders are at least not supposed to exercise their voting powers to effect reorgs that would more directly affect TZS property rights—such as moving TZS from the wallet of one person (e.g., a thief) to that of another (e.g., the victim). Thus, we will say that TZS holders can be said to govern both the Tezos protocol and the Tezos network and to partially govern the TZS tokens. As far as we know, deployment of smart contracts to Tezos remains permissionless, and, again, based on the apparent ‘anti-fork’ principle embedded in social norms about Tezos governance, we assume that reorgs affecting smart contracts are not acceptable—thus, TZS would not have the power or right to govern smart contracts.
Total Governance. DOT, the governance token for Polkadot, appears intended to have even more comprehensive governance powers and rights than TZS does on Tezos. For example, the Polkadot Wiki expressly invites DOT holders to “appeal to the on-chain council to enact a change on your behalf[, such as in] the case of lost or locked funds when the funds were lost due to a human interface error (such as inputting an address for another network)…When these circumstances can be proven beyond a reasonable doubt to be an error, the council may consider a governance motion to correct it.” Thus, DOT holders are expressly empowered to effect chain reorgs, which means that they ultimately completely govern DOT, all other tokens on Polkadot and all smart contracts on Polkadot, even if initial smart contract deployment is permissionless.
Protocol/Smart Contract Governance. MKR, the governance token for MakerDAO, is an example of a token that governs both a smart contract protocol and its specific instances (i.e., specific deployed smart contracts). An example of protocol governance is when a vote of MKR holders was held to approve the deployment of the Multi-Collateral DAI (MCD) system as the new canonical instance of MakerDAO, which included approving changing the name of the token that was originally called “DAI” to “SAI” and creating a new token for MCD which would now be deemed “DAI” instead. Examples of smart contract governance through MKR occur weekly when MKR holders vote on changes to stability fees and other parameters of the deployed MCD system. Unlike in the case of Tezos or Polkadot, where the governance tokens are also the fundamental native tokens of the blockchain, MakerDAO is deployed to Ethereum—accordingly, protocol governance cannot be completely automatic but necessarily involves an extrinsic social dimension—of which the name change from “DAI” to “SAI” is symptomatic. On the other hand, the governance of smart contract parameters can be cryptonative (notwithstanding the social dimension to crafting the proposal to be voted on, coordinating the vote and marshaling support for a particular outcome). MKR also partly governs MKR and thus involves token governance as well, though we find this aspect less interesting for purposes of this article.
Treasury Governance. Some tokens, like UNI and YFI, may primarily govern treasuries of the same token or other tokens. This will be further discussed below. Many times, treasury governance can slip into other forms of governance, depending on what the treasury funds are applied. For example, in Yearn, the treasury funds are applied to funding further Yearn technological development—thus, YFI holders making decisions on how to use treasury funds tends to also empower them (at least partly) to make or influence technology development decisions.
Why Governance Tokens? - The Official Narrative
One hopes that governance tokens may be seen as serving certain functions through which they solve certain problems or fulfill certain needs, though it is also likely that the existence of a governance token creates new problems and needs.
An analogy to Bitcoin might be helpful—giving nodes the power to determine the state of a ledger affecting people’s property rights solves a problem (getting rid of the need for intermediaries and trust in them to create and maintain a ledger), but also creates a new problem, which is that unaccountable nodes might act selfishly and supply bad blocks/chains to the others. Thus, an additional solution is needed—namely, proof-of-work as an anti-sybil mechanism.
Similarly, a governance token can allow a group of incentive-aligned persons to decide how to dynamically set smart contract parameters. This solves a problem if such parameters need to be adaptable in order for the smart contract to function well. An example is MakerDAO—a wide variety of market conditions (price of ETH, demand for DAI transactions, bullish and bearish sentiments for ETH, etc.) may affect how DAI is valued, and thus frequent parameter-tweaking is needed to keep DAI reasonably close to its “peg” of $1 USD. But the governance token’s existence also means that token holders could set the parameters maliciously, and thus having a governance token creates an attack vector. Thus, new problems and issues are created—e.g., how to set quorum requirements and other procedural protections in a way that protects against such attacks? And so on.
Roughly speaking, governance tokens are one answer to the question: who decides on changes to this system? The answer can be: Well, the governance token holders decide! One can imagine other deciders—e.g., node operators and core devs , who decide on protocol changes for Bitcoin and Ethereum—but systems with governance tokens have been designed with the aim of having the holders of that specific token type decide such changes instead of other types of ‘community participants’ or ‘stakeholders’.
This suggests a rough working framework:
If there was no need for system changes, then the governance token would be unnecessary.
If the measure of what constitutes a good change for the system does not tend to align with the measure of what a token holder in his capacity as such would vote in favor of (e.g., because a good change might adversely affect the value of the token) or the measure of what constitutes a bad change for the system does not tend to align with the measure of what a token holder in his capacity as such would vote against (e.g., because a bad change might increase the value of the token), then the governance token would not be suitable for deciding on system changes.
Conversely, if adequately informed token holders in their capacities as such will tend to vote in favor of substantially all positive system changes and vote against substantially all negative system changes, then the governance token aligns incentives and is suitable for deciding on system changes.
Of course, the words “in his capacity as such” are critical here. Real people have multifarious interests. A given governance proposal might be reasonably expected to increase the value of the governance token if the proposal is approved, but a given governance token holder might also coincidentally have a market short on the price of the governance token, and that holder might decide to vote the governance token in his capacity as a short holder rather than in his capacity as a governance token holder. The voter might not even really be a long-term governance token holder at all, but might be borrowing the governance token solely to vote.
At that point, the assumptions about incentive alignment break down. This does not mean the governance token is a bad method of deciding on changes—it can still be a good method, provided that other dynamics make it reasonable to assume that a sufficient critical mass of the token holders will vote in their capacities as token holders rather than in other capacities. Or, you can flip it—if you can set up distribution & holding so that nearly every token holder is likely to also be a user, then you can assume that nearly every token holder is voting in a user capacity rather than merely in a token holder capacity. Every decentralized system needs such an ‘honest majority assumption’ and breaks down when that assumption is violated, so this ‘problem of mixed capacities’ is not a design flaw more inherent to governance tokens than other methods of decentralized decision-making.
Why Governance Tokens? - The Dark Side
Unfortunately, there are other possible answers to the question of “why governance tokens?”: (1) regulatory arbitrage; (2) liquidity/profit; and (3) more recently, user acquisition through bribery aka “liquidity mining”.
Certain decisions—for example, the decision to enable trading for a token that may be a security on a DEX—can violate regulations; therefore, people may create a governance token for making that decision not because it is an elegant solution, but because they wish to shift the risk of making an illegal decision onto an inchoate group of others and/or have plausible deniability regarding their support of that decision, even if this results in less efficient and secure decision-making overall. Thus, governance tokens can create or be intended to create regulatory arbitrage and shift the risk of violating laws, regardless of whether they are otherwise good mechanisms for decision-making.
Like any token, because it has a price and market, a governance token can enable founders and early investors to gain liquidity in their otherwise illiquid investments by converting their investment rights into a governance token and selling the token into a market that has been created through an airdrop, liquidity mining or other public governance token distribution method. When the governance token theoretically has or can acquire the right or power to receive “protocol fees',” this method of obtaining liquidity can be an especially rational one. This is also itself a regulatory arbitrage strategy as well, because the “governance rights” create a (albeit typically weak) argument that the token is not a security because the token holders are, in the aggregate, responsible for their own value, thus enabling early investors and founders to arguably enjoy all the benefits of an IPO without the detriments that are typically imposed on such liquidity events by securities regulations. Governance tokens confer these liquidity benefits even if they are overall bad solutions to governance or if little or no governance is really needed.
An under-specification of the rights, powers and purposes associated with a governance token usually betrays that these more insidious purposes are important motivations for the token. This does not mean that the token does not also serve the more legitimate governance purposes described in the prior section, but it sometimes can mean that the governance token was not a very good solution to governance problems and its governance functions exist primarily as a pretext for it solving regulatory arbitrage problems and/or liquidity/profit problems. Alternatively, it can mean that the governance token reflects a failure to separate concerns and thus is a less efficient solution than could be achieved if each problem it addresses were tackled separately. With rare exceptions, trying to solve governance problems, regulatory problems and liquidity/profit problems through a single device—a governance token—results in muddled thinking and mixed results and represents a design failure that reduces the security of blockchain systems and their communities.
Good Guy MKR
Whatever criticisms might be found in MakerDAO overall, it is clear that MKR as a governance token both addresses important real problems (i.e., there is a need for this token) and is reasonably (although not perfectly) well designed to do so.
Because MakerDAO is a highly complex system designed to solve a difficult problem dynamically—i.e., minting and maintaining the peg for a token DAI, meant to be pegged 1:1 with U.S. dollars—it requires active decision-making. Matters such as the stability fee to be charged on deposits, the types of collateral to be accepted as deposits, the collateral ratios appropriate to reflect the volatility risks of the designated collateral types, and so on, must be dynamically decidable based on market conditions. If such a governance-heavy system is to be “decentralized” in some rough sense, then those decisions cannot perpetually be made by a specific company or institution, but need to be made on some kind of decentralized basis. Thus, a governance token for these smart contracts at least attempts to serve an important need—whether it is the best way of serving that need is not something we need to concern ourselves with here. It is a credible way of attempting to serve that need, and, so far, has done so reasonably well, albeit on a non-perfectly-decentralized basis.
Furthermore, because the system evolves, other decisions are needed. For example, someone must decide what gets to be called “DAI” within MakerDAO. Someone needs to decide which smart contracts are considered “part of” the “MakerDAO protocol” and which are not. Again, since these decisions must be made, it is potentially desirable to make them on a decentralized basis so that a “technology company” for the protocol is not needed forever and is not a central point of failure. So, MKR is credibly a tool for deciding such issues, and has been used to do so—e.g., with the ‘upgrade’ from the single-collateral DAI system to the multi-collateral DAI system.
MakerDAO is reasonably (though not perfectly) well designed to reward MKR holders for the kinds of outcomes the designers of MakerDAO deemed ‘good’ and punish MKR holders for the kinds of outcomes the designers of MakerDAO deemed ‘bad’. The good outcomes are those that are good for the users in their capacities as such—i.e., DAI holders. The bad outcomes are those that are bad for such users.
The system is designed to force MKR holders into the role of keeping DAI pegged to a dollar in a way that benefits powerless DAI users and honors their expectations. When the system is functioning well, stability fees accumulate and are used to buy back MKR—thus increasing its price and rewarding MKR holders for presumably using their governance powers well in service to DAI holders—and when the system is functioning poorly, stability fees are spent on DAI buybacks—thus increasing the price of DAI when it’s broken below its peg—and/or more MKR are printed to buy back DAI—thus lowering MKR price and punishing MKR holders for presumably using their governance powers poorly in a way that did not serve DAI holders.
Importantly, a certain kind of normativity, which values the goal of ‘maintaining the DAI peg,’ is built into the system and is not really up to MKR holders discretion. MKR holders are not empowered to decide that it would be better for DAI to become an investment asset and go up and up in value indefinitely. Although a temporary small break above the peg could benefit MKR holders, if they let DAI break freely above its peg (e.g., by raising stability fees to make it very expensive to print DAI), MKR value would eventually suffer because MKR’s price is driven by stability fees, which are paid by CDP creators, and with high stability fees and DAI prices CDPs would not be created very much because they would not present attractive arbitrage opportunities. If MKR holders decided to devalue DAI, they would be punished, as the system would become “insolvent”, protocol fees that otherwise could be used to buy back MKR would instead be used to buy DAI at a discount from Keepers, and, as a last resort, MKR would be printed in exchange for DAI, diluting each current MKR holder. Thus, the current reality of the system is that MKR holders’ discretion is rather constrained by a kind of hard-wired norm that the purpose of MKR governance is to maintain the DAI peg.
Because MKR holders’ economic interests are fairly tightly aligned with the user priority of keeping DAI usefully pegged to $1 and as abundant as it safely can be, MKR holders are also good choices to govern what future versions of MakerDAO should look like, assuming those future versions are also tied to MKR and can lead to MKR holders’ profits. Of course, there are corner cases where this reasoning falls apart—e.g., someone borrows MKR cheaply while shorting MKR and purposefully votes in a way that would lower MKR value—but the more stable MakerDAO becomes and the more MKR appreciates in price, the more this ‘governance attack surface’ shrinks.
Bad Guy UNI
Uniswap is a smart contract system that functioned well for years without any flexibility and thus without any need for governance—it is essentially an appliance sitting on the blockchain with no need for adjustable parameters or other issues. Nevertheless, it recently introduced a “governance token,” UNI.
UNI was deployed alongside a Medium article from the Uniswap team (which is organized as a corporation—which I will refer to as the ‘Uniswap Corporation’). Here is how the governance ambit of UNI was described in the article:
Parsing the claims in the above description about what UNI is supposed to provide “ownership” of, it remains rather unclear what UNI holders actually govern and why UNI needs to exist:
What does it mean to say “UNI holders have ownership over Uniswap governance”? This statement is circular and/or meaningless. Would you consider it to be an example of “Uniswap governance” when the Uniswap Corporation decides what features to add to Uniswap v3+? I would certainly say so. In fact, I would say that type of decision is by far the most important part of “Uniswap governance”. Yet this is also the decision that UNI holders have virtually no influence over today. Uniswap Corporation has lots of capital from UNI buyers (VC funds) and employs the persons most knowledgeable and active in keeping the Uniswap protocol up to date. Thus, it is Uniswap Corporation, not UNI holders, which “own Uniswap governance”. UNI holders have no input into the Uniswap Corporation—only Uniswap Corporation’s stockholders and employees do. Thus, saying UNI holders “own Uniswap governance,” when they are not even the deciders of what goes into Uniswap v3 and there is not even an express guarantee that Uniswap v3 will, like Uniswap v2, be governed by UNI, seems like an empty phrase designed to make UNI seem more meaningful than they really are.
UNI holders governing use of the UNI community treasury is meaningful because that treasury holds a bunch of UNI, UNI are worth money. However, governing the UNI community treasury cannot be the justification for UNI to exist—that would be circular. Furthermore, even if we assume that UNI is needed to govern how other UNI are spent, why are UNI holders needed to decide how to allocate the remaining un-allocated UNI now but were not necessary to decide how to allocate all the other UNI, which constitute the vast majority of UNI?—those allocation decisions were comfortably made by the Uniswap Corporation without needing a referendum of extrinsic governors. One needs to pick a theory of governance/legitimacy; the fact that the Uniswap Corporation did not trust “the community” to allocate the vast majority of UNI belies the idea that this community would be good at deciding allocations of a minority of UNI.
The fact that UNI holders govern “the protocol fee switch” is meaningful but also silly. It is a foregone conclusion that UNI holders will decide to turn on “the protocol fee switch”—without it, UNI will be value-less. Even if we assume that many current UNI holders are loyal Uniswap users who received it as an airdrop, Uniswap Corporation and its investors dominate UNI holdings and have a powerful incentive to turn on the protocol fee switch. “Governance” to choose a no-brainer choice which is a foregone conclusion is not real governance and does not explain why UNI needs to exist.
As for the ENS, token list and (lol) $SOCKs—I think it’s fairly obvious that these are not sufficient to justify a governance token with a market cap of (*checks coingecko*) nearly $900M.
In short, UNI is currently a massively overvalued governance token which serves little purpose other than creating a market that enables Uniswap Corporation to bribe liquidity providers to use Uniswap rather than a different DEX and enables Uniswap Corporation’s employees and investors to cash-out on the value of their investment by selling tokens directly or indirectly to the public now that such tokens have a market price. While I love Uniswap the product and give a lot of credit to those who created it, it has been VC-ified in the worst way possible and is now the “bad guy” of the bunch—pretending to launch UNI as a ‘protocol governance token’ when really it governs virtually nothing of any importance, and what little it does govern could very easily (and arguably more effectively) be governed in other more natural ways—such as by the Uniswap Corporation itself. Indeed, given the way UNI are distributed and the way UNI input is constrained (e.g., through elaborate quorum requirements), I would argue Uniswap Corporation and its affiliated employees and investors still govern basically everything and that UNI is a “governance token” in name and aspirations only.
Ugly Guy YFI
“The Ugly” in The Good, the Bad, the Ugly is Tuco Ramirez, who was director Sergio Leone’s favorite character and is both the comic relief and heart of the film. His character is a bit hard to describe if you haven’t seen the film, but, basically, he fits the classic archetype of the trickster. Early in the film, he is portrayed as a bumbling and helpless buffoon, but later we see him with a much more serious demeanor in a gun shop deftly hacking together a custom pistol which he uses to get the drop on Clint Eastwood’s character through expert subterfuge. He is pragmatic and opportunistic.
I choose Tuco to represent YFI and other governance tokens that launch on a decentralized or semi-chaotic basis from the start and thus are under-defined and mercurial in their rights and powers. Unburdened by either a formal or informal constitution or rules, such governance tokens essentially “govern what they govern”—if you want to know what they govern, you have to wait and see what questions they end up being asked to vote on and how or whether or by whom the results of those votes are honored. The rights and powers of such governance tokens are not defined a priori, because there is no authority empowered to thus define them—they must be self-defined over time through an iterative feedback loop involving developers, governance token holders, users and the broader ecosystem.
Initially, YFI looked like it would operate on a MakerDAO-like model in which YFI holders voted on nearly all uses of funds and changes to the protocol in the form of Yearn Improvement Proposals or YIPs. However, with YIP-41, yearn governance moved toward something like what I would call a model of “constrained delegation” in which YFI holders delegate spending decisions to a multsig and the developers funded from the multisig follow a loose social covenant to apply their time to develop the yearn ecosystem, reverting back either to the community for further informal approval (forum polling) or to YFI holders as such (formal (YIPs)) when they’ve developed something interesting they think should be added to yearn. There are no real legal agreements or hierarchies involved in any of this and it is unclear who would have what legal rights or remedies in the event that something “bad” occurred, but, so far, it has worked rather well—an excellent example of the spontaneous self-definition of a DeFi community.
Although this situation is awkward and potentially confusing to community outsiders, through it all there emerges at least one key reason for YFI to exist—to manage community development funds. Since, unlike in the case of Uniswap (which has the Uniswap Corporation to manage development funds, hire developers, etc.), there is no “company” or organization or foundation for Yearn, some method of deciding how development funds are used is needed—and, for now, that method seems to be YFI holders voting to approve certain community members having time-bound, revocable authority to allocate funds to developers, expenses, etc.. Occasionally YFI holders are solicited on the exact details of compensation for developers, but other times the Multisig utilizes the funds in a more ad hoc and discretionary manner. The rules are not completely clear, but YFI’s existence is really justified by the need to have some kind of decisionmaker about these things—and since there is no venture-backed company for Yearn, this gives YFI a reason for being, and that basic justification can be used as the fulcrum for facilitating richer community governance over time (if so desired). This makes YFI, like Tuco Ramirez, agile and pragmatic, but unpredictable and under-engineered—as a result I don’t think anyone could confidently predict what Yearn governance will look like even six months from now. This might be a good or bad thing, depending on your biases. = )
Conclusion
So, here, we have taken a spin through some governance tokens—defining one that has a really quite clear need to exist (MKR), one which has virtually no reason to exist other than to “dump on retail” so to speak (UNI), and another which is a bit of a “mixed bag” that could end up as good or bad or something in between (YFI). We have also tried to situate these in the broader context of possible governance tokens types, creating the beginnings of a possible classification framework for governance tokens which we could deepen through further analysis and discussion.
Now you may be wondering—what does any of this have to do with this series, “Fork Law Meditations”? Well, as I mentioned—the series is exploratory, so one legit answer is “I have no idea….yet”. But among the things that I find interesting about our three governance token heroes is that only one of them, MKR, has been defined in theory and practice to clearly determine what software gets incorporated “into the protocol.” Presumably, if MKR holders had rejected the multi-collateral DAI system, then the “MakerDAO' protocol” would have remained the original MakerDAO smart contract system (i.e., with the token that used to be called DAI and now is called SAI, and which only accepts ETH as collateral). But what does that really mean, and how might it impact forks?
Indeed, many interesting questions are raised by contemplating the scenario in which protocol governance token holders reject a protocol upgrade. For example, if MKR holders had rejected MCD, does that mean that MCD is prohibited from being deployed, or only that it is prohibited from being deployed “as MakerDAO” but can be deployed with a new governance token and called by some other name? Does the answer depend on whether or not MCD development was funded directly or indirectly ‘at the expense of’ the MKR holders? If it was funded by MKR holders, does that mean that it should be prohibited from being deployed if MKR holders do not want it as part of MakerDAO—on the theory that it would be wrong to steal resources from MKR holders in order to create a competing service? Does the answer depend on what person or person(s), if any, hold the trademarks to MakerDAO’s name-brand and logos? in short—what role do or should governance tokens play when it comes to defining what is “inside” and “outside” a “protocol”, and how does that role impact the legal analysis of contentious forks? Do the answers to these questions vary from governance token to governance token? Is it fair to call a token like UNI a “protocol governance token” (as it is sometimes described) if in fact it is a corporation or some other person or group of persons that really decides what “inside” and “outside” the protocol? What about the situation where developers spend resources to develop the protocol upgrades they want without any prior approval or signalling from the token holders, but then come back and run a vote before actually deploying it—is that meaningful “protocol governance” or merely window-dressing on what is essentially a coercive upgrade, since the resources have already been spent and token holders will presumably almost always reason that “some possibly good upgrade is better than a certain lack of upgrades,” unless the upgrade presents a clear and and distinct danger?
These are all questions I intend to keep addressing in this series. We must build up to them little by little through thought experiments and explorations like the above and hope that we find more clarity at the end of them than at the start. As always, thanks for following my thinking and let me know your thoughts and ideas on Twitter or Telegram (I am @lex_node on both).