-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathxft_research_m0_protocol_whitepaper_20240320.html
47 lines (47 loc) · 125 KB
/
xft_research_m0_protocol_whitepaper_20240320.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"/><title>M^0 Protocol Whitepaper - FINAL - 3/20/2024</title><style type="text/css"> * {margin:0; padding:0; text-indent:0; }
h1 { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: bold; text-decoration: underline; font-size: 25pt; }
.s1 { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: normal; text-decoration: underline; font-size: 12pt; }
.p, p { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 12pt; margin:0pt; }
.s3 { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 11pt; }
h2 { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: bold; text-decoration: none; font-size: 21pt; }
.s5 { color: black; font-family:"Times New Roman", serif; font-style: italic; font-weight: normal; text-decoration: none; font-size: 12pt; }
.s6 { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 8pt; vertical-align: 4pt; }
.s7 { color: black; font-family:"Times New Roman", serif; font-style: italic; font-weight: bold; text-decoration: none; font-size: 12pt; }
.s8 { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 6.5pt; vertical-align: 3pt; }
.s9 { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 10pt; }
h3 { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: bold; text-decoration: none; font-size: 15pt; }
.h4, h4 { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: bold; text-decoration: none; font-size: 12pt; }
a { color: #1154CC; font-family:"Times New Roman", serif; font-style: normal; font-weight: normal; text-decoration: underline; font-size: 10pt; }
.s11 { color: black; font-family:Arial, sans-serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 6.5pt; vertical-align: 3pt; }
.s13 { color: black; font-family:"Times New Roman", serif; font-style: italic; font-weight: normal; text-decoration: none; font-size: 10pt; }
.s15 { color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 11.5pt; }
.s16 { color: black; font-family:"Times New Roman", serif; font-style: italic; font-weight: normal; text-decoration: none; font-size: 11.5pt; }
li {display: block; }
#l1 {padding-left: 0pt;counter-reset: c1 1; }
#l1> li>*:first-child:before {counter-increment: c1; content: counter(c1, upper-roman)". "; color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: bold; text-decoration: none; font-size: 21pt; }
#l1> li:first-child>*:first-child:before {counter-increment: c1 0; }
#l2 {padding-left: 0pt;counter-reset: c2 1; }
#l2> li>*:first-child:before {counter-increment: c2; content: counter(c1, upper-roman)"."counter(c2, upper-roman)" "; color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: bold; text-decoration: none; font-size: 15pt; }
#l2> li:first-child>*:first-child:before {counter-increment: c2 0; }
#l3 {padding-left: 0pt;counter-reset: c3 1; }
#l3> li>*:first-child:before {counter-increment: c3; content: counter(c1, upper-roman)"."counter(c2, upper-roman)"."counter(c3, upper-roman)" "; color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: bold; text-decoration: none; font-size: 12pt; }
#l3> li:first-child>*:first-child:before {counter-increment: c3 0; }
#l4 {padding-left: 0pt;counter-reset: c2 1; }
#l4> li>*:first-child:before {counter-increment: c2; content: counter(c1, upper-roman)"."counter(c2, upper-roman)" "; color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: bold; text-decoration: none; font-size: 15pt; }
#l4> li:first-child>*:first-child:before {counter-increment: c2 0; }
#l5 {padding-left: 0pt; }
#l5> li>*:first-child:before {content: "● "; color: black; font-family:Arial, sans-serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 12pt; }
#l6 {padding-left: 0pt;counter-reset: c3 1; }
#l6> li>*:first-child:before {counter-increment: c3; content: counter(c1, upper-roman)"."counter(c2, upper-roman)"."counter(c3, upper-roman)" "; color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: bold; text-decoration: none; font-size: 12pt; }
#l6> li:first-child>*:first-child:before {counter-increment: c3 0; }
#l7 {padding-left: 0pt;counter-reset: c4 1; }
#l7> li>*:first-child:before {counter-increment: c4; content: counter(c1, upper-roman)"."counter(c2, upper-roman)"."counter(c3, upper-roman)"."counter(c4, upper-roman)" "; color: black; font-family:"Times New Roman", serif; font-style: italic; font-weight: bold; text-decoration: none; font-size: 12pt; }
#l7> li:first-child>*:first-child:before {counter-increment: c4 0; }
#l8 {padding-left: 0pt;counter-reset: c2 1; }
#l8> li>*:first-child:before {counter-increment: c2; content: counter(c1, upper-roman)"."counter(c2, upper-roman)" "; color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: bold; text-decoration: none; font-size: 15pt; }
#l8> li:first-child>*:first-child:before {counter-increment: c2 0; }
#l9 {padding-left: 0pt;counter-reset: c2 1; }
#l9> li>*:first-child:before {counter-increment: c2; content: counter(c1, upper-roman)"."counter(c2, upper-roman)" "; color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: bold; text-decoration: none; font-size: 15pt; }
#l9> li:first-child>*:first-child:before {counter-increment: c2 0; }
</style></head><body><h1 style="padding-top: 3pt;padding-left: 6pt;text-indent: 0pt;text-align: center;">M^0 Protocol Whitepaper</h1><p style="padding-top: 20pt;padding-left: 6pt;text-indent: 0pt;text-align: center;"><u>Author:</u> M^0 Foundation</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s3" style="padding-left: 126pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><u>Abstract:</u> The core M^0 protocol is a coordination layer for permissioned actors to generate <i>M</i>. <i>M </i>is a fungible token that can be generated by locking Eligible Collateral in a secure off-chain facility. The protocol enforces a common set of rules and safety procedures for the management of <i>M</i>.</p><p style="padding-top: 7pt;text-indent: 0pt;text-align: left;"><br/></p><ol id="l1"><li data-list-text="I."><h2 style="padding-left: 23pt;text-indent: -18pt;text-align: left;">Introduction</h2><p style="padding-top: 1pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">The <i>core </i>M^0 protocol (which excludes periphery contracts<span class="s6">1</span> and is hereon referred to simply as the M^0 protocol) is a coordination layer for permissioned actors to generate <i><b>M</b></i>. <i>M </i>is a crypto asset whose value is designed to be a robust representation of an exogenous collateral basket – a relationship enforced by the financial structure and market incentives of its generators. The purpose of <i>M </i>is to become a superior building block for value representation, by combining the convenience of digital money with the risk profile of physical cash. While holders may find this construct appropriate as a vehicle for <i>cryptodollar </i>use cases, developers and financial services providers might be interested in it as raw material for the build out of novel products and services – including as collateral for cryptodollars.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">When cash was primarily a physical construct, it had several properties that its holders found desirable but have since been lost in the process of digitization. Physical cash is first and foremost self-custodial; it’s a bearer instrument which guarantees that it cannot be frozen or seized without due process in the holder’s jurisdiction. For example, holders in one nation do not need to be concerned that a far away government can <i>turn off </i>the cash in their pocket. This feature allows cash to be credibly neutral, which means that it cannot discriminate against any specific holder. Second, physical cash does not carry additional counterparty risk, it is as good as holding reserves at the issuer’s central bank. Finally, physical cash is generally fungible with itself, which is to say that except in extraordinary circumstances where holders are wary to accept a certain serial number, no bill is more or less valuable than another. The downsides of physical cash are that it cannot be transferred electronically, it must be stored in a physically safe location which becomes exponentially more difficult to secure as the quantity held rises, is becoming less broadly accepted as a means of payment, and lacks general digital properties that can allow seamless composability and programmability.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 1pt;text-align: left;"><span/></p><p class="s8" style="padding-top: 4pt;padding-left: 5pt;text-indent: 0pt;text-align: justify;">1<span class="s9"> A periphery contract is a smart contract that adds supplement functionality, but exists outside of the core protocol.</span></p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Most users have historically believed those properties to be inherited by bank deposits, as if they were merely a digital representation of cash — the fallacy of this false equivalence is becoming evident due to the stress increasingly experienced by the banking system, and is exacerbated by the global nature of cryptodollars. What we call <i>digital cash </i>today is typically a commercial bank deposit that can be transferred electronically. It has several beneficial features such as the ability to earn interest, the ability to be transferred over the internet and across large distances, and it offers the peace of mind of digital and custodial security. It is also the most widely accepted form of payment through credit cards, debit cards, ACH, and SWIFT. Unfortunately bank deposits lose many of the desirable features of physical cash. Bank deposits are implicitly custodial and can be seized or frozen without due process in the holder’s jurisdiction – they are not credibly neutral. Due to the inherent characteristics of fractional reserve banking, bank deposits hold significant counterparty risk and are only as valuable as the specific bank’s balance sheet permits. For this reason they are also not fungible. A deposit in one bank cannot be treated as equal to a deposit in another, and thus introduces exorbitant clearing times between payments, as well as compounding complexity throughout the system.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">M <span class="p">is credibly neutral by design, it is by default self-custodial and fungible. Each </span>M <span class="p">is the same as every other </span>M <span class="p">and there is no ability for the protocol to discriminate against any specific holder(s). </span>M <span class="p">is stored and tracked on blockchains, and thus can be stored more securely at scale than physical cash. </span>M<span class="p">’s current instantiation is intended to be generated using short term US T-bills, representing the lowest level of counterparty risk excepting physical cash and bank reserves within the US dollar system. The T-bills used to generate </span>M <span class="p">must be held exclusively throughout a network of orphaned, bankruptcy-remote entities, which are customized to interact with the M^0 protocol while meeting the formalities of the existing legal system. </span>M <span class="p">can be sent anywhere in the world instantaneously using the blockchain rails on which it exists. Interest flowing to the T-bill collateral can be partly collected by the protocol and democratized across permissioned issuers and distributors.</span></p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">We refer to <i>M </i>as raw material for value representation, and not necessarily a cryptodollar in its own right, because the system relies on permissioned issuers (known as <i>Minters </i>in the protocol) for generation and distribution. These Minters should be compliant with all applicable regulations and may decide to distribute their own product, for example by wrapping the <i>M </i>token in a cryptodollar contract in a way that best meets their requirements. In this capacity, <i>M </i>becomes a monetary building block on top of which novel products can be built.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">In summary, the M^0 protocol introduces a superior coordination mechanism that democratizes access to the generation and management of programmable, digital cash instruments. It is an infrastructure layer not for the simplistic tokenization of real world bank deposits, but a much more sophisticated way to provide access to the liquidity on high-quality collateral. M^0 intends</p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">to redesign the monetary vertical stack, rather than build an additional layer on top of what has ultimately become byzantine infrastructure.</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li><li data-list-text="II."><h2 style="padding-left: 31pt;text-indent: -26pt;text-align: left;">Protocol</h2><p style="padding-top: 1pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">The M^0 protocol is a set of immutable smart contracts implemented for the Ethereum Virtual Machine. It receives all external inputs from a governance mechanism called the M^0 Two Token Governor, <i>TTG</i>, (see III. Governance). The M^0 protocol is a coordination tool for actors permissioned by governance, namely <i>Minters</i>, <i>Validators</i>, and <i>Earners</i>.</p><p style="text-indent: 0pt;text-align: left;"><br/></p><ol id="l2"><li data-list-text="II.I"><h3 style="padding-left: 30pt;text-indent: -25pt;text-align: left;">Operation</h3><p style="padding-top: 5pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Aside from users accessing the <i>M </i>token, which is permissionless, only actors permissioned through the TTG mechanism have access to the M^0 Protocol. The primary actors in the protocol are called Minters and Validators (see III.II 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 <i>M</i>. <i>M </i>is a standard ERC20 token. The core operating condition of the M^0 protocol is to ensure that all <i>M </i>in existence is backed by an equal or greater amount of value <i><b>Eligible Collateral </b></i>that is held in an <i><b>Eligible Custody Solution </b></i>(see IV.II Off-Chain Actors and Components). In this context, the protocol acts as the enforcer of a set of rules which controls the generation of <i>M</i>, the validation of collateral custody and value, and the assessment of fees when appropriate.</p><ol id="l3"><li data-list-text="II.I.I"><h4 style="padding-top: 12pt;padding-left: 32pt;text-indent: -27pt;text-align: left;">Generation of <i>M</i></h4><p style="padding-top: 8pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">In order to generate <i>M</i>, Minters must have a sufficient off-chain balance of Eligible Collateral which is represented on-chain by a frequently updated and validated number, known as the on-chain <i><b>Collateral Value</b></i>. Minters call the <b>Update Collateral </b>method to put this number on-chain. 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 are passed to a method, the contracts will take the minimum timestamp and the minimum threshold of signatures as defined by the TTG (see III.III Governance Controlled TTG Parameters). Optionally, they can pass a hash of arbitrary metadata and any open Retrieval IDs (see II.I.IV Retrieving Free Collateral) into the method as an argument. The Metadata Hash can be used to retrieve the actual off-chain metadata, which can serve to add context to the update, while Retrieval IDs allow Minters to remove outstanding balance subtractions (see II.I.IV Retrieving Free Collateral). Signature validation may either use</p><p style="padding-top: 4pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">standard <i>ecrecover</i><i>2</i>, which allows for the Minter to obtain the signature off-chain, or EIP-1271 on-chain contract signatures<span class="s6">3</span>. The collateral balance is an attestation to the value of the Eligible Collateral held in an Eligible Custody Solution (see IV.II Off-Chain Actors and Components for further details).</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">In order to post the value of their Eligible Collateral on-chain, the Minter 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 off-chain balances. Minters must update their Eligible Collateral number on-chain and with a valid Validator signature <i>at least </i>once every <i><b>Update Collateral Interval </b></i>(see II.III Governance Controlled Protocol Parameters). If a Minter fails to call Update Collateral within Update Collateral Interval of the previous time they called it, their on-chain 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 <i><b>Minter Rate </b></i>(see II.I.II 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 <i><b>Penalty Rate </b></i>on the Minter’s balance which is in violation (see II.I.II Protocol Fees).</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;text-align: justify;">Example: Eligible Collateral for M has been deemed to be 0-90 day T-bills. Minter 1 has</p><p class="s5" style="padding-top: 2pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">$10,000,000 of T-bills sitting in an Eligible Custody Solution. Minter 1 calls Update Collateral and passes 10,000,000, and a valid Validator signature as arguments. The on-chain Collateral Value of the Minter is now 10,000,000. The next day, $1,000,000 of the T-bills mature and convert to bank deposits, which are not considered Eligible Collateral. The Minter calls Update Collateral and passes 9,000,000, and a valid Validator signature as arguments. The on-chain collateral balance of the Minter is updated to 9,000,000.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Once a Minter has updated their on-chain collateral they are able to generate <i>M</i>. They do so by calling the <b>Propose Mint </b>method and passing in the amount of <i>M </i>they’d like to generate and the address which they would like to generate the <i>M </i>to. Once this method is called, it will first call <b>Get Present Amount </b>on the Minter's current balance of Owed M. It will then check to ensure that the on-chain Collateral Value multiplied by the <i><b>Mint Ratio </b></i>(see II.III Governance Controlled Protocol Parameters), including the amount they are currently attempting to generate and/or <i><b>Retrieve </b></i>(see II.I.IV Retrieving Free Collateral), is greater than the amount of total Owed M from the Minter. If these checks are passed the method will output a <i><b>Mint ID </b></i>which corresponds to the Propose Mint. A Minter can only have one outstanding Mint ID at any given time. If after the <i><b>Mint Delay </b></i>(see II.III Governance Controlled Protocol Parameters) the Mint ID has not been canceled by the Validator (see II.I.III Cancel and Freeze), the Minter may call the <b>Mint M </b>method and pass the Mint ID as an argument to execute the Propose Mint. The Mint Delay was</p><p style="padding-top: 4pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 1pt;text-align: left;"><span/></p><p class="s8" style="padding-top: 5pt;padding-left: 5pt;text-indent: 0pt;text-align: justify;">2<a href="https://soliditydeveloper.com/ecrecover" style=" color: black; font-family:"Times New Roman", serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 10pt;" target="_blank"> </a><a href="https://soliditydeveloper.com/ecrecover" target="_blank">https://soliditydeveloper.com/ecrecover</a></p><p class="s11" style="padding-left: 5pt;text-indent: 0pt;text-align: justify;">3<a href="https://eips.ethereum.org/EIPS/eip-1271" style=" color: black; font-family:Arial, sans-serif; font-style: normal; font-weight: normal; text-decoration: none; font-size: 10pt;" target="_blank"> </a><a href="https://eips.ethereum.org/EIPS/eip-1271" target="_blank">https://eips.ethereum.org/EIPS/eip-1271</a></p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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 II.I.III Cancel and Freeze). The Minter must call Mint M before the <i><b>Propose Mint Time To Live </b></i>has expired (see II.III Governance Controlled Protocol Parameters). Minters can destroy Owed M at any time by calling the <b>Burn </b>method and passing in their Minter Address and the amount of <i>M </i>they’d like to burn as arguments. Any address can repay <i>M </i>owed by a Minter by calling the Burn method and passing in the amount and Minter address as arguments.</p><p style="padding-top: 9pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 15pt;text-indent: 0pt;text-align: left;"><span/></p><p class="s9" style="padding-top: 5pt;padding-left: 6pt;text-indent: 0pt;text-align: center;">The <i>M </i>generation process and its limiting factors</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li><li data-list-text="II.I.II"><h4 style="padding-left: 37pt;text-indent: -32pt;text-align: justify;">Protocol Fees</h4><p style="padding-top: 8pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">There are two fees assessed on Minters in the M^0 protocol. The first is called Minter Rate, a governance controlled parameter, which is levied continuously on the Minter’s balance of Owed</p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">M. This fee compounds on a continuous basis. The beneficiaries of Minter Rate are the <i><b>Earn Mechanism </b></i>(see II.I.V The Earn Mechanism) and the <i><b>ZERO </b></i>holders (see III. 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. One of the primary invariants of the protocol is that the balance of a Minter’s Owed M should not exceed the on-chain Collateral Value (sans open Retrieval IDs) multiplied by the Mint Ratio. 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 the Minter Rate is contained in the Get Present Amount method, which is exclusively embedded in all other Minter methods and cannot be called independently. It is called in most methods, including Burn. 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 <b>Impose Penalty </b>method, which is exclusively embedded in the Update Collateral,Burn, and <b>Deactivate Minter </b>methods. When Impose Penalty is called in conjunction with Update Collateral, it checks</p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">for both missed Update Collateral Interval periods and the Minter’s balance of Owed M relative to their on-chain 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.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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 on-chain 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 on-chain 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 = 800,090.001 M.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">The following is a diagram which demonstrates a hypothetical sequence where a Minter incurs Penalty Rate charges. The example below describes this hypothetical sequence.</p><p style="text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 16pt;text-indent: 0pt;text-align: left;"><span/></p><p class="s9" style="padding-top: 11pt;padding-left: 6pt;text-indent: 0pt;text-align: center;">Hypothetical sequence where a Minter incurs Penalty Rate charges.</p><p style="text-indent: 0pt;text-align: left;"><br/></p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;text-align: justify;">Example (some balances are rounded):</p><p style="padding-top: 4pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Assume that the Mint 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%.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;text-align: justify;"><u>On Day 1</u>, a Minter calls Update Collateral and passes in 100 as the value. Its Owed M is 0.</p><p class="s5" style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 229%;text-align: justify;">Later that day (Day 1.1) the Minter generates 90 M. <u>On Day 2</u> the Minter fails to call Update Collateral.</p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><u>On Day 3</u> 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)) =</p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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 on-chain 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 on-chain Collateral Value being 0. The Minter’s Owed M is increased to (10.00035 * 1.0002) = 10.00235 M.</p></li><li data-list-text="II.I.III"><h4 style="padding-top: 12pt;padding-left: 42pt;text-indent: -37pt;text-align: justify;">Cancel and Freeze</h4><p style="padding-top: 8pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">There are two methods which can be used to stop an errant generation of <i>M </i>or to stop an errant Minter in the case of an emergency.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">The first method, <b>Cancel</b>, can be called by any Validator on any Mint ID associated with the generation of <i>M</i>. 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</p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">submitting a new Propose Mint will automatically cancel and replace any that are currently outstanding.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">The second method, <b>Freeze</b>, 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 <b>Minter Freeze Time </b>(see II.III Governance Controlled Protocol Parameters). It can be called multiple times on the same Minter to reset the Minter Freeze Time window. <span class="s15">If Freeze is called during an already existing Minter Freeze Time, the Minter Freeze Time window will restart from the beginning.</span></p><p style="padding-top: 1pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s16" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Example: A Validator calls freeze on a Minter and the Minter Freeze Time window is 6 hours. After 5 hours, the Validator calls Freeze again on the same Minter. The Minter is now frozen for an additional 6 hours. This means that the Minter will be frozen for 11 hours in total, unless a Validator calls Freeze again before the end of the second 6 hour period.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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.</p><p style="text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 102pt;text-indent: 0pt;text-align: left;"><span/></p><p style="padding-top: 1pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s9" style="padding-left: 6pt;text-indent: 0pt;text-align: center;">The three levels of escalation against an errant Minter</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li><li data-list-text="II.I.IV"><h4 style="padding-left: 41pt;text-indent: -36pt;text-align: left;">Retrieving Free Collateral</h4><p style="padding-top: 8pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Any Minter with an excess of off-chain 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 <b>Propose Retrieval </b>method</p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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 on-chain 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 <i><b>Retrieval ID</b></i>. The subtraction from the on-chain Collateral Value when relevant will remain until the Retrieval ID is closed.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">In order to close the Retrieval ID and eliminate the subtraction on the Minter’s on-chain 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 off-chain, or will not be processed at all, and that the new on-chain Collateral Value is correct.</p><p style="padding-top: 9pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 14pt;text-indent: 0pt;text-align: left;"><span/></p><p class="s9" style="padding-top: 8pt;padding-left: 6pt;text-indent: 0pt;text-align: center;">Diagram demonstrating the effect of Retrieve on a Minter’s on-chain Collateral Value.</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li><li data-list-text="II.I.V"><h4 style="padding-left: 36pt;text-indent: -31pt;text-align: left;">The Earn Mechanism</h4><p style="padding-top: 8pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">The <i><b>Earn Mechanism </b></i>is a mechanism in the protocol which allows Approved <i><b>Earners </b></i>(see II.II Governance Controlled Protocol Actors) to earn the <i><b>Earner Rate </b></i>(see II.III 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 <i>M </i>than is accruing from Minter Rate. To elaborate, the <i>utilization </i>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 <i>active M</i>) divided by the total amount of <i>M </i>in the Earn Mechanism. If a Minter is depermissioned by the TTG, their <i>M </i>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.</p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Once approved by the TTG, an Approved Earner can call the <b>Start Earning </b>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, <b>Stop Earning </b>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.</p></li><li data-list-text="II.I.VI"><h4 style="padding-top: 12pt;padding-left: 41pt;text-indent: -36pt;text-align: left;">Removing a Permissioned Actor</h4><p style="padding-top: 8pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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 <i>M</i>, and potentially penalties for missed intervals, is stored for repayment by the Minter or anyone interested in their off-chain collateral retrieval. This is to ensure that <i>M </i>does not get paid to the Earn Mechanism and to the <i>ZERO </i>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 off-chain actors can facilitate the winddown 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 <b>Deactivate Minter </b>method to cease the accrual of Minter Rate and the imposition of further Penalty Rate charges.</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li><li data-list-text="II.I.VII"><h4 style="padding-left: 46pt;text-indent: -41pt;text-align: left;">Example Interactions and Flows</h4><p style="padding-top: 8pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">The following is an example of how Permissioned Actors are intended to interact with the protocol, and how <i>M </i>is intended to flow through the protocol.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;text-align: justify;">Step 1: <span class="p">Minters, Validators, and Earners propose their addresses to the M^0 TTG.</span></h4><p style="padding-top: 4pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;text-align: justify;">Step 2: <span class="p">The TTG accepts or rejects the proposals.</span></h4><p style="padding-top: 4pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Step 3: <span class="p">Minters that were approved by the TTG are now on the Minter List. These Minters call for their first on-chain Collateral Value update.</span></h4><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Step 4: <span class="p">This Minter has contracted with at least one Validator off-chain. 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 on-chain 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,</span></h4><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">they will provide the Minter with their signature and a timestamp from when they performed the balance check.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Step 5: <span class="p">Once the Minter has obtained a valid signature and timestamp from the Validator(s) they will call Update Collateral to push the balance on-chain.</span></h4><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;text-align: justify;">Step 6: <span class="p">Now that the Minter has a positive on-chain Collateral Value, they are able to generate</span></h4><p style="padding-top: 2pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><i>M</i>. 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 on-chain Collateral Value (excluding any open Retrieval IDs) multiplied by the Mint Ratio<span class="s6">4</span>, 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.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><b>Step 7: </b>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 M and generate the <i>M</i>.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><b>Step 8: </b>Now that the <i>M </i>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 on-chain Collateral Value up to date or allow their on-chain Collateral Value to decrease below the permitted level. If the latter circumstance occurs, it is likely because the assets comprising the off-chain collateral have matured and are sitting in bank deposits.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><b>Step 9: </b>Assume that this Minter now wishes to repay some of the <i>M </i>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 <i>M </i>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 <i>M </i>that the Minter can generate and their Owed M, they can call the Retrieve method. The Retrieve method will first check if their on-chain 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 on-chain Collateral Value by the amount specified.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Step 10: <span class="p">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.</span></h4><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Step 11: <span class="p">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</span></h4><p style="text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 1pt;text-align: left;"><span/></p><p class="s8" style="padding-top: 4pt;padding-left: 5pt;text-indent: 0pt;text-align: justify;">4<span class="s9"> Note that if the on-chain Collateral Value was not updated within Update Collateral Interval it will be 0.</span></p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">on-chain Collateral Value associated with the Retrieval ID. The Minter once again requires the Validator signature data and timestamp for the transaction to succeed.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p></li></ol></li><li data-list-text="II.II"><h3 style="padding-left: 35pt;text-indent: -30pt;text-align: left;">Governance Controlled Protocol Actors</h3><p style="padding-top: 5pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><b>Minters </b>- 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 on-chain Collateral Value associated with their Minter address, Propose Mint <i>M</i>, Mint <i>M</i>, Burn <i>M</i>, and to Retrieve off-chain collateral.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Validators <span class="p">- A list of addresses (the Validator list, where the addresses are known as Validator IDs) 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.</span></h4><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Earners <span class="p">- A list of addresses (the Earner list, where the addresses are known as Earner IDs) maintained by the TTG mechanism. These addresses are able to control whether they earn the Earner Rate.</span></h4><p style="text-indent: 0pt;text-align: left;"><br/></p></li><li data-list-text="II.III"><h3 style="padding-left: 41pt;text-indent: -36pt;text-align: left;">Governance Controlled Protocol Parameters</h3><p style="padding-top: 5pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Note: These values will be set after launch through the TTG mechanism. It is not possible to deploy the protocol with preset parameters.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Minter Rate <span class="p">- The annualized percentage charged continuously to Minters on their Owed M. It is alterable with a Standard Proposal.</span></h4><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Penalty Rate <span class="p">- 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.</span></h4><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Example: Minter 1 has 1,000,000 Owed M but has not updated their on-chain Collateral Value within Update Collateral Interval, and hence the on-chain Collateral Value is 0. Whenever they call Update Collateral or Burn, and Impose Penalty is consequently called, they will pay Penalty Rate on 1,000,000 - (0 * Mint Ratio). So they will pay Penalty Rate on their full debt. 1,000,000</p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">* .01 = 10,000 M in Penalty Rate charges. This assumes that only one Update Collateral Interval period was missed.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><b>Earner Rate </b>- The annualized percentage paid to <i>M </i>in the Earn Mechanism. If the cumulative <i>M </i>paid out via the Earn Mechanism is going to be greater than the amount of <i>M </i>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.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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 <i>M </i>generated by the Minter Rate. It should not be set so low that it results in insufficient demand for <i>M </i>and thus an inefficient market for Minters.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><b>Mint Ratio </b>- This percentage is the fraction of a Minter’s on-chain Collateral Value that they can generate in M. It effectively controls the leverage of a Minter and the over-collateralization of <i>M</i>. It is alterable with a Standard Proposal.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Logic: This percentage controls the leverage of Minters and the over-collateralization of <i>M</i>. It should be set high enough to encourage attractive Minter economics, but not so high that it compromises the stability of <i>M</i>.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><b>Mint Delay</b>- This amount of time is the period between when a Minter has called Propose Mint and when they can first call Mint <i>M</i>. It serves as a protective measure to ensure all actors have sufficient time to audit each Mint. It is alterable with a Standard Proposal.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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 <i>M</i>.</p><h4 style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Propose Mint Time To Live <span class="p">- 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.</span></h4><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Update Collateral Interval <span class="p">- 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 on-chain Collateral Value is assumed to be 0 and they will incur Penalty Rate on the next update. It is alterable with a Standard Proposal.</span></h4><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Logic: This amount of time should be long enough to ensure that Validators can reliably check the status of the off-chain structures and balances, but not so long that it compromises the integrity of those checks.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Update Collateral Threshold <span class="p">- 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.</span></h4><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Minter Freeze Time <span class="p">- 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.</span></h4><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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.</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li></ol></li><li data-list-text="III."><h2 style="padding-left: 40pt;text-indent: -35pt;text-align: left;">Governance</h2><p style="padding-top: 1pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">The M^0 protocol uses a new on-chain governance mechanism called a TTG to manage its various inputs. TTG stands for <i>Two Token Govern</i>or and is a mechanism by which holders of the</p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">voting tokens are penalized for failing to vote. There are two utility tokens used in the M^0 TTG: <i><b>POWER </b></i>and <i>ZERO</i>. <i>POWER </i>is used to vote on active proposals and can be considered the primary management token of the mechanism. <i>POWER </i>holders will earn <i>ZERO </i>in exchange for their direct participation in governance. If a <i>POWER </i>holder delegates their balance to an address that is not also the holder of the tokens, it is this address which receives the <i>ZERO </i>rewards. <i>ZERO </i>holders are comparatively (to <i>POWER </i>holders) passive in the voting process and only vote on important changes. <i>ZERO </i>holders at any time may <b>Reset </b>(see: III.II.II.III ZERO Threshold Proposals) the <i>POWER </i>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. <i>POWER </i>holders are treated as a managerial class that is able to earn compensation through continued benevolent participation. This continued benevolence is judged by the <i>ZERO </i>holders who can always strip the <i>POWER </i>holders of their management rights, and thus their ability to earn future ownership in the protocol. If the composition and decisions of <i>POWER </i>holders trend towards either extreme, it is in the interest of <i>ZERO </i>holders to call Reset in order to restore balance.</p><p style="text-indent: 0pt;text-align: left;"><br/></p><ol id="l4"><li data-list-text="III.I"><h3 style="padding-left: 35pt;text-indent: -30pt;text-align: left;">Inputs</h3><p style="padding-top: 5pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">The M^0 TTG (hereafter TTG) is responsible for the following inputs to the M^0 protocol and to itself (see Section III.III Governance Controlled TTG Parameters, Section II.II Governance Controlled Protocol Actors, and Section II.III Governance Controlled Protocol Parameters for further context on the actors and parameters listed below):</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;text-align: left;">Governance Controlled TTG Parameters</h4><ul id="l5"><li data-list-text="●"><p style="padding-top: 2pt;padding-left: 41pt;text-indent: -18pt;text-align: left;">Proposal Fee</p></li><li data-list-text="●"><p class="s5" style="padding-top: 2pt;padding-left: 41pt;text-indent: -18pt;text-align: left;">POWER <span class="p">Threshold</span></p></li><li data-list-text="●"><p class="s5" style="padding-top: 2pt;padding-left: 41pt;text-indent: -18pt;text-align: left;">ZERO <span class="p">Threshold</span></p></li><li data-list-text="●"><p style="padding-top: 2pt;padding-left: 41pt;text-indent: -18pt;text-align: left;">CASH Toggle</p><p style="padding-top: 4pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;text-align: left;">Governance Controlled Protocol Actors</h4></li><li data-list-text="●"><p style="padding-top: 2pt;padding-left: 41pt;text-indent: -18pt;text-align: left;">A list of approved Minters</p></li><li data-list-text="●"><p style="padding-top: 2pt;padding-left: 41pt;text-indent: -18pt;text-align: left;">A list of approved Validators</p></li><li data-list-text="●"><p style="padding-top: 2pt;padding-left: 41pt;text-indent: -18pt;text-align: left;">A list of Approved Earners</p><p style="padding-top: 4pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;text-align: left;">Governance Controlled Protocol Parameters</h4></li><li data-list-text="●"><p style="padding-top: 2pt;padding-left: 41pt;text-indent: -18pt;text-align: left;">Minter Rate</p></li><li data-list-text="●"><p style="padding-top: 4pt;padding-left: 41pt;text-indent: -18pt;text-align: left;">Penalty Rate</p></li><li data-list-text="●"><p style="padding-top: 2pt;padding-left: 41pt;text-indent: -18pt;text-align: left;">Earner Rate</p></li><li data-list-text="●"><p style="padding-top: 2pt;padding-left: 41pt;text-indent: -18pt;text-align: left;">Mint Ratio</p></li><li data-list-text="●"><p style="padding-top: 2pt;padding-left: 41pt;text-indent: -18pt;text-align: left;">Mint Delay</p></li><li data-list-text="●"><p style="padding-top: 2pt;padding-left: 41pt;text-indent: -18pt;text-align: left;">Propose Mint Time To Live</p></li><li data-list-text="●"><p style="padding-top: 2pt;padding-left: 41pt;text-indent: -18pt;text-align: left;">Update Collateral Interval</p></li><li data-list-text="●"><p style="padding-top: 2pt;padding-left: 41pt;text-indent: -18pt;text-align: left;">Number of Signatures</p></li><li data-list-text="●"><p style="padding-top: 2pt;padding-left: 41pt;text-indent: -18pt;text-align: left;">Minter Freeze Time</p></li></ul><p style="text-indent: 0pt;text-align: left;"><br/></p></li><li data-list-text="III.II"><h3 style="padding-left: 41pt;text-indent: -36pt;text-align: left;">Operation</h3><p style="padding-top: 5pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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 M^0 protocol is deployed exclusively on the Ethereum Mainnet.</p><p style="text-indent: 0pt;text-align: left;"><br/></p><ol id="l6"><li data-list-text="III.II.I"><h4 style="padding-left: 42pt;text-indent: -37pt;text-align: left;">Epochs</h4><p style="padding-top: 8pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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 <b>Transfer Epoch</b>) is a non-voting period where transfers and delegation are enabled. The second 15-day epoch (the <i><b>Voting Epoch</b></i>) is where voting takes place on Standard Proposals and transfers and delegation are disabled. These restrictions on on-chain activity only apply to <i>POWER </i>tokens, there are no restrictions placed on the <i>ZERO </i>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 60 days, from submission to execution. During the 15-day Transfer Epoch, holders may transfer their balances, reassign delegations, and purchase <i>POWER </i>that is being auctioned.</p><p style="padding-left: 17pt;text-indent: 0pt;text-align: left;"><span/></p><p class="s9" style="padding-top: 7pt;padding-left: 6pt;text-indent: 0pt;text-align: center;">Diagram showing the Transfer and Voting Epochs</p></li><li data-list-text="III.II.II"><h4 style="padding-top: 13pt;padding-left: 46pt;text-indent: -41pt;text-align: left;">Proposals</h4><p style="padding-top: 8pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">The TTG has three types of proposals: (1) <i><b>Standard Proposals</b></i>, (2) <i><b>POWER Threshold Proposals</b></i>, and (3) <i><b>ZERO Threshold Proposals</b></i>. The use of threshold in the terminology represents a <i>yes threshold</i>, 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 below in further detail.</p><p style="text-indent: 0pt;text-align: left;"><br/></p><ol id="l7"><li data-list-text="III.II.II.I"><p class="s7" style="padding-left: 54pt;text-indent: -49pt;text-align: justify;">Standard Proposals</p><p style="padding-top: 8pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Standard Proposals are voteable only by <i>POWER </i>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 <i>POWER </i>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.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Example: During a Voting Epoch a proposal to change Minter Rate is made. Only 10% of the POWER tokens choose to participate. When voting on the proposal, 60% of the participating POWER tokens vote yes. This proposal is passed because the yes votes are greater than the no votes. The total number of POWER holders participating is only relevant in votes which require a POWER Threshold.</p></li><li data-list-text="III.II.II.II"><p class="s7" style="padding-top: 3pt;padding-left: 59pt;text-indent: -54pt;text-align: justify;">POWER Threshold Proposals</p><p style="padding-top: 8pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">A <i>POWER </i>Threshold Proposal can be used to submit anything which would otherwise be a Standard Proposal, except it requires a <i>POWER </i>Threshold and is immediately votable and subsequently immediately executable rather than only being votable and executable in the future epochs. For this reason, <i>POWER </i>holders are likely to use this proposal type in the case of an urgent or emergency situation. If a <i>POWER </i>Threshold has not been reached before the proposal expires, the proposal cannot be executed. <i>POWER </i>Threshold Proposals expire at the end of the next epoch.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Example: During the Transfer Period a POWER Threshold Proposal is made to change Minter Rate, which requires a POWER Threshold due to it being an POWER Threshold Proposal. The POWER Threshold is set to 75%. The proposal becomes immediately votable and a full 100% of the POWER supply chooses to participate – 80% vote affirmatively. This proposal has passed and is instantly executable upon the POWER Threshold being met. This is because it achieved yes votes from greater than 75% of the POWER supply (100% * 80% = 80% yes). Note that the proposal very well could have gone on to accumulate more yes votes, but was likely executed immediately or soon after meeting the POWER Threshold.</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li><li data-list-text="III.II.II.III"><p class="s7" style="padding-left: 63pt;text-indent: -58pt;text-align: justify;">ZERO Threshold Proposal</p><p style="padding-top: 8pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">A <i>ZERO </i>Threshold Proposal is used for Reset, to toggle CASH between <i>WETH </i>and <i>M</i>, and to set the <i>POWER </i>and <i>ZERO </i>Thresholds themselves. The Reset method is a special feature reserved for the <i>ZERO </i>token holders which allows a yes threshold of <i>ZERO </i>holders to change the current governor of the system to a new version with a new <i>POWER </i>token that is claimable pro rata to <i>ZERO </i>holders or to existing <i>POWER </i>holders. They do this by creating a proposal to call the Reset method. Mechanically this is affected by replacing the current governor (<i>POWER </i>token address) of the system with a new instance, where the starting balance of the <i>POWER </i>tokens are proportional to each <i>ZERO </i>holder's balance in the epoch before the Reset. It is immediately executable upon achieving a yes threshold. It is intended for <i>ZERO </i>holders to use this feature should they find something irreparably wrong with the composition and/or voting patterns of the current <i>POWER </i>holders and wish to take on voting responsibility themselves. It is anticipated that <i>ZERO </i>holders will only Reset the governor to the existing <i>POWER </i>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.</p><p class="s5" style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Example: The ZERO Threshold is set to 60%. POWER holders seem likely to pass a proposal to add a perceived malicious actor to the Minter List. A user submits a proposal to Reset. This proposal is immediately votable – it achieves 70% of the total ZERO supply voting yes. This proposal is passed and is immediately executable. All currently votable proposals, including the proposal to add the perceived malicious Minter, are effectively canceled.</p><p style="text-indent: 0pt;text-align: left;"><br/></p><p class="s7" style="padding-left: 5pt;text-indent: 0pt;text-align: justify;">III.II.II.V Proposal Matrix</p><p style="padding-top: 8pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">The diagram below details the three types of proposals in the TTG and highlights which actions are associated with each type.</p><p style="padding-top: 6pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 7pt;text-indent: 0pt;text-align: left;"><span/></p><p class="s9" style="padding-top: 5pt;padding-left: 6pt;text-indent: 0pt;text-align: center;">Diagram of Proposal Types with associated token responsibility, mechanics, and actions.</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li></ol></li><li data-list-text="III.II.III"><h4 style="padding-left: 51pt;text-indent: -46pt;text-align: left;">Checkpoints and Voting</h4><p style="padding-top: 8pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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 <i>POWER </i>Threshold Proposals, which will not include standard inflationary proposals by definition. In order to vote the <i>POWER </i>owner’s delegate address (hereon referred to as the <i>POWER </i>holder) calls the <b>Cast Votes </b>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.</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li><li data-list-text="III.II.IV"><h4 style="padding-left: 50pt;text-indent: -45pt;text-align: left;">Proposing</h4><p style="padding-top: 8pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Anyone with an ethereum address and <i><b>WETH </b></i>or <i>M </i>may submit a proposal. The TTG is to be deployed with <i>WETH </i>as its internal currency (known as <i>CASH </i>in the mechanism), and therefore any Standard Proposal submission must pay a Proposal Fee in <i>WETH, </i>or at a later date <i>M </i>depending on the current CASH toggle setting, in addition to gas fees (see III.III Governance Controlled TTG Parameters). A proposal that passes makes the Proposal Fee available to be returned to the proposer upon execution.</p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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 M^0 protocol looks to the registrar to use certain variables and sets of addresses in its processes.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">In order to propose a change to a list, a user submits a Standard Proposal or a <i>POWER </i>Threshold Proposal calling the <b>Add To List </b>or <b>Remove From List </b>methods along with the address they wish to add or remove. There is also a method called <b>Remove From And Add To List </b>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 M^0 core protocol is immutable, any list added after deployment can only be used to manage periphery smart contracts and cannot impact core operations.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Example: Alice wishes to add her company’s address to the list of approved Minters in the M^0 protocol. Alice calls Add To List, specifying the Minters list along with the address she would like to gain permission to mint M in the protocol.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">In order to propose a change to a configuration contract proposers call the <b>Set Key </b>method<span class="s6">5</span>. 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).</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Example: Bob wishes to change Minter Rate from 3% to 4%. Bob calls Set Key and specifies the configuration contract he’d like to change along with the new value he would like it to contain.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Once a proposal passes, and assuming the requisite amount of time has passed, anyone can call the <b>Execute </b>method to execute the action on chain. They must pass the proposal arguments into the Execute method.</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li><li data-list-text="III.II.V"><h4 style="padding-left: 46pt;text-indent: -41pt;text-align: left;">Inflation Mechanics</h4><p style="padding-top: 8pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">In each epoch the supply of <i>POWER </i>is inflated by 10% and the supply of <i>ZERO </i>is inflated by up to 5,000,000 tokens. This inflation is claimed <i>pro rata </i>by participating <i>POWER </i>holders, specifically by the delegate address. Any <i>POWER </i>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</p><p style="text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 1pt;text-align: left;"><span/></p><p class="s8" style="padding-top: 4pt;padding-left: 5pt;text-indent: 0pt;text-align: justify;">5<span class="s9"> In certain user interface implementations, this method may be referred to as “Set Protocol Configuration”</span></p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Transfer Epoch. Therefore if a user purchases <i>POWER </i>during an auction they will always be able to use those tokens to vote in the subsequent Voting Epoch. Each participating <i>POWER </i>holder during the Voting Epoch will also receive their <i>pro rata </i>(based on their percentage of total voting power) share of the 5,000,000 <i>ZERO </i>tokens.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Once a Standard Proposal has been submitted it can be voted on in the following Voting Epoch, unless it is a <i>POWER </i>Threshold Proposal or a <i>ZERO </i>Threshold Proposal, which can be voted on at any time. When a Standard Proposal becomes available for voting, it is mandatory for <i>POWER </i>holders to vote on it or else the owner of the <i>POWER </i>tokens will lose relative voting weight in the system. If a <i>POWER </i>owner’s delegate fails to vote on <i>any </i>proposal in an epoch, they will forfeit any <i>POWER </i>or <i>ZERO </i>inflation they would have otherwise been able to claim. <i>POWER </i>holders must vote on all Standard Proposals in the Voting Epoch; <i>POWER </i>Threshold Proposals and <i>ZERO </i>Threshold Proposals do not factor into <i>POWER </i>inflation dynamics. There is no inflation if an epoch only has <i>POWER </i>Threshold Proposals and/or <i>ZERO </i>Threshold Proposals, or no proposals at all.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><u>Example:</u> Alice is a POWER holder with 1,000 POWER tokens, the total POWER supply is 10,000; hence Alice controls 10% of the POWER voting weight. In epoch 1 she participates fully by voting on all Standard Proposals. Simultaneous to participating, Alice claims an additional 100 POWER tokens and 500,000 ZERO tokens, i.e. 10% of a POWER inflation of 1,000 tokens and 10% of a ZERO inflation of 5,000,000 tokens. In epoch 2 Alice fails to vote on a Standard Proposal and is therefore not able to claim any POWER or ZERO tokens. The 110 POWER tokens (i.e. 10% of the new additional POWER supply of 1,100 tokens) that should have gone to Alice are auctioned in the Dutch auction. Bob buys these 110 tokens for 1 WETH (the internal currency of the TTG) and can now participate in the following voting epoch. The ZERO tokens that should have gone to Alice are simply never minted.</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li><li data-list-text="III.II.VI"><h4 style="padding-left: 50pt;text-indent: -45pt;text-align: left;">Dutch Auction</h4><p style="padding-top: 8pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Once the Transfer Epoch has begun the Dutch auction will begin simultaneously if any <i>POWER </i>holder failed to participate. The price per basis point (0.01%) of <i>POWER </i>token, calculated as a percentage of the total <i>POWER </i>supply, in the Dutch auction will start at 2<span class="s6">99</span> wei (the smallest unit of <i>WETH</i>) 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<span class="s6">98</span> wei and linearly decrease to 2<span class="s6">97</span> 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 <i>POWER </i>in the Dutch auction, purchasers must call the <b>Buy </b>method. The diagrams below illustrate the intended price curve of the Dutch auction in ETH over the 15 day period. The first</p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: left;">demonstrates the entire price curve, while the second shows a smaller slice of the curve to demonstrate its semi-linearity.</p><p style="text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 34pt;text-indent: 0pt;text-align: left;"><span/></p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s13" style="padding-left: 6pt;text-indent: 0pt;text-align: center;">The price of 1 basis point of POWER in ETH at each 3.6-hour period (shown in days).</p><p style="text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 32pt;text-indent: 0pt;text-align: left;"><span/></p><p style="padding-top: 7pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s13" style="padding-left: 6pt;text-indent: 0pt;text-align: center;">A “slice” of the price curve between periods 40 and 50.</p><p style="padding-top: 10pt;text-indent: 0pt;text-align: left;"><br/></p></li><li data-list-text="III.II.VII"><h4 style="padding-left: 55pt;text-indent: -50pt;text-align: left;">Delegation</h4><p style="padding-top: 8pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Both <i>POWER </i>and <i>ZERO </i>owners may delegate their voting power to an arbitrary Ethereum address during the Transfer Epoch. Delegated <i>POWER </i>will retain its inflation in the <i>owner </i>address, while <i>ZERO </i>rewards will be claimable by the <i>delegate </i>address. Owning <i>ZERO </i>does not earn the owner or the owner’s delegate inflation or rewards aside from <i>M </i>generated by the protocol fees, and thus delegation does not have any impact on the owner outside of transferring voting power. <i>ZERO </i>does earn fees from the Proposal Fee on failed Standard Proposals and from the Minter Rate. 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 <i>POWER </i>and <i>ZERO </i>follow the ERC20 standard and holders must call the <b>Delegate </b>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.</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li><li data-list-text="III.II.VIII"><p class="s7" style="padding-left: 60pt;text-indent: -55pt;text-align: justify;">ZERO <span class="h4">Claiming of Residual Value</span></p><p style="padding-top: 8pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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 <i>ZERO </i>holders are Proposal Fee payments from proposal submission, the payments from <i>POWER </i>token auctions, and a portion of Minter Rate and Penalty Rate charges to Minters (see II.I.II Protocol Fees). Proposal Fee and auction payments are collected in <i>WETH </i>or <i>M</i>, depending on the status of the CASH toggle, and Minter Rate is collected in <i>M</i>. At any time a <i>ZERO </i>holder may call the <b>Claim </b>method in order to claim this accumulated value. The amount of claimable tokens are pro rata to each account's <i>ZERO </i>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.</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li></ol></li><li data-list-text="III.III"><h3 style="padding-left: 47pt;text-indent: -42pt;text-align: left;">Governance Controlled TTG Parameters</h3><p style="padding-top: 9pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;text-align: justify;">CASH <span class="p">- The internal currency of the TTG. It is used to pay Proposal Fee and to purchase</span></h4><p class="s5" style="padding-top: 2pt;padding-left: 5pt;text-indent: 0pt;text-align: justify;">POWER <span class="p">in the Dutch auction. It can be toggled between </span>WETH <span class="p">and </span>M<span class="p">.</span></p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Proposal Fee <span class="p">- The amount paid in CASH to submit any proposal. It is alterable with a Standard Proposal.</span></h4><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Logic: This amount should be sufficiently high to deter spam, but not so high as to deter legitimate proposals.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><i><b>POWER </b></i><b>Threshold </b>- The number of yes votes as a percentage of the total <i>POWER </i>supply required to pass proposals which require a <i>POWER </i>Threshold.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Example: POWER Threshold = 80%. Therefore if there are 10,000 total POWER in existence, 8,000 POWER will need to vote affirmatively for a proposal to pass that requires a POWER Threshold.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><i><b>ZERO </b></i><b>Threshold </b>- The number of yes votes as a percentage of the total <i>ZERO </i>supply required to pass proposals which require a <i>ZERO </i>Threshold.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Example: ZERO Threshold = 60%. Therefore if there are 1,000,000,000 total ZERO in existence, 600,000,000 ZERO will need to vote affirmatively for a proposal to pass that requires a POWER Threshold.</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li><li data-list-text="III.IV"><h3 style="padding-left: 46pt;text-indent: -41pt;text-align: left;">Immutable TTG Parameters</h3><p style="padding-top: 9pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><b>Epoch Duration </b>- The combined length of the Voting Epoch and the Transfer Epoch. <u><i>Set to 30</i></u><i> </i><u><i>days</i></u>.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Logic: This amount of time should be short enough to permit for timely management of the protocol, but long enough for all <i>POWER </i>holders to both socialize and physically vote on Standard Proposals.</p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;text-align: left;"><b>Voting Epoch Duration </b>- The length of the Voting Epoch. <u><i>Set to 15 days</i></u>.</p><p style="padding-top: 4pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Logic: This amount of time should be long enough to permit <i>POWER </i>holders to physically exercise their vote.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;text-align: left;"><b>Transfer Epoch Duration </b>- The length of the Transfer Epoch. <u><i>Set to 15 days</i></u>.</p><p style="padding-top: 4pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;text-align: left;">Logic: This amount of time should be long enough to contain the Dutch auction and for any</p><p class="s5" style="padding-top: 2pt;padding-left: 5pt;text-indent: 0pt;text-align: left;">POWER <span class="p">holders that may wish to perform transfers or re-delegations to do so.</span></p><p style="padding-top: 4pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><b>Auction Duration </b><span class="p">- The length of the Dutch auction for unclaimed </span>POWER <span class="p">inflation. </span><u>Set to 15</u> <u>days</u> <span class="p">and overlaps perfectly with the Transfer Epoch.</span></p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><b>Dutch Auction Exponent </b>- The exponent with a base of 2 that determines the starting auction price. <u><i>Set to 99</i></u>.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Logic: This number should produce a sufficiently high starting price per <i>POWER </i>token such that the market price of <i>POWER </i>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.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><b>Dutch Auction Periods </b>- The number of equal periods that must fit into the Transfer Epoch. <u><i>Set</i></u><i> </i><u><i>to 100</i></u>.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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.</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li><li data-list-text="III.V"><h3 style="padding-left: 40pt;text-indent: -35pt;text-align: left;">Immutable <i>POWER </i>Parameters</h3><p style="padding-top: 5pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><i><b>POWER </b></i><b>Initial Supply </b>- The initial supply of <i>POWER </i>tokens before any inflation. <u><i>Set to</i></u><i> </i><u><i>10,000</i></u>. Decimals are 0.</p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Logic: The initial supply of <i>POWER </i>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 <i>POWER </i>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 <i>ZERO </i>holder would not receive any <i>POWER </i>tokens. For example, since new <i>POWER </i>(post-Reset) is based on existing <i>ZERO </i>balances, anyone who owns less than 1/ <i>POWER </i>Initial Supply of a <i>ZERO </i>token will get 0 <i>POWER </i>after a Reset.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><i><b>POWER </b></i><b>Inflator </b>- The percentage inflation of the <i>POWER </i>supply per active epoch. This occurs only in epochs with a votable proposal, hence why they are referred to as active. If a <i>POWER </i>holder fails to fully participate in an epoch with at least one votable, their balance of <i>POWER </i>tokens will not decrease but their percentage of overall voting power will decrease by 1 / (1 + <i>POWER </i>Inflator). <u><i>Set to 10%</i></u>.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Logic: This percentage must sufficiently encourage <i>POWER </i>holder participation without occasional lapses in participation destabilizing the system. At 10% inflation, a <i>POWER </i>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 <i>POWER </i>Inflator on an inactive participant, and a comparison of <i>POWER </i>Inflator and decimal setting as they impact overflow times assuming a 30-day total epoch time.</p><p style="padding-left: 35pt;text-indent: 0pt;text-align: left;"><span/></p><p style="padding-top: 6pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s13" style="padding-left: 7pt;text-indent: 0pt;line-height: 114%;text-align: center;">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</p><p style="padding-top: 7pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 7pt;text-indent: 0pt;text-align: left;"><span/></p><p class="s13" style="padding-top: 5pt;padding-left: 6pt;text-indent: 0pt;line-height: 114%;text-align: center;">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 10,000.</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li><li data-list-text="III.VI"><h3 style="padding-left: 46pt;text-indent: -41pt;text-align: left;">Immutable <i>ZERO </i>Parameters</h3><p style="padding-top: 9pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: left;"><i><b>ZERO </b></i><b>Initial Supply </b>- The initial supply of the <i>ZERO </i>token before any rewards. <u><i>Set to</i></u><i> </i><u><i>1,000,000,000</i></u>. Decimals are 6.</p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Logic: The initial supply of <i>ZERO </i>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.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><i><b>ZERO </b></i><b>Reward </b>- The maximum amount of <i>ZERO </i>given to <i>POWER </i>holders in a Voting Epoch. Each <i>POWER </i>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. <u><i>Set to 5,000,000</i></u>.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">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 <i>POWER </i>one must own to justify participation.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Example: Alice has 10% of the POWER supply delegated to her. She fully participates in a Voting Epoch and is rewarded with 10% of the reward, in this case 500,000 ZERO tokens.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;text-align: justify;">See the diagrams below for further illustration of the potential impact of the reward on the <i>ZERO</i></p><p style="padding-top: 2pt;padding-left: 5pt;text-indent: 0pt;text-align: justify;">supply over time.</p><p style="text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 20pt;text-indent: 0pt;text-align: left;"><span/></p><p style="padding-top: 5pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s9" style="padding-left: 6pt;text-indent: 0pt;text-align: center;">Maximum <i>ZERO </i>inflation per epoch over 240 epochs (20 years)</p><p style="text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 20pt;text-indent: 0pt;text-align: left;"><span/></p><p style="padding-top: 6pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s9" style="padding-left: 6pt;text-indent: 0pt;text-align: center;">Maximum <i>ZERO </i>supply over 240 epochs</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li></ol></li><li data-list-text="IV."><h2 style="padding-left: 36pt;text-indent: -31pt;text-align: left;">The M^0 Economy</h2><p style="padding-top: 1pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">The M^0 protocol is a coordination mechanism. It is not intended to replace existing financial actors, but rather to provide novel and more efficient means by which they can interact. We believe that a universal blockchain-based protocol, where rules and transparency are enforced by code, is superior to the feudal and opaque landscape of value transmission present today.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">The M^0 Protocol is intended to coordinate Minters, Validators, and Earners. It is anticipated that off-chain this may correspond to financial services providers (such as cryptodollar issuers), auditors, and institutional holders of <i>M</i>.</p><p style="text-indent: 0pt;text-align: left;"><br/></p><ol id="l8"><li data-list-text="IV.I"><h3 style="padding-left: 33pt;text-indent: -28pt;text-align: left;">Minters</h3><p style="padding-top: 5pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Minters are primarily incentivized to join the protocol because they want to earn the spread between the yield (net of expenses) on their Eligible Collateral and the protocol’s Minter Rate. In</p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">addition, the <i><b>Mint Ratio </b></i>will determine the attractiveness of Minting relative to the yield spread. The effective ROC (<i>return on capital</i>) of a Minter is net yield generated on the Eligible Collateral, divided by the net cash investment, which is the capital invested into Eligible Collateral, minus their Owed M (assuming they were able to sell this <i>M </i>at $1) plus the Administrative Buffer. It is anticipated that Minters in the M^0 protocol will correspond to financial services providers (such as cryptodollar issuers) off-chain. The ultimate function of the Minter is the generation and management of the supply of <i>M</i>. Considering the initial Eligible Collateral is intended to be short term T-bills, it is assumed that the Minter Rate will need to be less than the US Federal Funds rate. See the diagram below for a visual example of the basic Minter economics.</p><p style="padding-top: 10pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 43pt;text-indent: 0pt;text-align: left;"><span/></p><p class="s9" style="padding-top: 11pt;padding-left: 6pt;text-indent: 0pt;text-align: center;">Diagram demonstrating the basic economics of a Minter</p><p style="padding-top: 6pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">It is also anticipated that Minters will engage in arbitrage. If <i>M </i>is trading above $1 on secondary markets, it is logical for Minters to deposit Eligible Collateral in order to generate more <i>M</i>. This will boost their net yield. Conversely, if <i>M </i>is trading below $1 on secondary markets, it is logical for Minters to repurchase <i>M </i>and to use it to Retrieve Eligible Collateral. This will also boost their net yield. It is for this reason that <i>M </i>is expected to trade with some volatility around (US)</p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">$1 – the mechanism relies on sometimes inefficient and unpredictable market forces to achieve an average price of $1 over the long term.</p><p style="text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 67pt;text-indent: 0pt;text-align: left;"><span/></p><p style="padding-top: 4pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s9" style="padding-left: 6pt;text-indent: 0pt;text-align: center;">A hypothetical price curve for <i>M </i>with expected Minter activity</p><p style="padding-top: 6pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">There will be no built in mechanism at the protocol level to ensure the price stability of <i>M</i>; rather, that will be achieved via the economic incentives described and visualized above.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p></li><li data-list-text="IV.II"><h3 style="padding-left: 38pt;text-indent: -33pt;text-align: left;">Validators</h3><p style="padding-top: 5pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Economically, all Validators must be incentivized off-chain or use periphery smart contracts. There is no Validator compensation in the core protocol. This decision was made because the Validator landscape is complex and the chance of accurately encapsulating these complex economic arrangements on-chain was nil. For the basic function of providing signatures for Update Collateral, it is expected that Validators and Minters will enter into binding, off-chain legal agreements specifying applicable terms and appropriate compensation. It is anticipated that Validators in the M^0 protocol will eventually correspond to auditors off-chain. The ultimate function of the Validator is to provide as close to real time attestation of the Eligible Collateral being used to generate <i>M </i>as possible.</p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">While the protocol considers all Validator addresses to be fungible, there are in fact many specializations that could occur off-chain in the Validator ecosystem. For instance, there may be Validators that specialize in signing off on on-chain Collateral Value updates, while others act as “sentinels” and exclusively exist to call Cancel and Freeze on errant Minters. The level of specialization could even go beyond the initial methods of the protocol as periphery contracts are added by the ecosystem.</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li><li data-list-text="IV.III"><h3 style="padding-left: 44pt;text-indent: -39pt;text-align: left;">Earners</h3><p style="padding-top: 5pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Earners are simply addresses approved by the TTG to earn the Earner Rate. It is expected that, throughout the cycle, the Earner Rate will remain comparable to the US Federal Funds rate as well in order to entice Earners to continue to hold <i>M</i>. The Earner Rate can be used as an additional tool to encourage <i>M </i>price stability around $1. If the price of <i>M </i>is above $1, the TTG can lower the Earner Rate in order to discourage holding of <i>M </i>and to encourage selling of <i>M </i>for alternative sources of yield. If the price of <i>M </i>is below $1, the TTG can raise the Earner Rate in order to encourage the holding and purchase of <i>M</i>. It should be noted that the Earner Rate can be higher than the Minter Rate as long as the amount of <i>M </i>being paid out via the Earner Rate is less than the amount of total <i>M </i>generated from Minter Rate.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">It is anticipated that Earners in the M^0 protocol will correspond to institutional holders of <i>M </i>off-chain, and to issuers and distributors that maintain <i>M </i>inventory. The ultimate function of Earners is as a source of demand for <i>M</i>, making it more likely that Minters can efficiently generate <i>M</i>. This is effectively to say that Earners align nicely with the ultimate distributors of <i>M </i>to the broader market.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Example: The TTG permissions a large cryptocurrency exchange to the Earners list. This exchange has millions of users and is regulated/licensed appropriately in the jurisdiction(s) it serves. Once permissioned, the exchange can use customer’s M to earn the Earner Rate. They can now pass a portion or all of the Earner Rate on to their customers.</p><p style="padding-left: 32pt;text-indent: 0pt;text-align: left;"><span/></p><p style="text-indent: 0pt;text-align: left;"><br/></p><p class="s9" style="padding-left: 6pt;text-indent: 0pt;text-align: center;">Diagram showing how Earners may distribute <i>M </i>yield to end users</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li></ol></li><li data-list-text="V."><h2 style="padding-left: 27pt;text-indent: -22pt;text-align: left;">Off-Chain Ecosystem</h2><p style="padding-top: 1pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">The M^0 protocol relies on the presence of several off-chain actors and components, and a feedback process referred to as “guidance” to function properly.</p><p style="text-indent: 0pt;text-align: left;"><br/></p><ol id="l9"><li data-list-text="V.I"><h3 style="padding-left: 27pt;text-indent: -22pt;text-align: left;">Guidance</h3><p style="padding-top: 5pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">It is anticipated that as the M^0 ecosystem grows, an increasing number of stakeholders will have an interest in its continued development and improvement. These stakeholders are referred to as <i>Think Tanks</i>. Much as the Basel Committee and its cooperating international regulators</p><p style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">have provided (theoretically non-committal) guidance and rules for the banking sector, it is anticipated that similar groups and perhaps new M^0-specific institutions will provide guidance for the M^0 ecosystem and protocol. The protocol is designed in such a way that it can formally adopt guidance through a governance vote and enforce this guidance throughout the system via the Validators. It is intended to function as follows:</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;text-align: left;">Step 1: <span class="p">Think Tanks provide guidance.</span></h4><p style="padding-top: 4pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Step 2: <span class="p">The TTG adopts or rejects this guidance by voting on a hash of a public document containing it.</span></h4><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;text-align: left;">Step 3: <span class="p">Permissioned Actors adjust their behavior accordingly.</span></h4><p style="padding-top: 4pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Step 4: <span class="p">Validators withhold signatures, Cancel Propose IDs, or Freeze Minters who have not adjusted their behavior to be in line with the guidance. If there is still non-compliance, the TTG can remove errant actors from the system.</span></h4><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;text-align: left;">This combination of steps creates the “guidance feedback loop.”</p><p style="text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 15pt;text-indent: 0pt;text-align: left;"><span/></p><p class="s9" style="padding-top: 11pt;padding-left: 6pt;text-indent: 0pt;text-align: center;">Illustration of the guidance feedback loop</p><p style="padding-top: 6pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s5" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Example: Think Tanks interested in the progress of the M^0 ecosystem and protocol determine that only certain jurisdictions are appropriate to host Eligible Custody Solutions. These Think Tanks put out guidance amending the definition of an Eligible Custody Solution to include a list of appropriate jurisdictions, and stipulate that all Minters should be in compliance with this list within 180 days of the proposal’s execution. The document is hashed so that all actors can</p><p class="s5" style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">validate they have the same and correct version of the guidance, and this hash is submitted to the TTG under a guidance list. The POWER holders will then vote on the proposal. If it passes, the guidance should be considered approved and enforceable. Once the 180 day window is complete (which is also defined in the guidance), Validators should begin to withhold signatures on Update Collateral calls from Minters that attempt to include Eligible Collateral held in an unapproved jurisdiction in their on-chain collateral value. Validators can also call Cancel or Freeze on a Minter that is errant in other ways not capturable in the Update Collateral Method. Validators not enforcing the approved guidance should expect to be removed by the TTG.</p><p style="text-indent: 0pt;text-align: left;"><br/></p></li><li data-list-text="V.II"><h3 style="padding-left: 33pt;text-indent: -28pt;text-align: left;">Off-Chain Actors and Components</h3></li></ol></li></ol><p style="padding-top: 5pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">The following components and their associated guidance represent those contemplated for the launch of the protocol. This list is not exhaustive and will likely change over time. While much of the guidance is currently quantitative, there is nothing prohibiting qualitative guidance that is left to the interpretation of the various actors. The guidance will also include legal templates and agreements that will contain terms required to ensure smooth operation of the off-chain components.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><b>Eligible Collateral </b>- A description of portfolio composition which can be placed in Eligible Custody Solutions and be used to generate an on-chain Collateral Value, which is subsequently used in the generation of <i>M</i>.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;text-align: left;"><u>Guidance at launch:</u> 30-90 day US Government T-bills.</p><p style="padding-top: 4pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Eligible Custody Solution <span class="p">- A description of entity structures, jurisdictions, contractual agreements, and other details that will suffice for the custody of Eligible Collateral.</span></h4><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;text-align: left;"><u>Guidance at launch: </u> Orphaned SPV<span class="s6">6</span> in approved jurisdiction.</p><p style="padding-top: 4pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Administrative Buffer <span class="p">- An amount of value that a Minter may be compelled to set aside to the Eligible Custody Solution Operator that is not included in the Minter’s Eligible Collateral. This value is intended to be used by the Eligible Custody Solution Operator to facilitate the orderly winddown of the facility should the Minter become inactive or incapacitated.</span></h4><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s1" style="padding-left: 5pt;text-indent: 0pt;text-align: left;">Guidance at launch: $100,000.</p><p style="text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 1pt;text-align: left;"><span/></p><p class="s8" style="padding-top: 5pt;padding-left: 5pt;text-indent: 0pt;text-align: left;">6<span class="s9"> An SPV (Special Purpose Vehicle) is a legal entity structured intentionally to serve a specific purpose. In the case of the M^0 ecosystem, that purpose is to securely custody collateral.</span></p><h4 style="padding-top: 3pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Eligible Custody Solution Operators <span class="p">- The professional corporate servicing agents (e.g. Trustees) that manage the Eligible Custody Solution.</span></h4><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><u>Guidance at launch</u>: Any governance-approved Operator that is technically and operationally equipped (and licensed, as applicable) to act as manager for an orphaned SPV structure in the approved jurisdictions as well as capable to read and interpret the relevant on-chain information.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 229%;text-align: left;"><b>Banks </b>- The banks that hold deposits on behalf of the Eligible Custody Solution. <u>Guidance at launch:</u> Any bank in the approved jurisdiction(s).</p><h4 style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: left;">Custodians <span class="p">- The custodians that hold Eligible Collateral (excluding bank deposits) on behalf of the Eligible Custody Solution.</span></h4><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: left;"><u>Guidance at launch:</u> Any bank in the approved jurisdiction(s) that are operationally equipped to custody the Eligible Collateral.</p><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><h4 style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: left;">Minter Wind Down Procedures <span class="p">- The procedures a Minter is expected to follow should they be removed from the Minter list.</span></h4><p style="padding-top: 2pt;text-indent: 0pt;text-align: left;"><br/></p><p style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;"><u>Guidance at launch:</u> Minters will be given a 90 day grace period after being removed from the Minter list to fully wind down their operations (a “cooperative wind down”). This means they will have zero remaining Owed M. Should they fail to do so in this timeframe, the remainder of their off-chain value will be forfeit including the Administrative Buffer. The Administrative Buffer, in addition to remaining off-chain value in excess of Owed M, is intended to be used to finance the various off-chain actors that will be involved in the uncooperative wind down.</p><p class="s13" style="padding-top: 4pt;padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">The information contained in this document is being provided solely for informational/discussion purposes and the reader should not construe anything contained herein to be a solicitation or an offer of sale of securities. Nor should you construe the contents of this document as legal, tax or financial advice. Any potential participant in the M^0 ecosystem is urged to consult their own advisors for any legal, tax or financial questions.</p><p style="padding-top: 1pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s13" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">To the extent this document contains any forecasts, projections, goals, plans, and other forward-looking statements regarding M^0’s project, position, results, and/ or other data, you acknowledge that such forward-looking statements are based on our assumptions, estimates, outlook, and other judgments made in light of information available at the time of preparation of such statements and involve both known and unknown risks and uncertainties. Accordingly, any forecasts, plans, goals, and other statements contained herein may not be realized as described, and actual financial results, success/ failure or progress of development, and other projections may differ materially from those presented herein.</p><p style="padding-top: 1pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s13" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Neither the $M token, nor any governance tokens associated with the M^0 project, will be offered to US persons (without a valid exemption). Any token described in this document has not been registered or qualified under any state or national securities law or regulation.</p><p style="padding-top: 1pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s13" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">Participation in the purchase, use, or investment in any digital assets, tokens, or cryptocurrencies involves inherent risks, including but not limited to market volatility, regulatory changes, and technological risks. Prospective investors should conduct their own research and seek the advice of a qualified financial advisor or legal counsel before making any decisions.</p><p style="padding-top: 1pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s13" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">The team and contributors associated with this project make no representations, warranties or guarantees regarding the accuracy, completeness, or reliability of the information contained in this whitepaper or any linked materials. They disclaim any liability for any direct, indirect, or consequential losses or damages arising from reliance on this information or any errors or omissions in its content.</p><p style="padding-top: 1pt;text-indent: 0pt;text-align: left;"><br/></p><p class="s13" style="padding-left: 5pt;text-indent: 0pt;line-height: 114%;text-align: justify;">By accessing, reading, or using this whitepaper, you acknowledge and agree to the terms outlined in this disclaimer. You are solely responsible for evaluating the risks and merits associated with any actions you take related to the contents of this document.</p></body></html>