III. Governance
The M0 protocol uses an onchain governance mechanism called a Two Token Governor (TTG) to manage its various inputs. With TTG, holders of the voting tokens are penalized for failing to vote.
There are two utility tokens used in the M0 TTG: POWER and ZERO.
POWER is used to vote on active proposals and can be considered the primary management token of the mechanism. POWER holders will earn ZERO in exchange for their direct participation in governance. If a POWER holder delegates their balance to an address that is not also the holder of the tokens, it is this address which receives the ZERO rewards. ZERO holders are comparatively (to POWER holders) passive in the voting process and only vote on important changes. ZERO holders at any time may Reset (see: ZERO Threshold Proposals) the POWER token supply to themselves.
The goal of the TTG mechanism is to ensure credible neutrality of governance. In any system there are two extremes that must be avoided: capture and fraud. In one case, the system is captured by actors whose primary interest is not in efficient protocol operation and it ceases to function in a way where all users are treated the same. In the other, the protocol ceases to function for anyone except the fraudulent actor. It is this dichotomy that is at the heart of the two token design. POWER holders are treated as a managerial class that is able to earn compensation through continued benevolent participation. This continued benevolence is judged by the ZERO holders who can always strip the POWER holders of their management rights, and thus their ability to earn future ownership in the protocol. If the composition and decisions of POWER holders trend towards either extreme, it is in the interest of ZERO holders to call Reset in order to restore balance.
III.I Inputs
List of protocol inputs by the M0 Two Token Governor (TTG).
The M0 TTG (hereafter TTG) is responsible for the following inputs to the M0 protocol and to itself (see (Governance Controlled TTG Parameters)[/home/getting-started/whitepaper/governance/#governance-controlled-ttg-parameters-1], Governance Controlled Protocol Actors, and Section Governance Controlled Protocol Parameters for further context on the actors and parameters listed below):
Governance Controlled TTG Parameters
Governance Controlled Protocol Actors
- A list of approved Minters
- A list of approved validators
- A list of Approved Earners
Governance Controlled Protocol Parameters
- Minter Rate
- Penalty Rate
- Earner Rate
- Mint Ratio
- Mint Delay
- Propose Mint Time To Live
- Update Collateral Interval
- Number of Signatures
- Minter Freeze Time
III.II Operation
Protocol operational attributes.
The TTG is used to vote on proposals seeking to amend the Actors and variables.
New lists and variables may be added arbitrarily over time, however the core protocol is immutable and these additions will not directly impact its operations.
The implementation which controls the M0 protocol is deployed exclusively on the Ethereum Mainnet.
III.II.I Epochs
Protocol epochs for governance and proposal execution.
The mechanism practically operates in 30-day epochs, meaning in the standard operating procedure proposals are only passed on a 30-day cycle. In practice, this broader epoch is split into two epochs of 15 days. These numbers were chosen to align with an average calendar month.
The first epoch (the Transfer Epoch) is a non-voting period where transfers and delegation are enabled. The second 15-day epoch (the Voting Epoch) is where voting takes place on Standard Proposals and transfers and delegation are disabled. These restrictions on onchain activity only apply to POWER tokens, there are no restrictions placed on the ZERO token.
The conceptual 30-day epoch is split into these two smaller epochs to ensure correct accounting for voting and inflation. This means that proposals are collected in one 15-day epoch (whether it be the Voting Epoch or the Transfer Epoch), are voted on in the following 15-day Voting Epoch, and should be executed in the following 15-day Transfer Epoch. Proposals that passed but were not executed eventually expire. Therefore a proposal may spend as short as 15 days plus two blocks, or as long as 45 days, from submission to execution. During the 15-day Transfer Epoch, holders may transfer their balances, reassign delegations, and purchase POWER that is being auctioned.
III.II.II Proposals
Protocol change proposals for TTG governance.
The TTG has three types of proposals: (1) Standard Proposals, (2) POWER Threshold Proposals, and (3) ZERO Threshold Proposals.
The use of threshold in the terminology represents a yes threshold, meaning that the threshold percentage of yes votes must be reached in order for the proposal to pass. A proposal that requires a threshold never explicitly fails (although it will eventually expire), but cannot be executed without reaching the requisite number of yes votes.
For example, if a proposal requires a 10% yes threshold, it will pass as soon as 10% of the relevant token supply has voted yes. If this proposal never reaches 10% of the relevant token supply voting yes, it will expire without passing.
These proposal types are described next in further detail.
III.II.II.I Standard Proposals
Standard Proposals in TTG Governance.
Standard Proposals are voteable only by POWER holders and require a simple majority of participating tokens to pass. Standard proposals do not require a threshold percentage of yes votes to pass. If there are only 100 POWER tokens voting in a Standard Proposal and 51 vote yes while 49 vote no, it will pass. If 50 vote yes and 50 vote no, it will fail as it requires the yes balance to exceed the no.
Standard Proposals are the only proposal type which are “mandatory” for POWER holder participation. Lack of participation will result in POWER holders being diluted in terms of their overall voting POWER in the system and will cause them to forfeit any ZERO rewards for which they were otherwise eligible. A successful Standard Proposal will have its Proposal Fee available to be returned to the proposer.
III.II.II.II POWER Threshold Proposals
A POWER Threshold Proposal requires a set vote threshold for immediate execution, used for urgent or important changes in M0 Governance.
A POWER Threshold Proposal can be used to submit anything which would otherwise be a Standard Proposal, except it requires a POWER Threshold and is immediately votable and subsequently immediately executable rather than only being votable and executable in the future epochs.
For this reason, POWER holders are likely to use this proposal type in the case of an urgent or emergency situation. If a POWER Threshold has not been reached before the proposal expires, the proposal cannot be executed. POWER Threshold Proposals expire at the end of the next epoch.
III.II.II.III ZERO Threshold Proposals
ZERO Threshold Proposals allow major governance changes.
A ZERO Threshold Proposal is used for Reset, to toggle CASH between WETH and $M, and to set the POWER and ZERO Thresholds themselves. The Reset method is a special feature reserved for the ZERO token holders which allows a yes threshold of ZERO holders to change the current governor of the system to a new version with a new POWER token that is claimable pro rata to ZERO holders or to existing POWER holders.
They do this by creating a proposal to call the Reset method. Mechanically this is affected by replacing the current governor (POWER token address) of the system with a new instance, where the starting balance of the POWER tokens are proportional to each ZERO holder's balance in the epoch before the Reset. It is immediately executable upon achieving a yes threshold.
It is intended for ZERO holders to use this feature should they find something irreparably wrong with the composition and/or voting patterns of the current POWER holders and wish to take on voting responsibility themselves. It is anticipated that ZERO holders will only Reset the governor to the existing POWER holders if the token is nearing an overflow, which will not happen for 150+ years. There is technically no limit to how many times Reset can be called, but it is not anticipated to be frequently used if it is ever used in the first place. If a Reset is executed in the middle of a Voting Epoch, all active and/or unexecuted proposals are effectively canceled because they are using the obsolete governor.
III.II.II.IV Proposal Matrix
The Proposal Matrix provides a visual breakdown of the three TTG proposal types.
The diagram below details the three types of proposals in the TTG and highlights which actions are associated with each type.
III.II.III Checkpoints and Voting
A checkpoint of balances is taken at the start of epochs and the balances contained in these checkpoints are used for voting throughout the epoch.
During a Transfer Epoch, only the balance a user possessed at the checkpoint will be counted towards voting on POWER Threshold Proposals, which will not include standard inflationary proposals by definition. In order to vote the POWER owner’s delegate address (hereon referred to as the POWER holder) calls the Cast Votes method on the array of proposals they wish to vote on and specifies yes/no for each proposal.
There is no abstain option in the TTG.
III.II.IV Proposing
Making protocol change proposals for TTG.
Anyone with an Ethereum address and WETH or $M may submit a proposal. The TTG is to be deployed with WETH as its internal currency (known as CASH in the mechanism), and therefore any Standard Proposal submission must pay a Proposal Fee in WETH, or at a later date M depending on the current CASH toggle setting, in addition to gas fees (see Governance Controlled TTG Parameters). A proposal that passes makes the Proposal Fee available to be returned to the proposer upon execution.
There are two primary structures of proposals that can be managed through the TTG: (1) configuring a registrar used by the protocol, i.e. adding and removing addresses from arbitrary lists/sets and setting arbitrary variables; (2) setting governance parameters. The M0 protocol looks to the registrar to use certain variables and sets of addresses in its processes.
In order to propose a change to a list, a user submits a Standard Proposal or a POWER Threshold Proposal calling the Add To List or Remove From List methods along with the address they wish to add or remove. There is also a method called Remove From And Add To List which facilitates swapping an address on a list. In order to add a new list to the TTG a proposer will create a proposal which uses Add To List and will specify a new list, which is created simultaneously to the proposal being executed. Since the M0 core protocol is immutable, any list added after deployment can only be used to manage periphery smart contracts and cannot impact core operations.
In order to propose a change to a configuration contract proposers call the Set Key method. In order to propose a configuration change at the registrar, proposers create a proposal for the governor to call the registrar's Set Key method. The update either results in the first setting or overwriting of a value for a given key (i.e. variable name).
Once a proposal passes, and assuming the requisite amount of time has passed, anyone can call the Execute method to execute the action on chain. They must pass the proposal arguments into the Execute method.
III.II.V Inflation Mechanics
Description of protocol inflation mechanics for TTG.
In each epoch the supply of POWER is inflated by 10% and the supply of ZERO is inflated by up to 5,000,000 tokens. This inflation is claimed pro rata by participating POWER holders, specifically by their delegate address. Any POWER that remains undistributed (or that could not be claimed because the holder did not fully participate in that epoch) is auctioned off to the highest bidder in a pay-as-bid Dutch auction (hereon “Dutch auction”).
When there are tokens to auction, the auction starts at the beginning of the Transfer Epoch and ends at the finish of the Transfer Epoch. Therefore if a user purchases POWER during an auction they will always be able to use those tokens to vote in the subsequent Voting Epoch. Each participating POWER holder during the Voting Epoch will also receive their pro rata (based on their percentage of total voting power) share of the 5,000,000 ZERO tokens.
Once a Standard Proposal has been submitted it can be voted on in the following Voting Epoch, unless it is a POWER Threshold Proposal or a ZERO Threshold Proposal, which can be voted on at any time. When a proposal becomes available for voting, it is mandatory for POWER holders to vote on it or else the owner of the POWER tokens will lose relative voting weight in the system. If a POWER owner’s delegate fails to vote on any proposal in an epoch, they will forfeit any POWER or ZERO inflation they would have otherwise been able to claim. POWER holders must vote on all Standard Proposals in the Voting Epoch; POWER Threshold Proposals and ZERO Threshold Proposals do not factor into POWER inflation dynamics. There is no inflation if an epoch only has POWER Threshold Proposals and / or ZERO Threshold Proposals, or no proposals at all.
III.II.VI Dutch Auction
Dutch Auction for POWER tokens.
Once the Transfer Epoch has begun the Dutch auction will begin simultaneously if any POWER holder failed to participate. The price per basis point (0.01%) of POWER token, calculated as a percentage of the total POWER supply, in the Dutch auction will start at
2^99 wei (the smallest unit of WETH) and decrement the exponent approximately every 3.6 hours. During the period between exponent decreases the price linearly declines. This means that after the first 3.6 hours of the auction the price will be
2^98
wei and linearly decrease to
2^97
wei over the following 3.6 hours.
In the implementation, bitwise shifting is used to achieve this effect. That is to say that at the midpoint between two exponents, the value is halfway between them. In order to purchase POWER in the Dutch auction, purchasers must call the Buy method.
The diagrams below illustrate the intended price curve of the Dutch auction in ETH over the 15 day period. The first demonstrates the entire price curve, while the second shows a smaller slice of the curve to demonstrate its semi-linearity.
III.II.VII Delegation
Delegation of voting POWER for TTG.
Both POWER and ZERO owners may delegate their voting POWER to an arbitrary Ethereum address during the Transfer Epoch. Delegated POWER will retain its inflation in the owner address, while ZERO rewards will be claimable by the delegate address.
Owning ZERO does not earn the owner or the owner’s delegate inflation or rewards aside from $M generated by the protocol fees, and thus delegation does not have any impact on the owner outside of transferring voting power. ZERO does earn fees from Proposal Fees on failed Standard Proposals, the payments from POWER token auctions and a portion of Minter Rate and Penalty Rate charges to Minters.
Delegation snapshots are taken at the beginning of the epoch and close at the end of the epoch, and the values in the snapshots are subject to change until the epoch closes. Both POWER and ZERO follow the ERC20 standard and holders must call the Delegate method and provide the address they wish to delegate to. For holders that do not actively Delegate, the default delegation is set to the address which owns the tokens. Users do not need to alter their delegation in each epoch unless they wish to change delegates.
III.II.VIII ZERO Claiming of Residual Value
In exchange for ZERO holders' participation in protocol governance, they will receive the remainder of the protocol fees. The anticipated accumulation of tokens to the ZERO holders are Proposal Fee payments from rejected proposal submission, the payments from POWER token auctions, and a portion of Minter Rate and Penalty Rate charges to Minters (see Protocol Fees).
Proposal Fee and auction payments are collected in WETH or $M, depending on the status of the CASH toggle, and Minter Rate is collected in $M.
At any time a ZERO holder may call the Claim method in order to claim this accumulated value. The amount of claimable tokens are pro rata to each account's ZERO balance on the close of each epoch they are trying to claim for. They pass the array of epochs (or a starting epoch and ending epoch) they are seeking to claim for as arguments to the method.
III.III Governance Controlled TTG Parameters
List of Governance controlled TTG parameters.
CASH
The internal currency of the TTG. It is used to pay Proposal Fee and to purchase POWER in the Dutch auction. It can be toggled between WETH and $M.
Logic: This token must be permissionless and well distributed in order to prevent takeover of the TTG. It should also have sufficient value to its holders in order to deter spam and to increase the efficiency of the Dutch auction.
Proposal Fee
The amount paid in CASH to submit any proposal. It is alterable with a Standard Proposal.
Logic: This amount should be sufficiently high to deter spam, but not so high as to deter legitimate proposals.
POWER Threshold
The number of yes votes as a percentage of the total POWER supply required to pass proposals which require a POWER Threshold.
Logic: This percentage should be low enough to ensure that in an emergency situation, enough POWER holders can be collected to pass a proposal. It should be high enough that a malicious proposal cannot be passed instantly.
ZERO Threshold
The number of yes votes as a percentage of the total ZERO supply required to pass proposals which require a ZERO Threshold.
Logic: This percentage should be low enough that it is possible to call Reset if necessary. It should be high enough to ensure that Reset is not called without a very high level of consensus.
III.IV Immutable TTG Parameters
List of immutable TTG parameters.
Epoch Duration
The combined length of the Voting Epoch and the Transfer Epoch. Set to 30 days.
Logic: This amount of time should be short enough to permit for timely management of the protocol, but long enough for all POWER holders to both socialize and physically vote on Standard Proposals.
Voting Epoch Duration
The length of the Voting Epoch. Set to 15 days.
Logic: This amount of time should be long enough to permit POWER holders to physically exercise their vote.
Transfer Epoch Duration
The length of the Transfer Epoch. Set to 15 days.
Logic: This amount of time should be long enough to contain the Dutch auction and for any POWER holders that may wish to perform transfers or re-delegations to do so.
Auction Duration
The length of the Dutch auction for unclaimed POWER inflation. Set to 15 days and overlaps perfectly with the Transfer Epoch.
Logic: This amount of time should be long enough to cross all conceivable prices while still promoting efficient price discovery. Note that this length matches the Transfer Epoch, so that tokens acquired in the Transfer Epoch will be included in the checkpoint for the following Voting Epoch.
Dutch Auction Exponent
The exponent with a base of 2 that determines the starting auction price. Set to 99.
Logic: This number should produce a sufficiently high starting price per POWER token such that the market price of POWER in Cash is never above this price. It should not be so high as to cause the auction to exceed the Transfer Epoch before reaching 0 given the Dutch Auction Period Time setting.
Dutch Auction Periods
The number of equal periods that must fit into the Transfer Epoch. Set to 100.
Logic: This number of periods defines how often the Dutch auction will decrease the Dutch Auction Exponent. At the current setting the Dutch auction will decrement the Dutch Auction Exponent approximately every 3.6 hours.
III.V Immutable POWER Parameters
List of immutable POWER parameters.
POWER Initial Supply
The initial supply of POWER tokens before any inflation. Set to 1,000,000. Decimals are 0.
Logic: The initial supply of POWER should be sufficient to distribute to the initial holders in the network, but not so high as to cause a premature overflow error. The lack of decimals (and thus lack of subdivision of tokens) was also chosen for this reason. See the diagram under POWER Inflator for further analysis. Another factor to consider in this initial supply is the “dust level,” meaning the level at which in a Reset a ZERO holder would not receive any POWER tokens. For example, since new POWER (post-Reset) is based on existing ZERO balances, anyone who owns less than 1 / POWER Initial Supply of a ZERO token will get 0 POWER after a Reset.
POWER Inflator
The percentage inflation of the POWER supply per active epoch. This occurs only in epochs with a votable proposal, hence why they are referred to as active. If a POWER holder fails to fully participate in an epoch with at least one votable, their balance of POWER tokens will not decrease but their percentage of overall voting POWER will decrease by 1 / (1 + POWER Inflator). Set to 10%.
Logic: This percentage must sufficiently encourage POWER holder participation without occasional lapses in participation destabilizing the system. At 10% inflation, a POWER holder can expect to lose ~45% of their voting POWER if not participating for 6 epochs (note that epochs in our implementation correspond roughly to calendar months), ~70% of their voting POWER if not participating for 12 epochs, and ~90% of their voting POWER if not participating for 24 epochs. To a lesser extent this number should also take into account a realistic number of epochs with votable proposals to ensure that the operation of the protocol is not impacted by an overflow error. This would require either a Reset or a Hard Fork. The following diagrams demonstrate the intended impact of the POWER Inflator on an inactive participant, and a comparison of POWER Inflator and decimal setting as they impact overflow times assuming a 30-day total epoch time.
Voting POWER as a percentage of starting voting POWER (y-axis) over missed epochs with a votable proposal (x-axis), using a 10% POWER Inflator
Years to overflow assuming 12 epochs per year with votable proposals. Comparison of POWER Inflator (left column) and decimal choice for POWER token (top row). Assumes a starting POWER supply of 1,000,000.
III.VI Immutable ZERO Parameters
List of immutable ZERO parameters.
ZERO Initial Supply
The initial supply of the ZERO token before any rewards. Set to 1,000,000,000. Decimals are 6.
Logic: The initial supply of ZERO should be large enough to promote a high level of decentralization (as it pertains to the Reset method), and small enough to not break common integrations.
ZERO Reward
The maximum amount of ZERO given to POWER holders in a Voting Epoch. Each POWER holder is given their pro rata share of the reward if they fully participate and the tokens are claimed simultaneously to voting. Tokens which go unclaimed are never minted. No tokens are distributed in an epoch with no active proposals. Set to 5,000,000.
Logic: The reward amount should provide enough incentive to Standard Proposal voters to consistently vote while not destabilizing the protocol through unpredictable distribution. An additional consideration is the maximum level of decentralization that can be achieved given average gas fees – i.e. the reward must at least cover the average gas fee of participants and thus the average gas fee puts a practical boundary on the percentage of POWER one must own to justify participation.
See the diagrams below for further illustration of the potential impact of the reward on the ZERO supply over time.
