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/fundamentals/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.
