Documentation Portal
Project Home
  • Core Documentation
    • Overview
    • Whitepaper
      • Abstract
      • I. Introduction
      • II. Protocol
        • II.I Operation
          • II.I.I Generation of M
          • II.I.II Protocol Fees
          • II.I.III Cancel and Freeze
          • II.I.IV Retrieving Free Collateral
          • II.I.V The Earn Mechanism
          • II.I.VI Removing a Permissioned Actor
          • II.I.VII Example Interactions and Flows
        • II.II Governance Controlled Protocol Actors
        • II.III Governance Controlled Protocol Parameters
      • III. Governance
        • III.I Inputs
        • III.II Operation
          • III.II.I Epochs
          • III.II.II Proposals
            • III.II.II.I Standard Proposals
            • III.II.II.II POWER Threshold Proposals
            • III.II.II.III ZERO Threshold Proposals
            • III.II.II.IV Proposal Matrix
          • III.II.III Checkpoints and Voting
          • III.II.IV Proposing
          • III.II.V Inflation Mechanics
          • III.II.VI Dutch Auction
          • III.II.VII Delegation
          • III.II.VIII ZERO Claiming of Residual Value
        • III.III Governance Controlled TTG Parameters
        • III.IV Immutable TTG Parameters
        • III.V Immutable POWER Parameters
        • III.VI Immutable ZERO Parameters
      • IV. The M0 Economy
        • IV.I Minters
        • IV.II Validators
        • IV.III Earners
      • V. Off-Chain Ecosystem
        • V.I Guidance
        • V.II Off-Chain Actors and Components
    • Adopted Guidance
      • Adopted Guidance v1.30
        • 1. Description of the Adopted Guidance
          • 1.1. Purpose of the Adopted Guidance
          • 1.2. Change Process for the Adopted Guidance
        • 2. Ecosystem Description
          • 2.1. Actors
          • 2.2. Mandatory Contracts
          • 2.3. Duty of Transparency
          • 2.4. Core Operational Flows
            • 2.4.1. Update Collateral Process
            • 2.4.2. Minting M
            • 2.4.3. Retrieval of Collateral
          • 2.5. High-Risk Jurisdictions
        • 3. Eligible Collateral
          • 3.1. Criteria for Eligible Collateral
          • 3.2. Valuation Policy for Eligible Collateral
          • 3.3. Collateral Storage
          • 3.4. Approved Jurisdictions
            • 3.4.1. Bankruptcy Remoteness
            • 3.4.2. Non-Petition and Non-Seizure Provisions
            • 3.4.3. Priority of Payments and Subordination
            • 3.4.4. Regulatory Compliance
            • 3.4.5. Legal and Regulatory Framework
            • 3.4.6. Political Stability
            • 3.4.7. Dispute Resolution
            • 3.4.8. Asset Segregation
            • 3.4.9. Limited Recourse
            • 3.4.10. Investor Protection
            • 3.4.11. Operational Infrastructure
            • 3.4.12. Custody Relationship
            • 3.4.13. Audit
        • 4. SPV Operators
          • 4.1. Contact Information of Currently Approved SPV Operators
          • 4.2. Eligibility Criteria for Approved SPV Operators
          • 4.3. Obligations of SPV Operators
            • 4.3.1. Obligations in the Normal Course of Business
            • 4.3.2. Obligations Outside of the Normal Course of Business
              • 4.3.2.1. Amicable Wind Down Process
              • 4.3.2.2. Non-Amicable Wind Down Process
              • 4.3.2.3. Minter Insolvency
              • 4.3.2.4. Unauthorized Termination of Minter – SPV Operator Agreement
            • 4.3.3. Operational Obligations of SPV Operators
              • 4.3.3.1. Co-signature of the SPV for significant payments
              • 4.3.3.2. Cooperation with Validators
              • 4.3.3.3. Maintenance of Administrative Buffer
              • 4.3.3.4. No Wire Back Instructions
          • 4.4. Guidelines for Submission of Approval Requests
        • 5. Validators
          • 5.1. Contact Information of Currently Permissioned Validators
          • 5.2. Eligibility Criteria for Permissioned Validators
          • 5.3. Obligations of Validators
          • 5.4. Guidelines for Submission of Permissioning Requests
        • 6. BD Minters and Minters
          • 6.1. Contact Information of Currently Permissioned Minters
          • 6.2. Eligibility Criteria for Permissioned Minters
          • 6.3. Obligations of Minters
          • 6.4. BD Minter and Minter Compliance Requirements
          • 6.5. Guidelines for Submission of Permissioning Requests
        • Adopted Guidance PDF Version
      • Adopted Guidance v1.20 (deprecated)
        • Adopted Guidance PDF Version
    • Glossary
    • Disclosures
    • Whitepaper PDF Version
  • Technical Documentation
    • Protocol Technical Specification
      • Main Invariants
      • Variables
        • Protocol Variables Controlled by TTG
        • Protocol Variables And Definitions
        • Protocol Variables Used For Interest Accruals
      • Protocol And M Token Actors And Actions
        • Protocol Core Functions
          • Minter Gateway
            • updateCollateral
            • proposeMint
            • mintM
            • cancelMint
            • freezeMinter
            • burnM
            • proposeRetrieval
            • activateMinter
            • deactivateMinter
          • M Token
            • startEarning
            • stopEarning
            • transfer
          • Interest Calculations And Indices
            • MinterGateway.updateIndex
            • MinterGateway.currentIndex
            • MToken.updateIndex
            • MToken.currentIndex
            • activeOwedM
          • Interest Rate Models
            • Stable Earner Interest Rate Model Contract
            • Minter Interest Rate Model Contract
    • TTG Technical Specification
      • Main Invariants
      • Core Architecture
        • 1. Registrar
          • Registrar Variables and Getters
          • Registrar Core Functions
        • 2. TTG Governors
          • Matrix Of TTG Proposals
          • 2.1 Standard Governor
            • Variables And Getters
            • Governor Proposal State Transitions
            • Core Functions
            • Core Governance Proposals
          • 2.2 Emergency Governor
            • Emergency Governor Variables And Getters
            • Governor Proposal State Transitions
            • Core functions
              • propose(targets[], values[], callDatas[], description): proposalId
              • castVote(proposalId, support): weight
              • castVotes(proposalIds[], supports): weight
              • execute(targets[], values[], callDatas[], description): proposalId
              • setThresholdRatio(newThresholdRatio)
              • getProposal(proposalId)
              • state(proposalId)
            • Core Governance Proposals
          • 2.3 ZERO Governor
            • Variables And Getters
            • Core Functions
            • Core Governance Proposals
        • 3. POWER Token
          • Variables And Getters
          • POWER Token Core Functions
        • 4. ZERO Token
          • ZERO Token Core Functions
        • 5. Distribution Vault
          • Variables And Getters
          • Core Functions
    • Source Code Reference
      • Protocol
        • Protocol Contracts
          • Core Protocol Contracts
            • MToken
            • MinterGateway
          • Abstract Protocol Contracts
            • ContinuousIndexing
          • Protocol Interfaces
            • IContinuousIndexing
            • IMToken
            • IMinterGateway
            • IRateModel
            • ITTGRegistrar
          • Libs
            • ContinuousIndexingMath
            • TTGRegistrarReader
          • Rate Models
            • Contracts
              • EarnerRateModel
              • MinterRateModel
            • Interfaces
              • IEarnerRateModel
              • IMinterRateModel
      • TTG
        • TTG Contracts
          • Core TTG Contracts
            • DistributionVault
            • Registrar
            • Governors
              • EmergencyGovernor
              • StandardGovernor
              • ZeroGovernor
            • Tokens
              • PowerBootstrapToken
              • PowerToken
              • ZeroToken
          • Abstract TTG Contracts
            • ERC5805
            • Governors
              • BatchGovernor
              • ThresholdGovernor
            • Tokens
              • EpochBasedInflationaryVoteToken
              • EpochBasedVoteToken
            • Interfaces
              • IBatchGovernor
              • IERC5805
              • IERC6372
              • IEpochBasedInflationaryVoteToken
              • IEpochBasedVoteToken
              • IGovernor
              • IThresholdGovernor
          • Deployers
            • EmergencyGovernorDeployer
            • PowerTokenDeployer
            • StandardGovernorDeployer
          • TTG Interfaces
            • IDistributionVault
            • IRegistrar
            • Deployers
              • IDeployer
              • IEmergencyGovernorDeployer
              • IPowerTokenDeployer
              • IStandardGovernorDeployer
            • Governors
              • IEmergencyGovernor
              • IStandardGovernor
              • IZeroGovernor
            • Tokens
              • IPowerBootstrapToken
              • IPowerToken
              • IZeroToken
          • Libs
            • PureEpochs
      • Common
        • Contracts
          • Main
            • ContractHelper
            • ERC20Extended
            • ERC3009
            • ERC712Extended
            • StatefulERC712
          • Interfaces
            • IERC1271
            • IERC20
            • IERC20Extended
            • IERC3009
            • IERC712
            • IERC712Extended
            • IStatefulERC712
          • Libs
            • SignatureChecker
            • UIntMath
    • 🏁Audits
    • 🔛Deployments
Powered by GitBook

M0 Project

  • Home
  • Research

Legal

  • Terms & Conditions
  • Privacy Policy

Copyright 2025 M0 Foundation

On this page
  1. Core Documentation
  2. Whitepaper

I. Introduction

The core M0 protocol (which excludes periphery contracts and is hereon referred to simply as the M0 protocol) is a coordination layer for permissioned actors to generate $M.

PreviousAbstractNextII. Protocol

Last updated 1 month ago

$M 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 $M 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 stablecoin use cases, builders, 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 stablecoins.

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 turn off 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.

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 stablecoins. What we call digital cash 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.

$M is credibly neutral by design, it is by default self-custodial and fungible. Each $M is the same as every other $M and there is no ability for the protocol to discriminate against any specific holder(s). $M is stored and tracked on blockchains, and thus can be stored more securely at scale than physical cash. $M’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 $M must be held exclusively throughout a network of orphaned, bankruptcy-remote entities, which are customized to interact with the M0 protocol while meeting the formalities of the existing legal system. $M 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.

We refer to $M as raw material for value representation, and not necessarily a stablecoin in its own right, because the system relies on permissioned issuers (known as in the protocol) for generation and distribution. These should be compliant with all applicable regulations and may decide to distribute their own product, for example by wrapping the $M token in a stablecoin contract in a way that best meets their requirements. In this capacity, $M becomes a monetary building block on top of which novel products can be built.

In summary, the M0 protocol is the platform powering builders of safe, programmable, interoperable stablecoins. It 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. M0 intends to redesign the monetary vertical stack, rather than build an additional layer on top of what has ultimately become byzantine infrastructure.

Minters
Minters