Introducing the Two Token Governor

M^0's contribution to the next era of decentralized governance

The promise of public blockchain protocols is to provide a decentralized, permissionless, and (as) credibly neutral (as possible) ledger that eliminates reliance on trusted intermediaries who historically have been required to act as a source of truth. With the addition of smart contract capabilities, which added the ability to have the ledger perform arbitrary computations, the ability to replace these intermediaries in specific applications – particularly those in the realm of financial institutions – became possible. With this ability, a simple computer program can (in theory) replace a complex web of behemoth trust-sellers. For example, the Uniswap protocol is able to replace the various exchange houses that have come to define the modern market landscape, and it operates in a mostly decentralized, permissionless, and credibly neutral way.

Yet not all intermediation is as mechanical and objective as facilitating the fair execution of trades. Some applications require unavoidably subjective inputs. The creation of money, which is the purpose of the M^0 Protocol, is such an application. 

In an effort to bridge this subjectivity gap many decentralized finance (DeFi) protocols have added management systems into their code that are broadly defined as governance mechanisms. While these governance mechanisms are extremely broad in their scope and functionality, many of the largest players in the DeFi space have adopted a similar feature set – simple majority voting by tokenholders with the nearly unlimited ability to upgrade code. The problem with this expansive approach to governance is that it is antithetical to the raison d’être of blockchain-based systems in the first place. Applications with such broad governance powers over their smart contracts can no longer be considered decentralized, permissionless, or credibly neutral as the ability to discriminate against individual users has simply been transferred from a financial institution to an amorphous group of tokenholders – the latter of which is likely less regulated, more opaque, and less intelligent in its actions than the institution it unwittingly replaced. 

It is under these circumstances that we created the Two Token Governor (TTG). Used in the correct context, we believe it to be a more logical mechanism that preserves the sanctity of the blockchain’s purpose while still providing critical subjective inputs to smart contracts.          

‍Contextualizing the utility of the TTG

While the TTG can be used across a variety of use cases, it is not a general-purpose governance mechanism in the sense that it can make arbitrarily complex decisions. Rather, it is designed to provide simple, relatively unambiguous inputs in a reliable and progressively more decentralized manner. This means that the smart contracts which the TTG are governing need to be specifically configured as to not disrupt its incentives.

The M^0 protocol, for instance, is completely immutable and non-upgradeable. Nothing the TTG can vote on will ever be able to change a single line of code in the core M^0 protocol. The inputs that the TTG can provide are hardcoded as well, significantly limiting the scope of its powers. The M^0 protocol also hardcodes the way in which it distributes funds to various ecosystem actors and intentionally circumvents the TTG in this process. There is nothing the TTG can vote on to divert funds anywhere outside of these hardcoded pathways. These features are very important in order for the TTG to function properly as they were core assumptions in the analysis of user incentives. 

‍Logic and function of the TTG

As its name suggests, the TTG is actually composed of two governance tokens. One, which in the context of the M^0 protocol is called $POWER but can be generalized as a Management Token, is responsible for providing any day-to-day inputs that proposers request. The other, which in the context of the M^0 protocol is called $ZERO but can be generalized as a Guardian Token, is responsible for system oversight. By participating in the governance cycle, the delegates of Management Token holders will receive newly minted Guardian Tokens as rewards pro rata to their voting power. In exchange for their participation in protecting the protocol, the Guardian Token holders are entitled to certain fees generated in the system. This creates a dynamic where the Management Token holders are exclusively incentivized (on-chain at least) by the earning of Guardian Tokens, and all actual value in the system will accrue to the Guardian Token holders, without any intermediate value spillage. 

The TTG operates in a series of hardcoded cycles of a fixed length called epochs. Each epoch is composed of two subtypes of alternating epochs, one is called the Transfer Epoch, the other the Voting Epoch. In the Transfer Epoch, all holders of the Management Token are able to freely transfer and delegate balances. In the Voting Epoch, these balances are frozen and can only be used to vote. This is to ensure correct accounting for further token rewards. In the context of the M^0 protocol, the Transfer Epoch and the Voting Epoch are each 15 days long, but there is nothing special about this number and third party deployers of the TTG can optimize the parameter to their needs.

The TTG has three types of proposals that each serve a different purpose. Anyone with an Ethereum address can make a proposal. The proposals are split by which token is voting on then (Management or Guardian), and then by what type of proposal is being submitted (Standard or Threshold). These different proposal types exist to provide flexibility in governance, and to address the need for a separation between the ordinary course of business and urgent/emergency situations.

The first is called a Standard Proposal. A Standard Proposal is submitted either in the previous Voting Epoch or in the Transfer Epoch preceding a Voting Epoch. Once this next Voting Epoch occurs, the proposal becomes votable and remains votable for the duration of the Voting Epoch. This is done to ensure that all Management Token holders have a minimum and deterministic amount of time to evaluate proposals. The ultimate result of this mechanism is that in each Voting Epoch, Management Token holders have a limited and pre-disclosed list of proposals to vote on. A Standard Proposal requires a simple majority over the course of the Voting Epoch to become executable. If it achieves this it is executable in the Transfer Epoch following the Voting Epoch in which it was active. There is an arbitrary proposal fee, which is set by the Management Token holders, to submit a Standard Proposal.

The second proposal type is called a Management Token Threshold Proposal ($POWER Threshold Proposal in the M^0 protocol). A Management Token Threshold Proposal is proposable at any time and becomes immediately votable to the Management Token holders. Once it reaches a pre-set threshold, which is set by the Management Token holders, it is immediately executable. This proposal type is anticipated to be used for emergency decisions that are time sensitive and have a high level of consensus.

This third proposal type is a Guardian Token Threshold Proposal ($ZERO Threshold Proposal in the M^0 Protocol). This proposal type is functionally identical to the Management Token Threshold Proposal, but as its name implies, is votable by Guardian Token holders rather than Management Token holders. This proposal type is intended to primarily be used for a specific function called a Reset, which is described in further detail below. 

‍The aberration of abstention 

One of the core innovations of the TTG is arguably its punishment mechanism for inactivity. If a Management Token holder does not participate in all votable proposals in any Voting Epoch, they will be progressively diluted as a percentage of total voting power. This is effected by causing a fixed increase in the Management Token supply in each Voting Epoch. Management Token holders that participate in all votable proposals receive their share of the inflation through the process of casting their vote, while those who do not cannot receive anything. At the end of the Voting Epoch, the residual Management Tokens that have not been claimed are auctioned off to the highest bidder via a Dutch auction. The auction process ensures that there is a market mechanism, rather than a political one, to distribute available voting power.

In other DeFi governance systems, abstention has been often treated as a feature; a way for less informed voters to defer their vote to the more (politically) aware and active. We argue that this is an aberration in the intended course of governance and leads almost exclusively to abuse by a minority. The actual impact of such a mechanism is that large token holders – a.k.a. whales – will simply abstain from any vote they consider inconsequential and leave the more involved, more risk-tolerant small holders to do their dirty work. They do this for a number of reasons, including laziness, but a major consideration is the belief that they are passing liability on to the smallholders without any cost.

In many systems, they are completely right in this assessment. History and reason tell us that larger targets are easier targets. By abstaining from the normal course of business, the whales are able to push the complexity of operating the protocol on to the smallholders while they continue to reap the benefits. This is of course a bad incentive – the whales still control the system, they are just pretending not to, and this can cause the governance landscape to morph into a system that defers off-chain to these actors and asks “what will it take to keep you sidelined?” 

The TTG aims at minimizing such misalignment. There is no option to abstain and failing to participate has an explicit cost. While the specific number is up to the deployer, the M^0 protocol dilutes inactive Management Token holders at a rate of 10% per epoch. This means that if a participant is inactive for a year, they will have lost approximately 70% of their voting power in the system. If they are inactive for two years, they have been all but eliminated from the voting pool.  

‍Can’t actors just split their balance across two addresses and vote “yes and no'' on every proposal? Yes, but we don’t think this weakens the impact of the mechanism. These actors are still actively participating, and if they are seeking to avoid controversy or have liability concerns they will need to justify the 50% of their vote that is going in the controversial direction. A system where this strategy is being deployed by large holders is not a system that is nearing capture. In a situation where an actor is truly captured they will not have the option of voting in both directions. If they are being pressured to vote in a way that is at odds with their own interests they will in all likelihood stop voting altogether. There may also be legitimate reasons to act this way. For example, the M^0 Foundation may hold unallocated tokens that it should not use to express an opinion and can do so in this way.

The intention of this mechanism is, obviously, to encourage maximum participation in all votes. We believe that this correctly plays to the incentives of the whales and smallholders alike. In the TTG, if a token holder does not participate, they probably have a good reason and the rest of the system is likely better off without their vote. This assumption is based on the idea that inactivity in the face of explicit financial punishment is more likely than not the result of external pressure to vote in a way that is bad for the system. 

The result of this semi-forced participation dynamic is that over time, the TTG will locally optimize its Management Token holders for participation – it should eventually be getting 100% participation each epoch. The tradeoff is that while the deployer can pick the initial distribution of token holders, the end result can end up being semi-random (although this tradeoff is present in any system with a market for its tokens). This is why the system is implemented in such a way that it severely restricts the scope of governance decisions. The idea is that as long as new Management Token holders need to buy their place at the table via the auction, and there is no on-chain ability to profit from corruption, their interests can be trusted to be at least loosely aligned with that of the protocol. From this point, successful governance is a matter of optimizing the protocol so that even the least informed Management Token holder can make the correct decisions. For the M^0 protocol, this means that Management Token holders are limited to a strict set of simple decisions – tell the protocol which actors it can trust, and set a few very simple and relatively straightforward parameters. We believe that through the combination of these restrictive conditions and the inflation/dilution mechanism, we will achieve improved governance results over current on-chain governance mechanisms.   

It should be noted that Management Token Threshold Proposals and Guardian Token Threshold Proposals do not have dilution, but must meet an arbitrarily high (set by their respective token holders) threshold of yes votes in order to become executable. Proposers of these proposal types should not expect any participation unless there is significant time sensitivity and consensus regarding the desired outcome. These proposals are free to submit as there is no punishment for not participating in the vote. 

‍The rise and fall of the delegate class

Other on-chain governance mechanisms have sought to solve their participation issues through the creation of a delegate class – a group of entities or individuals that accept delegations from other token holders in order to vote on their behalf, or to represent certain political agendas. Many of these even have a way to compensate these delegates directly through the protocol. In our opinion, this is a well-intentioned idea but a poor implementation. Many delegates need to rely on the protocol itself for their payment rather than their delegator. While originally with good intentions, this creates a bureaucratic servant class which is again beholden to the whales, with the cost of these bureaucrats being socialized across all token holders and therefore unfairly extracting value from the self-participating small holders.

The TTG reduces this problem by allowing third party delegation, but giving all Guardian Token rewards to their delegate(s). Management Token holders are free to delegate to any entity or individual that they see fit, but this entity or individual will reap all of the Guardian Token rewards for their participation. The upside to the delegator in this arrangement is that they will not be diluted for inactivity and can re-delegate their tokens at any time to once again begin capturing the Guardian Token rewards.  

‍Keeping management in check with Reset powers

Although the system is designed in such a way that encourages good behavior, all systems with subjective inputs can be corrupted. It is for this reason that the TTG has its second layer of token holders, the Guardian Token holders. The Guardian Token can set a few key parameters, but is mainly there to stand guard against corruption and to be ready to enact a Reset if necessary. A Reset switches the Management Token to a new address that is then distributed pro rata to the current set of Guardian Token holders. In other words, they are reclaiming management rights to themselves and will now have to vote or be subject to dilution.

We believe that the latter responsibility will deter Guardian Tokenholders from calling this function spuriously, as they already reap the majority of the rewards of the system without taking an active role in its management. 

‍A new mechanism for on-chain dapp governance 

Another way to think of the TTG is that it uses a market-incentivized delegation mechanism. Management Token holders purchase their own share of the voting power and are then rewarded with Guardian Tokens, which provide them a permanent share of the residual value of the system they are governing.

Overall, our goal was to build a mechanism that produces better outcomes and best preserves credible neutrality. While we’re excited to see the M^0 protocol use this innovative new mechanism, we hope to see it used broadly across DeFi and crypto. If you are interested in learning more, go ahead and browse M^0’s Documentation Portal.

‍

Gregory Di Prisco, M^0 Foundation Council Member & Lead Architect of the M^0 protocol