II. Protocol

The M0 protocol is a set of immutable smart contracts implemented for the Ethereum Virtual Machine.

The M0 protocol receives all external inputs from a governance mechanism called the M0 Two Token Governor, TTG, (see Governance). The M0 protocol is a coordination tool for actors permissioned by governance, namely Minters, validators, and Earners.

II.I Operation

The M0 Protocol is permissioned through the Two Token Governor (TTG) mechanism.

The primary actors in the protocol are called Minters and validators (see Governance Controlled Protocol Actors).

Once permissioned by the TTG, Minters and validators are able to access certain methods in the smart contracts which facilitate the creation, maintenance, and destruction of $M. $M is a standard ERC20 token. The core operating condition of the M0 protocol is to ensure that all M in existence is backed by an equal or greater amount of Eligible Collateral value that is held in an Eligible Custody Solution (see offchain Actors and Components).

II.I.I Generation of M

In order to generate $M, Minters must have a sufficient offchain balance of Eligible Collateral which is represented onchain by a frequently updated and validated number, known as the onchain Collateral Value.

Minters call the Update Collateral method to put this number onchain. They must pass the amount, the list of signing validators, a list of timestamps associated with the Validator signatures, and valid signature data (from validators). Whenever timestamps and signature data is passed to a method, the contracts will take the minimum timestamp and the minimum threshold of signatures as defined by the TTG (see Governance Controlled TTG Parameters). Optionally, they can pass a hash of arbitrary metadata and any open Retrieval IDs (see Retrieving Free Collateral) into the method as an argument. The Metadata Hash can be used to retrieve the actual offchain metadata, which can serve to add context to the update, while Retrieval IDs allow Minters to remove outstanding balance subtractions (see Retrieving Free Collateral). Signature validation may either use standard ecrecover, which allows for the Minter to obtain the signature offchain, or EIP-1271 onchain contract signatures. The collateral balance is an attestation to the value of the Eligible Collateral held in an Eligible Custody Solution (see offchain Actors and Components for further details).

In order to post the value of their Eligible Collateral onchain, the Minters will need to provide the signature data (from validators) in the transaction. The presence of the Validator’s signature is to reinforce that the value of the Eligible Collateral is correct and reflects the most up-to-date snapshot of the offchain balances. Minters must update their Eligible Collateral number onchain and with a valid Validator signature at least once every Update Collateral Interval (see Governance Controlled Protocol Parameters). If a Minter fails to call Update Collateral within Update Collateral Interval of the previous time they called it, their onchain Collateral Value is assumed to be 0. If the Minter cannot provide valid signature data (from validators), they cannot successfully call the method. Each time this method is called it will accrue the Minter Rate (see Protocol Fees) on the Minter’s current balance of Owed $M. If any rules are being violated at the time of the method being called, it will also charge Penalty Rate on the Minter’s balance which is in violation (see Protocol Fees).

Once a Minter has updated their onchain collateral they are able to generate $M. They do so by calling the Propose Mint method and passing in the amount of $M they’d like to generate and the address which they would like to generate the $M to. Once this method is called, it will first call Get Present Amount on the Minter's current balance of Owed M. It will then check to ensure that the onchain Collateral Value multiplied by the Mint Ratio (see Governance Controlled Protocol Parameters) is greater than the amount of total Owed $M from the Minter, including the amount they are currently attempting to generate and/or Retrieve (see Retrieving Free Collateral). If these checks are passed the method will output a Mint ID which corresponds to the Propose Mint. A Minter can only have one outstanding Mint ID at any given time.

If after the Mint Delay (see Governance Controlled Protocol Parameters) the Mint ID has not been canceled by the Validator (see Cancel and Freeze), the Minter may call the Mint method and pass the Mint ID as an argument to execute the Propose Mint. The Mint Delay was introduced to avoid atomic Update Collateral calls and Mint calls, and to provide the network of validators with sufficient opportunity to intervene in the minting process if something is seemingly wrong (see Cancel and Freeze). The Minter must call Mint before the Propose Mint Time To Live has expired (see Governance Controlled Protocol Parameters).

Minters can destroy Owed $M at any time by calling the Burn method and passing in their Minter Address and the amount of $M they’d like to burn as arguments. Any address can repay $M owed by a Minter by calling the Burn method and passing in the amount and Minter address as arguments.

II.I.II Protocol Fees

There are two fees assessed on Minters in the M0 protocol.

The first is called Minter Rate, a governance controlled parameter, which is levied continuously on the Minter’s balance of Owed $M. This fee compounds on a continuous basis. The beneficiaries of Minter Rate are the Earn Mechanism (see The Earn Mechanism) and the ZERO holders (see Governance).

The second is Penalty Rate, another governance controlled parameter, which is levied on balances that are in violation of protocol rules and has the same beneficiaries as the Minter Rate.

Penalty Rate is imposed upon any balance in excess of this amount. If a Minter has not called Update Collateral within Update Collateral Interval, they will incur Penalty Rate on their entire balance of Owed $M for each Update Collateral Interval that they miss – i.e. when Update Collateral is not called in the TTG-specified time the system interprets its value to be ZERO. Unlike Minter Rate, Penalty Rate is not continuously levied on the Minter’s balance of Owed M, but is charged discretely as a one-time percentage fee on their delinquent balance at the moment the balance is checked, and then added to the Minter’s Owed M. Collecting Minter Rate is contained in the Get Present Amount method, which is exclusively embedded in all other Minter methods, including Burn, and cannot be called independently. The Minter Rate is mechanically affected by updating a global index value which is applied to all Owed $M in the Minter’s balance, as is Penalty Rate. Penalty Rate is contained in the Impose Penalty method, which is exclusively embedded in the Update Collateral, Burn and Deactivate Minter methods. When Impose Penalty is called in conjunction with Update Collateral, it checks for both missed Update Collateral Interval periods and the Minter’s balance of Owed $M relative to their onchain Collateral Value discounted by the Mint Ratio. When it is called in conjunction with Burn, it only checks for missed Update Collateral Interval periods. This is done to ensure that the Minter is not penalized on the same errant balance more than once. Impose Penalty will also account for whether it has already been called in the current Update Collateral Interval period and will not charge a Minter twice for the same missed period.

Example A Minter calls Update Collateral; the Get Present Amount method is called along with the Impose Penalty method. The Minter’s balance of Owed $M prior to the method call is 8,000,000 M. First, Get Present Amount is used to fetch the latest index and apply the Minter Rate to the Minter’s balance of Owed M, accounting for continuous compounding. Assume that this increases the Minter’s Owed $M to 8,000,010 M. If the Minter’s onchain Collateral Value is 8,000,000 and the Mint Ratio is 90%, then the maximum amount of Owed $M Minter 1 should have is 7,200,000 M– but the actual onchain number is 8,000,010 M. Therefore Minter 1 will incur Penalty Rate on (8,000,010 M - 7,200,000 M) = 800,010 M. If Penalty Rate is 0.01%, then the Minter’s Owed $M is incremented to 8,000,010 M + 800,010 M* 1.0001 = 8,800,100.001 M.

The following is a diagram which demonstrates a hypothetical sequence where a Minter incurs Penalty Rate charges. The example below describes this hypothetical sequence.

Example (some balances are rounded) Assume that the Mint to Collateral Ratio is 90%, Update Collateral Interval is 24 hours, Minter Rate is 5% APY (and therefore ~0.00058% per hour), and Penalty Minter Rate is 0.02%.

On Day 1, a Minter calls Update Collateral and passes in 100 as the value. Its Owed $M is 0. Later that day (Day 1.1) the Minter generates 90 M.
On Day 2 the Minter fails to call Update Collateral.
On Day 3 the Minter calls Burn and passes in 50.043 M. Assume that less than 48 hours have passed since the Mint call on Day 1. First, Get Present Amount is called and applies the latest index to the Minter’s balance of 90 M. This increases the Minter’s Owed $M to (90 _ (1 + (0.0000058 _ 48))) = 90.025 M. Next, Impose Penalty is called and is applied to the Minter’s updated balance. Since the Minter missed one Update Collateral Interval period (on Day 2), they are penalized one time. The Minter’s Owed $M is increased to (90.025 _ (1 + (0.0002 _ 1)) = 90.043 M. The amount passed into the Burn method (50.043) is now subtracted from this new balance and reduces the Minter’s Owed $M to (90.043 - 50.043) = 40 M. Recall that burn only checks for missed Update Collateral Interval periods and does not check the Minter’s current onchain Collateral Value and therefore does not penalize any currently errant balance. The Minter then calls Burn again on Day 3 and passes in 30.0014 M. Assume 6 hours have passed since the previous Burn call. First, Get Present Amount is called and applies the latest index to the Minter’s balance of 40 M. This increases the Minter’s Owed $M to (40 _ (1 + (0.0000058 _ 6))) = 40.0014 M. Impose Penalty is then run but does not charge the Minter an additional Penalty Rate because it has already paid for all missed Update Collateral Interval periods. The amount passed into the Burn method (30.0014) is now subtracted from this new balance and reduces the Minter’s Owed $M to (40.0014 - 30.0014) = 10 M. Finally, also on Day 3, the Minter calls Update Collateral and passes in 0 (most likely because their Eligible Collateral has matured and is sitting in ineligible bank deposits). Assume another 6 hours have passed. Once again, Get Present Amount is run to apply the latest index to the Minter’s balance of M. This increases the Minter’s Owed $M by (10 _ (1 + (0.0000058 _ 6))) = 10.00035 M. Next Impose Penalty is called. There are no charges for missed periods because these were already paid when the Minter called Burn. A check for an errant balance is now run and produces 10.00035 M since the Minter’s entire balance is in excess of their maximum permitted Owed $M due to the onchain Collateral Value being 0. The Minter’s Owed $M is increased to (10.00035 * 1.0002) = 10.00235 M.

II.I.III Cancel and Freeze

An overview of the two methods which can be used to stop an errant generation of $M or to stop an errant Minter in the case of an emergency.

The first method, Cancel, can be called by any Validator on any Mint ID associated with the generation of $M. The calling actor must pass the Mint ID as an argument to the method. Calling this method will cancel the specified Mint ID and cancel the proposal. The Cancel method can be called at any time until Mint is called. Minters do not have access to the Cancel method because submitting a new Propose Mint will automatically cancel and replace any that are currently outstanding. The second method, Freeze, can be called by any Validator on any Minter by passing the Minter address as the argument of the method. Calling Freeze will disable Propose Mint and Mint for Minter Freeze Time (see Governance Controlled Protocol Parameters). It can be called multiple times on the same Minter to reset the Minter Freeze Time window. If Freeze is called during an already existing Minter Freeze Time, the Minter Freeze Time window will restart from the beginning.

These methods can be thought of as being a part of a series of escalations the system (first through validators and then through the TTG) can levy against an errant Minter. The final escalation being removal of the Minter. Removal of a Minter would similarly be done via a TTG proposal.

II.I.IV Retrieving Free Collateral

This is an extensive description of the process of retrieving collateral.

Any Minter with an excess of offchain value (both Eligible Collateral and other forms of value that may reside in the Eligible Custody Solution) relative to their Owed $M, can remove this value from the Eligible Custody Solution. They can do so by calling the Propose Retrieval method and passing the amount they wish to retrieve from custody.

Like most methods this will first call Get Present Amount. After that it will check that the onchain Collateral Value, after subtracting the amount the Minter is trying to retrieve and any other open Retrieval IDs, is sufficient to support the Minter’s remaining balance of Owed $M. Unlike Propose Mint, which is limited to one Mint ID at a time, there is not a limit to the number of outstanding Retrieval IDs. If this check passes, it will sideline this balance to be deducted from future calculations where it is relevant. Finally it outputs a Retrieval ID. The subtraction from the onchain Collateral Value, when relevant, will remain until the Retrieval ID is closed.

In order to close the Retrieval ID and eliminate the subtraction on the Minter’s onchain Collateral Value, the Minter must pass the Retrieval ID into an Update Collateral. In signing off on this transaction, the Validator is attesting that the Retrieval ID has been fully processed offchain, or will not be processed at all, and that the new onchain Collateral Value is correct.

II.I.V The Earn Mechanism

This is an extensive description of the Earn mechanism within the M0 protocol.

The Earn Mechanism is a mechanism in the protocol which allows Approved Earners (see Governance Controlled Protocol Actors) to earn the Earner Rate (see Governance Controlled Protocol Parameters).

The Earner Rate, while input as an explicit value from the TTG, is bound in the smart contracts to be the lower of its input value or the maximum it can be without expending more $M than is accruing from Minter Rate. To elaborate, the utilization of the Earn Mechanism can be considered to be the total amount of Owed $M that is currently paying the Minter Rate (hereon referred to as active M) divided by the total amount of $M in the Earn Mechanism. If a Minter is depermissioned by the TTG, their M will be deducted from the active $M and thus lower utilization. The Earner Rate is then the minimum of the value input by the TTG, or the Minter Rate multiplied by utilization, which represents the lowest rate that would be safe to offer before more $M is being paid to Earners than is being collected from Minters.

Once approved by the TTG, an Approved Earner can call the Start Earning method. This will check if the address is on the Approved Earners list and if so the address will begin to earn the Earner Rate on a continuously compounding basis. If an address is removed from the Earner’s list, Stop Earning can be called with the address in question passed as an argument to the method, which will cease the accrual of the Earner Rate on the address’ balance.

II.I.VI Removing a Permissioned Actor

Overview of the process for removing permissioned actors in the M0 Protocol.

Permissioned actors can be removed from the system by passing a proposal in the TTG mechanism removing them from a specific list (e.g. the Minter list). Once an actor is removed they are no longer able to call the methods in the contracts, preventing them from engaging in further activity with the protocol.

Once a Minter is removed from the Minter list, they cease to pay the Minter Rate on their Owed $M. The value of current Owed $M, and potentially penalties for missed intervals, is stored for repayment by the Minter or anyone interested in their offchain collateral retrieval. This is to ensure that $M does not get paid to the Earn Mechanism and to the ZERO holders if a Minter is no longer actively in the system.

The Burn method always remains available to anyone even if a Minter is no longer permissioned. This ensures that offchain actors can facilitate the wind-down of the Minter’s operations and destroy the Owed $M in order to retrieve the value from the Eligible Custody Solution.

Once a Minter is removed from the Minter list, any actor in the system can call the Deactivate Minter method to cease the accrual of Minter Rate and the imposition of further Penalty Rate charges.

II.I.VII Example Interactions and Flows

The following is an example of how Permissioned Actors are intended to interact with the protocol, and how $M is intended to flow through the protocol.

Step 1: Minters, validators, and Earners propose their addresses to the M0 TTG.
Step 2: The TTG accepts or rejects the proposals.
Step 3: Minters that were approved by the TTG are now on the Minter List. These Minters call for their first onchain Collateral Value update.
Step 4: This Minter has contracted with at least one Validator offchain. The Validator(s) have full access to the records and statements of the Eligible Custody Solution. The Validator(s) will check to ensure that the proposed onchain Collateral Value is less than the dollar value of the Eligible Collateral in the Eligible Custody Solution. Once they have confirmed this to be true, they will provide the Minter with their signature and a timestamp from when they performed the balance check.
Step 5: Once the Minter has obtained a valid signature and timestamp from the Validator(s) they will call Update Collateral to push the balance onchain.
Step 6: Now that the Minter has a positive onchain Collateral Value, they are able to generate M. They will call the Propose Mint method and specify the amount they wish to generate. As long as this amount is within the bounds of the current onchain Collateral Value (excluding any open Retrieval IDs) multiplied by the Mint Ratio, the method will output a Mint ID. This Mint ID will be inactionable for some Mint Delay, and then actionable for Propose Mint Time To Live.
Step 7: The Mint ID must be outstanding for Mint Delay. This is to ensure the superset of validators have the opportunity to scrutinize the Propose Mint and call the Cancel and/or Freeze methods if something is amiss. Once Mint Delay has passed, the Minter can call Mint and generate the M.
Step 8: Now that the $M is generated, the Minter begins to pay Minter Rate on their Owed $M. They will be subject to Penalty Rate charges on this balance if they do not keep their onchain Collateral Value up to date or allow their onchain Collateral Value to decrease below the permitted level. If the latter circumstance occurs, it is likely because the assets comprising the offchain collateral have matured and are sitting in bank deposits.
Step 9: Assume that this Minter now wishes to repay some of the $M they have generated and to retrieve a portion of the collateral from the Eligible Custody Solution. The Minter will first call Burn and specify the amount of $M they’d like to repay. This will reduce their Owed $M by this amount. Assuming that now there is a positive spread between the permitted amount of $M that the Minter can generate and their Owed M, they can call the Retrieve method. The Retrieve method will first check if their onchain Collateral Value, after the retrieval, is in compliance with the protocol’s rules. If it is, the method will output a Retrieval ID and reduce the Minter’s onchain Collateral Value by the amount specified.
Step 10: The Minter can now go to the operator of the Eligible Custody Solution and show them the Retrieval ID and request that they allow them to redeem the corresponding value.
Step 11: Once the transaction has completed and cleared the Minter will call Update Collateral and input the new Collateral Value and the Retrieval ID in order to remove the subtraction to onchain Collateral Value associated with the Retrieval ID. The Minter once again requires the Validator signature data and timestamp for the transaction to succeed.

II.II Governance Controlled Protocol Actors

List of Governance controlled protocol actors.

Minters

A list of addresses (the Minter list, where the addresses are known as Minter address) maintained by the TTG mechanism which are able to access the minting functionality. The minting functionality allows for addresses on the Minter list to update onchain Collateral Value associated with their Minter address, Propose Mint, Mint, Burn, and to Retrieve offchain collateral.

Validators

A list of addresses (the Validator list, where the addresses are known as Validator address) maintained by the TTG mechanism which act as a security layer for protocol. validators are required to provide signatures for the Update Collateral method. They also have the ability to call the Cancel method on any Mint ID, and the Freeze method on any Minter address.

Earners

A list of addresses (the Earner list, where the addresses are known as Earner address) maintained by the TTG mechanism. These addresses are able to control whether they earn the Earner Rate.

II.III Governance Controlled Protocol Parameters

Minter Rate

The annualized percentage charged continuously to Minters on their Owed $M. It is alterable with a Standard Proposal.

Logic: This annualized percentage should (generally) be less than the average rate on the Eligible Collateral being earned by Minters. This spread, adjusted for the Mint Ratio, is the profit margin of the Minter.

Penalty Rate

The percentage charged on Owed $M that is in excess of the amount a Minter is permitted to have generated. It is assessed any time Impose Penalty is called, which is embedded in both Update Collateral and Burn. It is alterable with a Standard Proposal. This is a fixed percentage and not an annualized rate. Logic: This percentage should be sufficiently high to deter Minter offenses, but not so high as to overly punish Minters that are victims of circumstance.

Earner Rate

The annualized percentage paid to $M in the Earn Mechanism. If the cumulative $M paid out via the Earn Mechanism is going to be greater than the amount of $M being generated by the Minter Rate, the Earner Rate is automatically discounted to whichever percentage will reduce this mismatch to 0. ZERO holders receive all remaining $M that is not paid out to the Earn Mechanism for their participation in protocol governance. It is alterable with a Standard Proposal. Logic: This annualized percentage should be consistent with the yield demanded by institutional holders of $M. It is mechanically prevented from exceeding the cumulative level of $M generated by the Minter Rate. It should not be set so low that it results in insufficient demand for $M and thus an inefficient market for Minters.

Mint Ratio

This percentage is the fraction of a Minter’s onchain Collateral Value that they can generate in $M. It effectively controls the leverage of a Minter and the over-collateralization of $M. It is alterable with a Standard Proposal. Logic: This percentage controls the leverage of Minters and the over-collateralization of $M. It should be set high enough to encourage attractive Minter economics, but not so high that it compromises the stability of $M.

Mint Delay

This amount of time is the period between when a Minter has called Propose Mint and when they can first call Mint. It serves as a protective measure to ensure all actors have sufficient time to audit each Mint. It is alterable with a Standard Proposal. Logic: This amount of time should be long enough to ensure proper auditability and to afford validators a chance to call Cancel or Freeze if necessary. It should not be so long that it introduces unnecessary friction into the Minting process and reduces the efficiency of Minters and the stability of $M.

Propose Mint Time To Live

This is the amount of time after the Mint Delay that a Proposed Mint has to be called before it expires. It serves as a protective measure to ensure that Minters cannot call Propose Mint and then execute the Mint at a much later date. It is alterable with a Standard Proposal. Logic: This amount of time should be long enough to give Minters a chance to react to the Mint Delay lapsing and execute their Mint, without being so long that it compromises the integrity of the previous Validator checks.

Update Collateral Interval

This amount of time is the period between which Update Collateral must be called by a Minter. If they do not call Update Collateral within this amount of time after their previous call, their onchain Collateral Value is assumed to be 0 and they will incur Penalty Rate on the next update. It is alterable with a Standard Proposal. Logic: This amount of time should be long enough to ensure that validators can reliably check the status of the offchain structures and balances, but not so long that it compromises the integrity of those checks.

Update Collateral Threshold

This number of signatures is the minimum number of Validator signatures required to execute Update Collateral. If a Minter cannot provide this number of signatures, they cannot successfully call Update Collateral. It is alterable with a Standard Proposal. Logic: This number of signatures should ensure that the Update Collateral process is as secure as possible given the number of validators in the network. It should not be set so high that Minters cannot reliably call Update Collateral.

Minter Freeze Time

This amount of time is the duration for which a Minter will not be able to call Propose Mint or Mint after having the Freeze method called by a Validator on their address. It is alterable with a Standard Proposal. Logic: This amount of time should be sufficient for the Minter to remedy an issue, but not so long that it materially disrupts its normal course of business.