Skip to content

2. Ecosystem Description

The M0 Protocol is designed to support permissioned Actors in the minting of a crypto asset called M. The minting of M requires collaboration across a set of Actors complying with a set of rules, some of which can be enforced onchain.

First and foremost, a sufficient balance of Eligible Collateral (as described in the Adopted Guidance) must be constantly identifiable and constrained for the backing of Owed M. This requires a demonstration of the existence and validity of the collateral, repeated on an ongoing basis, and executed via the updateCollateral() function call. Only if sufficient collateral balance has been updated and only if such balance is still valid within the timeframe implied by the collateral update interval can a Minter (see below) mint M or retrieve collateral.

With Eligible Collateral we refer to the types of collateral that are defined to be suitable to back M, based on the criteria listed in Criteria for Eligible Collateral. With Collateral Balance we refer to the onchain value of the Eligible Collateral available to mint M.

The sufficiency of the Collateral Balance is determined by the following Core Operating Condition:

(Collateral BalanceTotal Pending Retrievals)×Mint RatioOwed M+Proposed M(Collateral \ Balance - Total \ Pending \ Retrievals) \times Mint \ Ratio \geq Owed \ M + Proposed \ M

Subject to the following definitions:

  • Total Pending Retrievals indicate the total amount of collateral a Minter is trying to retrieve from SPV by submitting a Retrieval Request to the protocol via the proposeRetrieval() function.
  • Retrieval Request is the process by which a Minter submits a request to the Protocol to retrieve a specified amount of M. The Protocol verifies that the Core Operating Condition would not be breached by the retrieval of this amount of M, based on the latest Collateral Balance.
  • Mint Ratio refers to the fraction of a Minter’s Collateral Balance that can be used to generate M, which effectively controls the leverage of a Minter and the over-collateralization of M.
  • Owed M describes the amount of M generated by the Minter, plus the Minter's Accumulated Minter Rate and Penalty, still outstanding — i.e. not burned.
  • Proposed M is the amount of new M that a Minter is requesting to mint.

The Core Operating Condition intends to guarantee that no M can be minted and/or no collateral can be retrieved unless there is sufficient Collateral Balance.

We define Burn (or Burned M) as a successful call to the burn() function, which specifies a Minter’s address. Such operation effectively reduces that Minter’s Owed M balance by the amount of burned M.

2.1. Actors

Actors are relevant participants (roles and entities) within the M0 ecosystem. Only a subset of the Actors (so-called Permissioned Actors) are explicitly approved through Governance, while the rest is explicitly, albeit more loosely, identified as part of the Adopted Guidance.

The following diagram displays a schematic view of the Actors within the M0 ecosystem and how they connect to external parties (i.e. parties whose practices are not covered by the Adopted Guidance) and contracts that need to be in place between Actors. The list of Actors is defined below.

Noble

Minter: The Minter is an entity considered orphaned from the risk of exogenous insolvency, operated by a separate entity responsible for business operations that is in place to further distance the Minter from bankruptcy issues (referred to here as the BD Minter). The Minter owns the private key associated with a public address that is permissioned by Governance to interact with a minting smart contract in order to mint M against a sufficient Collateral Balance, represented by Notes which are issued by the SPV (see below for details) and held on the Minter’s balance sheet.

The Minter is not allowed to conduct any other business or take on any other liabilities except the M balance it owes to the Protocol and the contractually defined liabilities vis-à-vis the BD Minter.

BD Minter: The BD Minter is the business development entity that performs the operational obligations of the Minter and contractually absorbs any and all potential liabilities arising from agreements with service providers of the Minter. While the suggested exclusive relationship between the Minter and the BD Minter should not be overly prescriptive, we emphasize that this provision aims to maintain liability segregation, keeping all non-minting responsibilities away from the Minter.

SPV Operator: The SPV Operator manages the portfolio of collateral in the SPV on behalf of the SPV but for the benefit of a Minter’s business operations. The SPV Operator also acts as selling agent in the context of a wind down (as described in Obligations Outside of the Normal Course of Business) and can even wind down a Minter in cases where the Minter is unable or unwilling to comply with the Protocol rules.

SPV: The SPV is the orphaned and insolvency-remote legal owner of the Eligible Collateral, available financial resources, or of any other asset which is managed by the SPV Operator.

Validator: The Validator independently verifies that the amount of collateral to be published onchain appropriately exists and is compliant with appropriate eligibility criteria. We expect the role of Validator to evolve jointly with the evolution of the nature of the underlying available collateral (e.g. appropriate tokenization).

2.2. Mandatory Contracts

Mandatory Contracts are contracts that are required to be in place between the Actors to ensure maximum protection for the collateral as well as maximum degree of enforceability of the Protocol rules. The execution of these contracts should improve robustness against collusion among malicious Actors.

As with many aspects outlined in the Adopted Guidance, the following set of contracts is intended for scenarios where no robust onchain equivalent exists. With advancements in tokenization efforts for instruments deemed Eligible Collateral, we anticipate that some of these contracts may become redundant in future updates of the Adopted Guidance.

Given that Governance participants and holders of M are likely not contractual parties to any of the Actors, the Mandatory Contracts are designed to ensure alignment among all Actors involved in the legal and operational framework, ensuring compliance with Protocol rules.

Minter Operating Memorandum: The Minter is an entity with a contractually-limited purpose to hold Notes and mint M. Therefore, it is not allowed to e.g. hire personnel and build operational resources or directly enter into distribution agreements, as well as sale/ purchase agreement, with buyers of M. Notes are defined as pass-through and look-through limited recourse notes issued by the SPV in one or more tranches in accordance with the Terms and Conditions of the Note itself.

The Minter Operating Memorandum should regulate that:

  • The BD Minter provides sufficient operational resources to the Minter for its operations, given that the Minter should not have operational staff.
  • The BD Minter and Minter should have appropriate liability segregation in order to limit eventual spillovers between general liabilities and those solely related to the Protocol with regards to the requirement to back the Owed M by sufficient Collateral Balance.

Minter-SPV Operator Agreement: The relationship between the Minter and the SPV Operator is of core importance since the intentional split between an entity that mints M and another entity that manages the collateral creates a field of tension between collaboration, control and potential enforcement. The Minter-SPV Operator Agreement should regulate this relationship. It differentiates between two scenarios:

  • a) Normal Course of Business
  • b) Outside Normal Course of Business

While the Normal Course of Business regulates the obligations of the SPV Operator to maintain the Eligible Collateral balance, the Outside Normal Course of Business ensures that the SPV Operator is allowed to perform actions against the Minter to enforce the Protocol rules in case the Minter is not compliant.

This agreement is crucial for the protection of the collateral.

Minter-Validator Agreement (where required): The Validator requires broad ongoing visibility of the collateral storage.

With Collateral Storage we identify the collection of venues such as Securities and Deposit Accounts, as well as digital asset accounts, held by the SPV.

The services provided by a Validator to the Minter (and, indirectly, the ecosystem) need to be well-defined to ensure the smooth operation of the Protocol. Therefore, this agreement, where required, should regulate all transparency, access and confidentiality aspects between the parties, as well as the service of validation in compliance with the Protocol rules.

Terms and Conditions (and Subscription Agreement) of the Note: The Terms and Conditions of the Note (as well as Subscription Agreement) represent the economic link between the collateral and the Minter entity. Their enforceability and protective clauses have an obvious direct impact on the quality and availability of the collateral for the purpose of the Protocol. Additionally, these documents need to reflect the scenarios where the SPV Operator winds down a Minter balance without the Minter’s collaboration. This requires certain rights of a party (the SPV Operator) which is not the noteholder (Minter) that need to be mandatorily reflected in the Terms and Conditions of the Note itself.

SPV Operating Memorandum: Every Actor should practically be replaceable; in particular any operation of the SPV should be highly standardized. This is what an appropriate SPV Operating Memorandum should ensure. As a crucial point this document also regulates the transfer restrictions of funds transferred out of the Collateral Storage.

In case any of the Mandatory Contracts defined here are modified as part of the change process, all parties shall work to amend the respective contracts as soon as practically feasible.

Parties are not expected to perform changes on their Mandatory Contracts (or similar) that are not made in the spirit of the Adopted Guidance. Parties are expected to remedy such misaligned clauses by replacing them as soon as practical and without undue delay.

2.3. Duty of Transparency

To the extent reasonable, and observing proper confidentiality practices, all Actors within the M0 ecosystem are encouraged to abide by a duty of transparency and candor toward Governance. The Actors will enter into Mandatory Contracts with each other and are expected to timely and appropriately make the latest versions of such agreements available to Governance and other interested parties, ideally in the public domain, but certainly upon request.

2.4. Core Operational Flows

While the Protocol is immutable and the direct impact of Governance on the Protocol’s behavior is limited to the Governance Controlled Parameters (the set of variables that can be modified by Governance votes and that have an impact on the Protocol's functioning) and the permissioning of certain Actors, calls of Protocol functions should go hand in hand with offchain processes that the Actors must comply with. The following processes are, at the current state of technology and collateral eligibility, to be considered binding for all Actors.

2.4.1. Update Collateral Process

The updateCollateral() function (Update Collateral) needs to be called once per Update Collateral Interval.

Update Collateral Interval: In accordance with Protocol specifications, the period between which Update Collateral must be called by a Minter. If Minters do not call Update Collateral within this amount of time after their previous call, their onchain Collateral Value is assumed to be 0 and they will incur a penalty rate on the next update. This protocol parameter is alterable with a Standard Proposal.

The Penalty Rate is defined as 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.

Failure to do so will result in the Collateral Balance being set to 0 and the application of a respective Penalty.

Some key financial definitions are outlined below:

  • Deposit Equivalents are amounts, denominated in the Reference Currency, held in either Deposit Accounts or in the form of so-called stablecoins (including M) in wallets.
  • Deposit Account is the demand deposit account held by the SPV with demand deposit providers.
  • Custody Account is the securities account or digital asset account held by the SPV with custody providers.
  • The Reference Currency throughout this document is USD (United States Dollar).

An example collateral update flow, assuming a look-through validation of the collateral, is shown in the picture below:

Noble
  1. The Minter purchases Notes from the SPV with Deposit Equivalents.
  2. The SPV Operator on behalf of the SPV will perform the collateralization process.
  3. Minter sends a Validation Request (see below) which contains the amount it would like to update onchain to the Validator.
  4. Validator verifies the existence of the Collateral (e.g. via its read access to the depository account or, in case of eligible tokenized collateral, via observation of distributed ledger entries), verifies the compliance with the eligibility criteria and, potentially, verifies the implementation of Mandatory Contracts.
  5. If all checks have been successful, the Validator sends a Signature to the Minter.
  6. With this Signature the Minter can call the updateCollateral() function.

Validation Request: A call from the Minter to the Validator where the Minter requests a Signature for either updating its Collateral Balance or for removing a RetrieveID from the Protocol.

Steps 3-6 have to be completed at least once per Update Collateral Interval. Step 2 has to be completed whenever new funds are transferred to the Collateral Storage or whenever collateral matures thus liquidates.

2.4.2. Minting M

The mint process of M can be triggered by the Minter at any time as long as the Collateral Balance is sufficient and the Core Operating Condition satisfied.

Noble
  1. The Minter can call the proposeMint() function at any time, indicating the amount it wants to mint. The Protocol will support the verification of the Core Operating Condition following a successful mint. The transaction will fail if the condition is not satisfied. As a reminder, during the Mint Delay time any Validator can cancel the mint.
  2. Once the Mint Delay has elapsed, the Minter can execute the mint and the Protocol will again check the Core Operating Condition. If the mint is successful, the minted M will be transferred to the wallet indicated in the mint request.

2.4.3. Retrieval of Collateral

As defined in the Whitepaper, and as a reminder for the reader, collateral can generally only be retrieved (at least during the Normal Course of Business — see below) if the Core Operating Condition remains satisfied following a successful retrieval. Given that the retrieval flow is the main way in which funds can leave the Collateral Storage, the process should absolutely come with strict rules. We are expecting Governance to holistically assess that those rules remain satisfied by any alternative implementation proposed by a prospective Minter. An example of such a flow is described in the chart below:

Noble
  1. The Minter requests a retrieval by calling the proposeRetrieval() function with the amount it wishes to retrieve.
  2. If the Core Operating Condition remains satisfied after the retrieval the call succeeds and a RetrievalID is generated and stored in the Protocol. For as long as the RetrievalID is not closed the Protocol will subtract the requested amount from the Collateral Balance.
  3. The Minter can now request the retrieval with the SPV Operator.
  4. The SPV Operator will now validate the existence of the Retrieval Request in the Protocol.
  5. If the existence of a corresponding Retrieval Request has been confirmed, the SPV Operator can initiate the liquidation of the equivalent collateral and transfer the funds back to the Minter.
  6. Once the transfer has been executed the Minter can request a Signature from the Validator for the removal of the RetrievalID.
  7. The Validator confirms via appropriately provided access to the Collateral Storage that the transfer was executed.
  8. If the check was successful, the Validator provides a Signature for the removal of the RetrievalID.
  9. The Minter can now call the updateCollateral() function and pass on the RetrievalID it wishes to remove together with the Signature. The RetrievalID will be removed, and the respective amount will no longer be subtracted from the Minter’s Collateral Balance.

2.5. High-Risk Jurisdictions

For the benefit of this document, the countries in the following lists are considered to be high-risk jurisdictions.