0xb024…a016

All memos sent from and to 0xb024…a016.

0x80c6a512…5990sent to0xb024ac5a…a0162026-02-03·#24,372,884·0x04414db3…930647

# Add Saturn (USDat) as an Approved Earner # Add Saturn (USDat) as an Approved Earner ## About Saturn is building a stablecoin and yield-bearing RWA generating 11% via MicroStrategy's STRC. Unlike DeFi yields that compress at scale or opaque RWA products, Saturn maintains 11% yield at billions in AUM with transparent, liquid backing. USDat is powered by M0 and designed to support liquidity for the larger protocol. - **Extension Name**: USDat - **Targeted Chains**: Ethereum (initial deployment), with the goal to expand to EVM chains - **Extension Ticker**: USDat Learn more about Saturn at [https://www.usdat.xyz/](https://www.usdat.xyz/) ## Yield Distribution This uses the JMI extension. All yield earned from underlying reserves will be directed back to the Saturn Corporate Treasury to provide incentives to users of the protocol and revenue for the project. ## Use Cases USDat will serve two primary roles in the Saturn Protocol: 1. **Liquidity** Saturn will use USDat to help build liquidity for the larger protocol. We want to build DEX pools, lending markets and more that are USDat/sUSDat. As we scale we can use USDat to support instant liquidity. 2. **Checking account** USDat will be the entry and exit point for users in our protocol. Over time we want to build the savings account and checking account on top of USDat and STRC. ## Roadmap for Inflows Several upcoming milestones are expected to drive significant liquidity and adoption: - **Private Beta Launch** We will launch a private beta with $25M in initial protocol TVL, onboarding a limited, curated set of users to validate product performance and liquidity mechanics. - **Public Launch & DeFi Integrations** Following the private beta, we will roll out a public launch supported by multiple DeFi integrations targeted for the first two weeks: - Curve Pool Integration – Support for a Curve pool to enable deep liquidity and efficient entry/exit for USDat. This also allows non-onboarded users to acquire and hold USDat, expanding access to the broader protocol. - Pendle Markets – Launch of USDat and sUSDat markets on Pendle, enabling yield separation and attracting yield-focused capital. - Money Markets & Curators – There is active borrow demand for Saturn assets, and we are in discussions with Morpho and other curators to list USDat-based markets. - **Incentives & Rewards** We will deploy targeted incentive and rewards campaigns to bootstrap early liquidity and reward initial adopters. - **Cross-Chain Expansion** Expansion to high-performance chains across and beyond the EVM ecosystem, including SVM, Starknet, and additional networks, to unlock new liquidity sources and distribution channels. ## Security & Compliance Mint/Redeem of USDat is KYCed and only available to onboarded users to the Saturn protocol. We support blacklisting addresses and are working to integrate with Chainalysis, TRM or Predicate to enforce compliance with OFAC and sanctions. --- [Discussion](https://docs.google.com/document/d/1UsNp8Hxi4LAo5iAnbhcMuf9Z_Pwmb28BbYJbCaj5xwk/edit?usp=sharing)

0x80ea37a9…c0d6sent to0xb024ac5a…a0162026-02-03·#24,372,871·0x47fc56f0…5aca3a

# Update eligible collateral criteria to include Franklin OnChain U.S. Government Money Fund (FOBXX) ### Proposal This present proposal recommends the inclusion of Franklin OnChain U.S. Government Money Fund (FOBXX) product as one of the explicitly approved so-called wrappers of United States Treasury Bills to be deemed Eligible Collateral as per section 3.1, and valued in accordance to section 3.2 in the Adopted Governance — i.e. without any additional haircuts given no additional risk overlay of the wrapping technology. The Franklin OnChain U.S. Government Money Fund (FOBXX) was analyzed in detail by several teams in the M0 ecosystem, including members of M0 Labs and the M0 Foundation. After thorough diligence, the product is being recommended to distributed governance as suitable for the ecosystem. For more information on FOBXX, see [https://www.franklintempleton.com/investments/options/money-market-funds/products/29386/SINGLCLASS/franklin-on-chain-u-s-government-money-fund/FOBXX](https://www.franklintempleton.com/investments/options/money-market-funds/products/29386/SINGLCLASS/franklin-on-chain-u-s-government-money-fund/FOBXX) . For any questions on the due diligence and findings, please contact [joao.reginatto@m0.org](mailto:joao.reginatto@m0.org). ### Change #1 #### Section 3.1.1. Criteria for the Eligibility of Assets **Old**: ... > **vii.** Any version of items (i), (ii), (iii), (vi) in tokenized form, provided that such versions comply with all applicable laws and regulations - subject to specific definition of the financial product in scope. **a.** List of approved products: (1) Superstate Short Duration US Government Securities Fund (commonly referred to as USTB); (2) BlackRock USD Institutional Digital Liquidity Fund (commonly referred to as BUIDL). **New**: ... > **vii.** Any version of items (i), (ii), (iii), (vi) in tokenized form, provided that such versions comply with all applicable laws and regulations - subject to specific definition of the financial product in scope. **a.** List of approved products: (1) Superstate Short Duration US Government Securities Fund (commonly referred to as USTB); (2) BlackRock USD Institutional Digital Liquidity Fund (commonly referred to as BUIDL); (3) Franklin OnChain U.S. Government Money Fund (commonly referred to as FOBXX). ---

0x80ea37a9…c0d6sent to0xb024ac5a…a0162026-02-03·#24,372,843·0xd2a6be5f…1be416

# Update eligible collateral criteria to include WisdomTree Treasury Money Market Digital Fund (WTGXX) ### Proposal This present proposal recommends the inclusion of WisdomTree Treasury Money Market Digital Fund (WTGXX) product as one of the explicitly approved so-called wrappers of United States Treasury Bills to be deemed Eligible Collateral as per section 3.1, and valued in accordance to section 3.2 in the Adopted Governance — i.e. without any additional haircuts given no additional risk overlay of the wrapping technology. The WisdomTree Treasury Money Market Digital Fund (WTGXX) was analyzed in detail by several teams in the M0 ecosystem, including members of M0 Labs and the M0 Foundation. After thorough diligence, the product is being recommended to distributed governance as suitable for the ecosystem. For more information on WTGXX, see [https://www.wisdomtreeconnect.com/digital-funds/money-market/wtgxx](https://www.wisdomtreeconnect.com/digital-funds/money-market/wtgxx) . For any questions on the due diligence and findings, please contact [joao.reginatto@m0.org](mailto:joao.reginatto@m0.org). ### Change #1 #### Section 3.1.1. Criteria for the Eligibility of Assets **Old**: ... > **vii.** Any version of items (i), (ii), (iii), (vi) in tokenized form, provided that such versions comply with all applicable laws and regulations - subject to specific definition of the financial product in scope. **a.** List of approved products: (1) Superstate Short Duration US Government Securities Fund (commonly referred to as USTB); (2) BlackRock USD Institutional Digital Liquidity Fund (commonly referred to as BUIDL). **New**: ... > **vii.** Any version of items (i), (ii), (iii), (vi) in tokenized form, provided that such versions comply with all applicable laws and regulations - subject to specific definition of the financial product in scope. **a.** List of approved products: (1) Superstate Short Duration US Government Securities Fund (commonly referred to as USTB); (2) BlackRock USD Institutional Digital Liquidity Fund (commonly referred to as BUIDL); (3) WisdomTree Treasury Money Market Digital Fund (commonly referred to as WTGXX). ---

0xa34da86c…24fbsent to0xb024ac5a…a0162026-02-02·#24,371,321·0xc97a24d0…60f94d

# Add Nexus U.S. Dollar (USDX) to Earner List ## Description USDX is a fully U.S. Dollar-backed stablecoin designed to serve as the primary settlement and accounting dollar for a specialized financial exchange and application ecosystem on Nexus Layer 1. Its design creates structural, non-speculative demand: USDX balances accumulate naturally through trading activity, margin, settlement, and application treasuries rather than short-term incentive campaigns. ### Extension Details - **Extension Name:** Nexus U.S. Dollar - **Ticker:** USDX - **Initial deployments:** Ethereum Mainnet, Nexus Mainnet - **USDX** is: - A dollar-denominated stablecoin fully backed by U.S. dollar assets - Issued and redeemed via the M0 reserve infrastructure - Designed for predictable value, high liquidity, and institutional compatibility USDX uses the JMI (Just Mint It) extension, a fork of the MYieldToOne architecture. All yield accrues to a single Yield Recipient wallet controlled by Nexus Foundation, which we will distribute to users through the Global Yield Distribution System (see below). ## Roadmap for Adoption USDX is designed around the following properties: ### A. Structural Demand USDX is the default dollar inside the Nexus ecosystem, and the Nexus Exchange: - Trading collateral and margin - PnL, fees, and funding flows - Liquidation and insurance buffers - Application treasury and vault accounting As activity grows across the Nexus Exchange (a perpetual futures DEX) and Layer 1, USDX balances grow mechanically. All liquidity in the Exchange will be denominated in USDX. ### B. Cooperative Distribution Model USDX does not compete with existing stablecoins at the edges: - USDC, USDT, and other stablecoins remain on/off-ramps and liquidity rails - USDX becomes the internal unit after capital enters into Nexus Exchange This approach reduces fragmentation and allows USDX to absorb and retain flows from all kinds of users, rather than fight for initial distribution. ### C. Clear Adoption Strategy Nexus has designed a protocol-native adoption strategy to accelerate USDX usage across applications: A builder flywheel powered by reserve yield. The **Global Yield Distribution System (GYDS)** makes USDX adoption economically compelling for apps: - GYDS allocates a portion of Nexus’ realized reserve yield to applications that host and retain USDX balances from users - apps that retain more USDX TVL from their users earn more USDX yield - the system is designed to reward user and TVL retention over spikes The system aligns application incentives with USDX adoption through an automatic system, supporting durable TVL growth driven by real usage rather than promotional activity. ### D. Verifiable Finance and M0 Nexus is actively considering ways to integrate zero-knowledge and verifiability to strengthen the entire M0 ecosystem, leading by example with USDX. We will be exploring a proof of reserves system with select issuers. ## Security and Compliance * USDX uses M0's standard JMI extension architecture with zero modifications to the core contract logic. The JMI framework has been audited as part of M0's core infrastructure. * The USDX contract includes freeze functionality for AML/sanctions compliance. We maintain the ability to freeze addresses as required by regulatory obligations. ---

0x91039422…23fbsent to0xb024ac5a…a0162026-02-02·#24,371,059·0xe8e6bb51…b59ea9

# Add 0G USD (0GUSD) as an Approved Earner About 0GUSD is a yield-bearing, fully compliant stablecoin powered by M0, designed as the native dollar currency for the 0G blockchain ecosystem. As an EVM-compatible chain purpose-built for AI and data-intensive applications, 0G requires a robust, scalable stablecoin to serve as the foundational settlement layer for its decentralized data economy. Learn more about 0G at https://0g.ai Extension Name: 0G USD Extension Ticker: 0GUSD Targeted Chains: 0G (primary deployment), with cross-chain interoperability to: Ethereum Arbitrum Base Optimism Yield Distribution 0GUSD will use the extension. All yield earned from underlying reserves will be directed back to the Questflow ecosystem treasury to provide incentives to agent builders. Use Cases 0GUSD will serve three primary roles within the 0G ecosystem: Native stablecoin for AI and Data Marketplace transactions 0G is architected as a modular blockchain optimized for AI workloads and decentralized data availability. 0GUSD serves as the default settlement currency for: Purchasing data availability and storage services Paying for AI model inference and compute resources Settling transactions between data providers and consumers Rewarding node operators and data contributors Core DeFi primitive across 0G's financial infrastructure As the native M0-backed stablecoin, 0GUSD will anchor DeFi activity on 0G: Primary stablecoin pair for decentralized exchanges and AMMs Collateral and borrowing asset in lending protocols Stable unit of account for derivatives and perpetuals Yield-bearing savings vehicle for ecosystem participants Cross-chain settlement and liquidity unification 0GUSD enables seamless value transfer between 0G and the broader EVM ecosystem: Unified liquidity layer across 0G and major L2s Bridge settlement currency for cross-chain data and AI service payments Interoperable stablecoin for multi-chain dApps building on 0G's data layer Roadmap for Inflows Several upcoming milestones are expected to drive significant liquidity and adoption: 0G mainnet launch integration – Native deployment of 0GUSD coinciding with 0G mainnet, positioning it as the default stablecoin from genesis with deep protocol-level integrations. Data marketplace activation – As 0G's decentralized data marketplace scales, 0GUSD becomes the required settlement token for data availability purchases, storage fees, and provider payouts. DeFi ecosystem grants – Incentive programs for DEXs, lending protocols, and yield aggregators that integrate 0GUSD as a core trading pair and collateral asset. Cross-chain bridge deployments – Native bridge support to Ethereum, Arbitrum, Base, Optimism, and Polygon, enabling unified 0GUSD liquidity for applications leveraging 0G's data layer from other chains. AI agent and compute integrations – Partnerships with AI infrastructure providers and agent frameworks to adopt 0GUSD as the payment standard for on-chain AI services built on 0G. Security & Compliance 0GUSD will use the Predicate authorized freezer across all chains that 0GUSD is present on to enforce compliance with OFAC and sanctions. The 0G Foundation maintains operational oversight of compliance parameters in coordination with M0's governance framework. ---

0xdc010abe…e771sent to0xb024ac5a…a0162026-02-02·#24,369,888·0x660ff276…821902

# Update Penalty Rate to 0% The MAP (Monetary Adaptation and Policy) Committee is proposing to reduce the Penalty Rate from 1 bp to 0. The Penalty Rate applies when a Minter fails to meet defined operational obligations, such as timely collateral reporting or remaining within permitted debt limits. As the M0 network has scaled materially in total value, operational maturity and number of minters, a non-zero Penalty Rate now imposes a disproportionate economic impact relative to the operational issues it is intended to address. Setting the Penalty Rate to 0 bps acknowledges the network’s growth and operational maturity, and supports a shift toward more precise and effective governance tools as the ecosystem continues to scale. ---

0x0b6f330b…34a2sent to0xb024ac5a…a0162026-01-30·#24,350,893·0xd6c277d7…b07979

# Add KarsaUSD (kUSD) Extension to Earner List # Add KarsaUSD (kUSD) Extension to Earner List ## Description KarsaUSD (kUSD) is an M0-backed stablecoin powering Karsa, a stablecoin neobank for emerging markets. Karsa provides financial services to underbanked populations in emerging markets, including US virtual accounts, crypto on/off-ramping, and debit cards. We're building the infrastructure for borderless money movement. - Website: [gokarsa.com](https://gokarsa.com/) - LinkedIn: [linkedin.com/company/karsa](https://www.linkedin.com/company/karsa) - X: [x.com/go_karsa](https://x.com/go_karsa) ## Extension Details - **Extension Name:** KarsaUSD - **Ticker:** kUSD - **Targeted Chain:** Base ## Yield Distribution KarsaUSD uses the JMI (Just Mint It) extension, a fork of the MYieldToOne architecture. All yield accrues to a single Yield Recipient wallet controlled by Karsa, which we will distribute to users. - **Yield savings:** Users earn yield on their kUSD holdings distributed by Karsa - **Cross-border payments:** kUSD serves as the settlement layer for Karsa's remittance and payment products - **Card funding:** Users can fund their Karsa debit cards with yield-bearing kUSD ## Security / Compliance - KarsaUSD uses M0's standard JMI extension architecture with zero modifications to the core contract logic. The JMI framework has been audited as part of M0's core infrastructure. - The kUSD contract includes freeze functionality for AML/sanctions compliance. We maintain the ability to freeze addresses as required by regulatory obligations. ## Benefits to M0 Ecosystem - **New market expansion:** Karsa operates in emerging markets where M0 currently has limited presence, bringing new users and TVL to the ecosystem - **Real-world utility:** kUSD will be actively used for payments, remittances, and card transactions - not just held for yield - **Increased demand:** Every kUSD minted drives inflows through the SwapFacility --- We are requesting that KarsaUSD (kUSD) be added as an approved earner. ---

0xdc010abe…e771sent to0xb024ac5a…a0162026-01-28·#24,336,244·0xbd6fe280…f494bb

# Add M0 Labs Engineering Reserved 'EarnerPhi' Address as an Earner M0 Labs Engineering Team would like to add the pre-determined address 0x0bCA330fe1500CF785e2321A553Cd66f98bdC3DA to the Earners list. This address will be used in the future for deployment of high priority Earner Contract like Extension or Bridging infrastructure that requires yield accrual and distribution. Earner Contract will be deployed by the wallet with the following address: 0xF2f1ACbe0BA726fEE8d75f3E32900526874740BB. Earner Contract relies on the ERC-1967 Proxy pattern for upgradability and the CREATEX Factory contract will be used to deploy the Earner contract via CREATE3 at the following pre-deterministic address: 0x0bCA330fe1500CF785e2321A553Cd66f98bdC3DA. This address can be verified by calling CREATEX function computeCreate3Address(bytes32 salt) with this salt: 0x4a8fd2453c4bbb0209265b165be2403c247757489bb9a35cae722db2b5b8d6cc. This salt is computed by concatenating the deployer address with the EarnerPhi contract name and is hashed with the deployer address to guard against deployment by another wallet. The Solidity code computing this guarded salt can be found here.

0xdc010abe…e771sent to0xb024ac5a…a0162026-01-28·#24,336,244·0xcf5533a0…27e89d

# Add M0 Labs Engineering Reserved 'EarnerUpsilon' Address as an Earner M0 Labs Engineering Team would like to add the pre-determined address 0x19A6c761d485593D24B21d51d6f5A0fEFd074223 to the Earners list. This address will be used in the future for deployment of high priority Earner Contract like Extension or Bridging infrastructure that requires yield accrual and distribution. Earner Contract will be deployed by the wallet with the following address: 0xF2f1ACbe0BA726fEE8d75f3E32900526874740BB. Earner Contract relies on the ERC-1967 Proxy pattern for upgradability and the CREATEX Factory contract will be used to deploy the Earner contract via CREATE3 at the following pre-deterministic address: 0x19A6c761d485593D24B21d51d6f5A0fEFd074223. This address can be verified by calling CREATEX function computeCreate3Address(bytes32 salt) with this salt: 0x6665997becab1b96c4cd7a51d58b168a207e8406ebd5c3aabfa9d5edfe93d4ea. This salt is computed by concatenating the deployer address with the EarnerUpsilon contract name and is hashed with the deployer address to guard against deployment by another wallet. The Solidity code computing this guarded salt can be found here.

0xdc010abe…e771sent to0xb024ac5a…a0162026-01-28·#24,336,244·0xa39c5114…679202

# Add M0 Labs Engineering Reserved 'EarnerTau' Address as an Earner M0 Labs Engineering Team would like to add the pre-determined address 0x3109Eb1e8BB869d2DDa02e6c10b4155e77c9bd82 to the Earners list. This address will be used in the future for deployment of high priority Earner Contract like Extension or Bridging infrastructure that requires yield accrual and distribution. Earner Contract will be deployed by the wallet with the following address: 0xF2f1ACbe0BA726fEE8d75f3E32900526874740BB. Earner Contract relies on the ERC-1967 Proxy pattern for upgradability and the CREATEX Factory contract will be used to deploy the Earner contract via CREATE3 at the following pre-deterministic address: 0x3109Eb1e8BB869d2DDa02e6c10b4155e77c9bd82. This address can be verified by calling CREATEX function computeCreate3Address(bytes32 salt) with this salt: 0xc3369ba305b95630fe978d8a7e40dd160906b52fef7df5d4a7b084106e344c95. This salt is computed by concatenating the deployer address with the EarnerTau contract name and is hashed with the deployer address to guard against deployment by another wallet. The Solidity code computing this guarded salt can be found here.

0xdc010abe…e771sent to0xb024ac5a…a0162026-01-28·#24,336,244·0xe460be5c…a8f63a

# Add M0 Labs Engineering Reserved 'EarnerSigma' Address as an Earner M0 Labs Engineering Team would like to add the pre-determined address 0xe39BB732e95aD78C386884e3c4EEDc29e16862e1 to the Earners list. This address will be used in the future for deployment of high priority Earner Contract like Extension or Bridging infrastructure that requires yield accrual and distribution. Earner Contract will be deployed by the wallet with the following address: 0xF2f1ACbe0BA726fEE8d75f3E32900526874740BB. Earner Contract relies on the ERC-1967 Proxy pattern for upgradability and the CREATEX Factory contract will be used to deploy the Earner contract via CREATE3 at the following pre-deterministic address: 0xe39BB732e95aD78C386884e3c4EEDc29e16862e1. This address can be verified by calling CREATEX function computeCreate3Address(bytes32 salt) with this salt: 0xc36a5b6f45da39666048a1ec775ca8ce6b2da29a4a51f7d93a185679f3232133. This salt is computed by concatenating the deployer address with the EarnerSigma contract name and is hashed with the deployer address to guard against deployment by another wallet. The Solidity code computing this guarded salt can be found here.

0xdc010abe…e771sent to0xb024ac5a…a0162026-01-28·#24,336,244·0xeca3239e…2c7aec

# Add M0 Labs Engineering Reserved 'EarnerRho' Address as an Earner M0 Labs Engineering Team would like to add the pre-determined address 0x4B468e822bF9446E1125F5082a50Ee02CaA7E76A to the Earners list. This address will be used in the future for deployment of high priority Earner Contract like Extension or Bridging infrastructure that requires yield accrual and distribution. Earner Contract will be deployed by the wallet with the following address: 0xF2f1ACbe0BA726fEE8d75f3E32900526874740BB. Earner Contract relies on the ERC-1967 Proxy pattern for upgradability and the CREATEX Factory contract will be used to deploy the Earner contract via CREATE3 at the following pre-deterministic address: 0x4B468e822bF9446E1125F5082a50Ee02CaA7E76A. This address can be verified by calling CREATEX function computeCreate3Address(bytes32 salt) with this salt: 0x9672ae7fecaa1d071c6d4a56480faeab43813f60a58fa15b0cfe3aab407cb49b. This salt is computed by concatenating the deployer address with the EarnerRho contract name and is hashed with the deployer address to guard against deployment by another wallet. The Solidity code computing this guarded salt can be found here.

0xdc010abe…e771sent to0xb024ac5a…a0162026-01-28·#24,336,244·0xec5582cd…328c15

# Add M0 Labs Engineering Reserved 'EarnerPi' Address as an Earner M0 Labs Engineering Team would like to add the pre-determined address 0x27cC239F6e4Ac3502B53599e1B780cc1D785762b to the Earners list. This address will be used in the future for deployment of high priority Earner Contract like Extension or Bridging infrastructure that requires yield accrual and distribution. Earner Contract will be deployed by the wallet with the following address: 0xF2f1ACbe0BA726fEE8d75f3E32900526874740BB. Earner Contract relies on the ERC-1967 Proxy pattern for upgradability and the CREATEX Factory contract will be used to deploy the Earner contract via CREATE3 at the following pre-deterministic address: 0x27cC239F6e4Ac3502B53599e1B780cc1D785762b. This address can be verified by calling CREATEX function computeCreate3Address(bytes32 salt) with this salt: 0xf7c7f69f3c00836a4a725d1d549b19b745341ae1a88e9e7cf81a6cc4df6865d2. This salt is computed by concatenating the deployer address with the EarnerPi contract name and is hashed with the deployer address to guard against deployment by another wallet. The Solidity code computing this guarded salt can be found here.

0xdc010abe…e771sent to0xb024ac5a…a0162026-01-28·#24,336,243·0x17617f6a…771d0b

# Add M0 Labs Engineering Reserved 'EarnerOmicron' Address as an Earner M0 Labs Engineering Team would like to add the pre-determined address 0xEAaCe3B58657BfB8D3DaFd36c63208d3032AbAfB to the Earners list. This address will be used in the future for deployment of high priority Earner Contract like Extension or Bridging infrastructure that requires yield accrual and distribution. Earner Contract will be deployed by the wallet with the following address: 0xF2f1ACbe0BA726fEE8d75f3E32900526874740BB. Earner Contract relies on the ERC-1967 Proxy pattern for upgradability and the CREATEX Factory contract will be used to deploy the Earner contract via CREATE3 at the following pre-deterministic address: 0xEAaCe3B58657BfB8D3DaFd36c63208d3032AbAfB. This address can be verified by calling CREATEX function computeCreate3Address(bytes32 salt) with this salt: 0x70bfbecb2b811d9b2ba9297871df4a5152eb338f4acc939606b7a48a78d7d011. This salt is computed by concatenating the deployer address with the EarnerOmicron contract name and is hashed with the deployer address to guard against deployment by another wallet. The Solidity code computing this guarded salt can be found here.

0xdc010abe…e771sent to0xb024ac5a…a0162026-01-28·#24,336,243·0x99d51ee7…c30c7b

# Add M0 Labs Engineering Reserved 'EarnerXi' Address as an Earner M0 Labs Engineering Team would like to add the pre-determined address 0x855619eC9D7A6485079d47f290E7168E18BCc9d3 to the Earners list. This address will be used in the future for deployment of high priority Earner Contract like Extension or Bridging infrastructure that requires yield accrual and distribution. Earner Contract will be deployed by the wallet with the following address: 0xF2f1ACbe0BA726fEE8d75f3E32900526874740BB. Earner Contract relies on the ERC-1967 Proxy pattern for upgradability and the CREATEX Factory contract will be used to deploy the Earner contract via CREATE3 at the following pre-deterministic address: 0x855619eC9D7A6485079d47f290E7168E18BCc9d3. This address can be verified by calling CREATEX function computeCreate3Address(bytes32 salt) with this salt: 0x9ab6ab36339002ed0ff30ff2257766ffdb6c221c036523c5aaa064a1b2de557d. This salt is computed by concatenating the deployer address with the EarnerXi contract name and is hashed with the deployer address to guard against deployment by another wallet. The Solidity code computing this guarded salt can be found here.

0xdc010abe…e771sent to0xb024ac5a…a0162026-01-28·#24,336,242·0x66afb524…e0fd7e

# Add M0 Labs Engineering Reserved 'EarnerNu' Address as an Earner M0 Labs Engineering Team would like to add the pre-determined address 0x3ed111C56B9d2Ec19ccFF4B5dC79290B40b3f692 to the Earners list. This address will be used in the future for deployment of high priority Earner Contract like Extension or Bridging infrastructure that requires yield accrual and distribution. Earner Contract will be deployed by the wallet with the following address: 0xF2f1ACbe0BA726fEE8d75f3E32900526874740BB. Earner Contract relies on the ERC-1967 Proxy pattern for upgradability and the CREATEX Factory contract will be used to deploy the Earner contract via CREATE3 at the following pre-deterministic address: 0x3ed111C56B9d2Ec19ccFF4B5dC79290B40b3f692. This address can be verified by calling CREATEX function computeCreate3Address(bytes32 salt) with this salt: 0x9090f3c0729b8588e6aa23239edb1aaea5131209857cc52ac77199b1c0493541. This salt is computed by concatenating the deployer address with the EarnerNu contract name and is hashed with the deployer address to guard against deployment by another wallet. The Solidity code computing this guarded salt can be found here.

0xdc010abe…e771sent to0xb024ac5a…a0162026-01-28·#24,336,241·0x296479cf…5f770e

# Add M0 Labs Engineering Reserved 'EarnerMu' Address as an Earner M0 Labs Engineering Team would like to add the pre-determined address 0x62b7f5A5Be488ea58f660C5aff465647213Bc6e9 to the Earners list. This address will be used in the future for deployment of high priority Earner Contract like Extension or Bridging infrastructure that requires yield accrual and distribution. Earner Contract will be deployed by the wallet with the following address: 0xF2f1ACbe0BA726fEE8d75f3E32900526874740BB. Earner Contract relies on the ERC-1967 Proxy pattern for upgradability and the CREATEX Factory contract will be used to deploy the Earner contract via CREATE3 at the following pre-deterministic address: 0x62b7f5A5Be488ea58f660C5aff465647213Bc6e9. This address can be verified by calling CREATEX function computeCreate3Address(bytes32 salt) with this salt: 0x3d1877e4c5b5a48d5af4d9caa8111891cdf33fc2582a55db686c148e8e7fbdd2. This salt is computed by concatenating the deployer address with the EarnerMu contract name and is hashed with the deployer address to guard against deployment by another wallet. The Solidity code computing this guarded salt can be found here.

0xdc010abe…e771sent to0xb024ac5a…a0162026-01-28·#24,334,839·0xf3dc5aba…4b43ca

# Add M0 Labs Engineering Reserved 'SolanaEarnerNu' Address as a Solana Earner M0 Labs Engineering Team would like to add the M Vault PDA calculated for the pre-determined program address listed below to the Solana Earners list. This address will be used in the future for deployment of high priority Solana Earner Extension that requires yield accrual and distribution. Solana differs from Ethereum in that individual user balances are not stored on the Token 'Mint', but in individual Token Accounts. The owner of a Token Account controls the balance and must sign any transaction that moves those tokens. For a Program to sign transactions and control tokens, it must use a Program Derived Account (PDA), which is a sub-address of the Program derived from the hash of the Program address and a seed value. As a result PDA values are deterministic from the Program address (aka ID or PubKey) and the seed. For our purposes, the Extension Program custodies M tokens in a Token Account owned by its M Vault PDA. For the M held in the Program under this PDA to earn yield, it must be added as an Earner. Similar to Ethereum M earners, Solana M earners must be added to a list on the TTGRegistrar contract by Governance. This list is compiled into a Merkle tree by the new MerkleTreeBuilder contract. The root of this Merkle tree is sent to Solana via the M Portal Bridge. Since Solana addresses are longer (32 bytes) than EVM addresses (20 bytes), we must use the more generic `setKey(bytes32 key, bytes32 value)` function on the TTGRegistrar. The key is calculated as `keccak256(abi.encodePacked(bytes32('solana-earners'),bytes32(<M_VAULT_HEX>)))` where `<M_VAULT_HEX>` is the derived PDA pubkey expressed as a hexadecimal value. The value is just a boolean flag, so we set it to 1 (meaning the address is a member of the list). The pre-determined program address corresponds to a Solana keypair mined and custodied by the M0 Labs Engineering team for this purpose. No program is currently deployed at the address. The Vault PDA address can be verified using the Solana CLI command `solana find-program-derived-address <PROGRAM_ID> string:m_vault` where the actual base58 program ID is substituted for `<PROGRAM_ID>`. | Account Name | Address (base58) | Address (hex) | |----------------------|----------------------------------------------|--------------------------------------------------------------------| | Nu Extension Program | mextuLDMLF27Pg7YpvoU5raAJDsHw3jPeMhgXQyYbZE | 0x0b707b3646b2d86e61a6ce34ac60bf3836711a7a4f3d6d0ed7e142de70b266cd | | Nu Extension M Vault | EQfFn1JdYbRP4b3cwYdtabXFvLfxAcyJqxHdsdPvGrZm | 0xc7378b1f22dc884ce61bfca8368a1936bec6360a3230f23cf0dc2a24bbada1b8 |

0xdc010abe…e771sent to0xb024ac5a…a0162026-01-28·#24,334,839·0x59a3d941…76619b

# Add M0 Labs Engineering Reserved 'SolanaEarnerMu' Address as a Solana Earner M0 Labs Engineering Team would like to add the M Vault PDA calculated for the pre-determined program address listed below to the Solana Earners list. This address will be used in the future for deployment of high priority Solana Earner Extension that requires yield accrual and distribution. Solana differs from Ethereum in that individual user balances are not stored on the Token 'Mint', but in individual Token Accounts. The owner of a Token Account controls the balance and must sign any transaction that moves those tokens. For a Program to sign transactions and control tokens, it must use a Program Derived Account (PDA), which is a sub-address of the Program derived from the hash of the Program address and a seed value. As a result PDA values are deterministic from the Program address (aka ID or PubKey) and the seed. For our purposes, the Extension Program custodies M tokens in a Token Account owned by its M Vault PDA. For the M held in the Program under this PDA to earn yield, it must be added as an Earner. Similar to Ethereum M earners, Solana M earners must be added to a list on the TTGRegistrar contract by Governance. This list is compiled into a Merkle tree by the new MerkleTreeBuilder contract. The root of this Merkle tree is sent to Solana via the M Portal Bridge. Since Solana addresses are longer (32 bytes) than EVM addresses (20 bytes), we must use the more generic `setKey(bytes32 key, bytes32 value)` function on the TTGRegistrar. The key is calculated as `keccak256(abi.encodePacked(bytes32('solana-earners'),bytes32(<M_VAULT_HEX>)))` where `<M_VAULT_HEX>` is the derived PDA pubkey expressed as a hexadecimal value. The value is just a boolean flag, so we set it to 1 (meaning the address is a member of the list). The pre-determined program address corresponds to a Solana keypair mined and custodied by the M0 Labs Engineering team for this purpose. No program is currently deployed at the address. The Vault PDA address can be verified using the Solana CLI command `solana find-program-derived-address <PROGRAM_ID> string:m_vault` where the actual base58 program ID is substituted for `<PROGRAM_ID>`. | Account Name | Address (base58) | Address (hex) | |----------------------|----------------------------------------------|--------------------------------------------------------------------| | Mu Extension Program | mextuCwdM6AD1Z6o3SkMjegkhtSk2SDtxDoBmbwNg98 | 0x0b707b363a828aad47de093132a04ba4c19a4ca67d4c906ce0759c702d6d5e3b | | Mu Extension M Vault | BhRgsug5bbcGXuhTCQMioP2krgzoorHfEr3jmrbuVrp9 | 0x9ef00413a80177d9aca0487742c8e94e7d80d6113d805bab104e95b1c3ff3bb2 |

0xdc010abe…e771sent to0xb024ac5a…a0162026-01-28·#24,334,839·0x77950ed1…f8a667

# Add M0 Labs Engineering Reserved 'SolanaEarnerLambda' Address as a Solana Earner M0 Labs Engineering Team would like to add the M Vault PDA calculated for the pre-determined program address listed below to the Solana Earners list. This address will be used in the future for deployment of high priority Solana Earner Extension that requires yield accrual and distribution. Solana differs from Ethereum in that individual user balances are not stored on the Token 'Mint', but in individual Token Accounts. The owner of a Token Account controls the balance and must sign any transaction that moves those tokens. For a Program to sign transactions and control tokens, it must use a Program Derived Account (PDA), which is a sub-address of the Program derived from the hash of the Program address and a seed value. As a result PDA values are deterministic from the Program address (aka ID or PubKey) and the seed. For our purposes, the Extension Program custodies M tokens in a Token Account owned by its M Vault PDA. For the M held in the Program under this PDA to earn yield, it must be added as an Earner. Similar to Ethereum M earners, Solana M earners must be added to a list on the TTGRegistrar contract by Governance. This list is compiled into a Merkle tree by the new MerkleTreeBuilder contract. The root of this Merkle tree is sent to Solana via the M Portal Bridge. Since Solana addresses are longer (32 bytes) than EVM addresses (20 bytes), we must use the more generic `setKey(bytes32 key, bytes32 value)` function on the TTGRegistrar. The key is calculated as `keccak256(abi.encodePacked(bytes32('solana-earners'),bytes32(<M_VAULT_HEX>)))` where `<M_VAULT_HEX>` is the derived PDA pubkey expressed as a hexadecimal value. The value is just a boolean flag, so we set it to 1 (meaning the address is a member of the list). The pre-determined program address corresponds to a Solana keypair mined and custodied by the M0 Labs Engineering team for this purpose. No program is currently deployed at the address. The Vault PDA address can be verified using the Solana CLI command `solana find-program-derived-address <PROGRAM_ID> string:m_vault` where the actual base58 program ID is substituted for `<PROGRAM_ID>`. | Account Name | Address (base58) | Address (hex) | |--------------------------|----------------------------------------------|--------------------------------------------------------------------| | Lambda Extension Program | mextmcZAd421yuo8g77SdYjqcbpbkmKe1xH1URpx4D8 | 0x0b707b335847c540c4fb72fc9bd10b5a1da11bb3b6e65c99dec6d63d90772c73 | | Lambda Extension M Vault | 9mA22icPGbrtYLqFyrzEmjeEvTFkzibFoX5YMTGsmK3c | 0x822d3f569202428de7f07d515c5ecb3b51aef5f27166ffd1d3270c35d1bcc0ff |

0xdc010abe…e771sent to0xb024ac5a…a0162026-01-28·#24,334,838·0xec48f317…ebd568

# Add M0 Labs Engineering Reserved 'SolanaEarnerKappa' Address as a Solana Earner M0 Labs Engineering Team would like to add the M Vault PDA calculated for the pre-determined program address listed below to the Solana Earners list. This address will be used in the future for deployment of high priority Solana Earner Extension that requires yield accrual and distribution. Solana differs from Ethereum in that individual user balances are not stored on the Token 'Mint', but in individual Token Accounts. The owner of a Token Account controls the balance and must sign any transaction that moves those tokens. For a Program to sign transactions and control tokens, it must use a Program Derived Account (PDA), which is a sub-address of the Program derived from the hash of the Program address and a seed value. As a result PDA values are deterministic from the Program address (aka ID or PubKey) and the seed. For our purposes, the Extension Program custodies M tokens in a Token Account owned by its M Vault PDA. For the M held in the Program under this PDA to earn yield, it must be added as an Earner. Similar to Ethereum M earners, Solana M earners must be added to a list on the TTGRegistrar contract by Governance. This list is compiled into a Merkle tree by the new MerkleTreeBuilder contract. The root of this Merkle tree is sent to Solana via the M Portal Bridge. Since Solana addresses are longer (32 bytes) than EVM addresses (20 bytes), we must use the more generic `setKey(bytes32 key, bytes32 value)` function on the TTGRegistrar. The key is calculated as `keccak256(abi.encodePacked(bytes32('solana-earners'),bytes32(<M_VAULT_HEX>)))` where `<M_VAULT_HEX>` is the derived PDA pubkey expressed as a hexadecimal value. The value is just a boolean flag, so we set it to 1 (meaning the address is a member of the list). The pre-determined program address corresponds to a Solana keypair mined and custodied by the M0 Labs Engineering team for this purpose. No program is currently deployed at the address. The Vault PDA address can be verified using the Solana CLI command `solana find-program-derived-address <PROGRAM_ID> string:m_vault` where the actual base58 program ID is substituted for `<PROGRAM_ID>`. | Account Name | Address (base58) | Address (hex) | |-------------------------|----------------------------------------------|--------------------------------------------------------------------| | Kappa Extension Program | mextdCfJGgyD7qcFVorVK19LyugJFQ6Yz7extZLP4xi | 0x0b707b302669f1e4289ff5cbc039cf1040c1d68d223599dcb321064ea94aaceb | | Kappa Extension M Vault | 8D8eDPV346TVca4MGSLkbUUB1voJgxCGduVGTbNjzJU6 | 0x6b1d6b28ed369b2a340e2017502e990662c27eebfcdeee5c2886a52a11068faf |

0xdc010abe…e771sent to0xb024ac5a…a0162026-01-28·#24,334,837·0x6578dbb1…08ef3c

# Add M0 Labs Engineering Reserved 'SolanaEarnerIota' Address as a Solana Earner M0 Labs Engineering Team would like to add the M Vault PDA calculated for the pre-determined program address listed below to the Solana Earners list. This address will be used in the future for deployment of high priority Solana Earner Extension that requires yield accrual and distribution. Solana differs from Ethereum in that individual user balances are not stored on the Token 'Mint', but in individual Token Accounts. The owner of a Token Account controls the balance and must sign any transaction that moves those tokens. For a Program to sign transactions and control tokens, it must use a Program Derived Account (PDA), which is a sub-address of the Program derived from the hash of the Program address and a seed value. As a result PDA values are deterministic from the Program address (aka ID or PubKey) and the seed. For our purposes, the Extension Program custodies M tokens in a Token Account owned by its M Vault PDA. For the M held in the Program under this PDA to earn yield, it must be added as an Earner. Similar to Ethereum M earners, Solana M earners must be added to a list on the TTGRegistrar contract by Governance. This list is compiled into a Merkle tree by the new MerkleTreeBuilder contract. The root of this Merkle tree is sent to Solana via the M Portal Bridge. Since Solana addresses are longer (32 bytes) than EVM addresses (20 bytes), we must use the more generic `setKey(bytes32 key, bytes32 value)` function on the TTGRegistrar. The key is calculated as `keccak256(abi.encodePacked(bytes32('solana-earners'),bytes32(<M_VAULT_HEX>)))` where `<M_VAULT_HEX>` is the derived PDA pubkey expressed as a hexadecimal value. The value is just a boolean flag, so we set it to 1 (meaning the address is a member of the list). The pre-determined program address corresponds to a Solana keypair mined and custodied by the M0 Labs Engineering team for this purpose. No program is currently deployed at the address. The Vault PDA address can be verified using the Solana CLI command `solana find-program-derived-address <PROGRAM_ID> string:m_vault` where the actual base58 program ID is substituted for `<PROGRAM_ID>`. | Account Name | Address (base58) | Address (hex) | |------------------------|----------------------------------------------|--------------------------------------------------------------------| | Iota Extension Program | mextP5A2yk6D7PvrcyfUuXntfvt97HcgLRUEsDvD5Am | 0x0b707b2ac8a9a7463e7a4eac71e8f27a68e768f6594d8a8a562aee178008c876 | | Iota Extension M Vault | DHZhtqP4e97rNnsjXZJvRLfyP9RJdwKjyLdz2dWiP5Ti | 0xb68a840b20c6caa5a500badb6fcd2ae685ad8eb3d9d3b582f3c862bc8d9fdd3d |

0xdc010abe…e771sent to0xb024ac5a…a0162026-01-27·#24,327,261·0xa3d653be…db6f15

# Update standard proposal fee to 35 ETH This proposal increases the protocol’s standard proposal fee to 35 ETH. The intent is to materially raise the cost of submitting standard proposals, thereby encouraging the use of priority proposals for routine changes. Future protocol changes are expected to be managed by M0 Labs directly via the priority proposal pathway. External partners can still use the standard proposal mechanism but should be conscious of the new fee structure. ---

0xc07f0b45…cd33sent to0xb024ac5a…a0162026-01-27·#24,326,381·0xaa584b11…df6998

# Add Nerona USD (USDnr) as an Approved Earner ## **About** USDnr is Nerona's native yield-bearing stablecoin, designed as the core asset for a crypto-powered wealth management platform targeting high-net-worth individuals in the Asia-Pacific region. It automatically aggregates onchain yield from across DeFi protocols, enabling capital to work efficiently while providing institutional-grade stability and compliance. Learn more about Nerona at [https://nerona.xyz](https://nerona.xyz) * **Extension Name:** Nerona USD * **Targeted Chains:** Ethereum (initial deployment), with expansion to Fluent * **Extension Ticker:** USDnr --- ## **Yield Distribution** This uses the JMI **YieldToOne** extension. All yield earned from M0's underlying reserves will be directed to the Nerona treasury to: * Enhance USDnr holder returns through yield optimization strategies * Fund platform development and concierge services * Support ecosystem growth and partner integrations across APAC --- ## **Use Cases** USDnr will serve as the foundational asset in Nerona's wealth management ecosystem: ### **High-Yield Savings & Wealth Preservation** USDnr provides a stable, dollar-denominated store of value with automatic yield generation. Unlike traditional stablecoins that sit idle, USDnr continuously earns yield from M0's institutional-grade reserves, offering HNWIs and wealth managers a superior alternative to traditional banking deposits. ### **Seamless Capital Flow Across DeFi** Within Nerona's integrated platform, USDnr serves as the unified dollar layer for: * Yield aggregation across vetted DeFi protocols * Liquidity provision and portfolio rebalancing * Instant settlement for crypto card spending * Cross-border wealth transfers without traditional banking friction ### **Private Banking for the Digital Asset Era** USDnr is designed for sophisticated investors who demand: * Self-custody with institutional-grade security * White-glove concierge service for personalized wealth strategies * Transparent portfolio tracking and reporting * Compliant infrastructure for regulated markets --- ## **Roadmap for Inflows** Several upcoming milestones are expected to drive significant liquidity and adoption: **APAC Wealth Manager Partnerships** – Onboarding of leading family offices, private banks, and wealth management firms across Singapore, Hong Kong, and Southeast Asia who will utilize USDnr as their primary digital dollar allocation. **Crypto Card Launch** – Integration with global payment networks enabling USDnr holders to spend directly while maintaining yield generation on unspent balances. **Multi-Chain Expansion** – Deployment to Base, Arbitrum, and additional high-throughput chains with unified liquidity and seamless bridging for institutional users. **Institutional Custody Integrations** – Partnerships with qualified custodians to enable regulated entities and family offices to hold USDnr within a compliant infrastructure. **DeFi Yield Vault Launch** – Introduction of curated yield strategies allowing USDnr holders to access optimized DeFi returns through Nerona's risk-managed vaults, targeting Q2 2026\. --- ## **Security & Compliance** Nerona USD is built with institutional compliance as a core principle: * Full KYC/AML compliance for platform users * Regulatory alignment with APAC digital asset frameworks (Singapore MAS, Hong Kong SFC guidelines) * Integration with compliant freezer mechanisms for OFAC and sanctions enforcement * Self-custody architecture ensures users maintain full control of assets ---

0x50af02a3…6560sent to0xb024ac5a…a0162026-01-04·#24,162,017·0x2459df4b…0bf777

# Add Fairblock CUSD as an Approved Earner Confidential USD (CUSD) is a stablecoin designed for confidential payments, while remaining compliance-ready through selective disclosure controls and traceability. It aims to deliver a digital cash experience for payments and transfers, where amounts and balances are encrypted, without forcing users to rely on volatile privacy coins or isolated privacy chains. Privacy is powered by [Fairblock](https://fairblock.network/), a cryptographic execution layer built for dynamic confidential computing. Cryptographic operations such as homomorphic encryption, key generation, and ZKP verification run efficiently on Fairblock’s purpose-built chain, FairyRing. These capabilities can be accessed from confidential applications (cApps) deployed on FairyRing or on other major chains, allowing users to seamlessly utilize confidential functionality without the typical encryption delays, bridging funds, switching wallets, or compromising composability. CUSD contributes to the M0 infrastructure and ecosystem by expanding distribution into privacy-sensitive payment flows, including payroll, payouts, treasury operations, commerce, cross-border remittances, and large strategic trades. These use cases are expected to drive sustained demand for CUSD and confidential applications more broadly. CUSD is also the primary stablecoin powering [Stabletrust](https://stabletrust.io/), Fairblock’s confidential payments application. Stabletrust acts as a distribution engine for CUSD, and its permissionless integrations across DeFi ecosystems and applications accelerate early adoption and create structural demand. In addition to built-in selective disclosure and traceability, which prevent the typical risks associated with mixers and exposure to illicit flows, CUSD integrates Predicate-authorized freezing mechanism across all supported chains. This mechanism enforces compliance with OFAC requirements and applicable sanctions regimes. **Extension Name:** Confidential USD **Extension Ticker:** CUSD **Targeted Chains:** Ethereum, Arbitrum, Base, Solana, and leading payment networks such as Arc, Tempo, Noble, Stable ---

0x2328f33b…bccfsent to0xb024ac5a…a0162025-12-05·#23,946,840·0x0b1debd9…46c778

# Add pUSDC (a new stablecoin) for PRED as an earner PRED is a prediction exchange for sports - founded by seasoned entrepreneurs and backed by top global funds. Learn more about pred at [https://www.pred.app](https://www.pred.app). **Extension Name:** pUSDC **Target Chains:** Base **Extension Ticker:** pUSDC **Yield Distribution:** This uses the YieldToOne extension. All yield earned will go to PRED as revenue - which Pred is looking to reward active users consistently making predictions **Use Cases:** 1. pUSDC will be used as backing token for prediction market smart contracts as stable token collateral. **Roadmap for inflows:** PRED is a user facing prediction market, so major inflow will be 1. user TVL **Security & Compliance** pUSDC will use the Predicate authorized freezer across all chains that pUSDC is present on to enforce compliance with OFAC and sanctions. ---

0x80ea37a9…c0d6sent to0xb024ac5a…a0162025-12-05·#23,946,799·0xdb73a1d2…91947a

# Update eligible collateral criteria ### Proposal With the recent introduction of the GENIUS act in the United States, and with the increased interest from US based entities in utilizing the M0 tech platform for the issuance of stablecoins, it makes sense to evolve the definition of Eligible Collateral for the network in a way that aligns more closely with GENIUS language. With that goal, the present proposal recommends a revamped language for Eligible Collateral composition, in a way that maintains robustness and safety of collateral, while allowing issuers to utilize reserve components that are deemed permissible under GENIUS guidance. The new language proposed for such section of the Adopted Guidance was very much inspired in the GENIUS language, and it was reviewed with existing and prospecting issuers on the M0 network. ### Change #1 #### Section: 3.1. Criteria for Eligible Collateral **Old** > We expect Validators to solely and exclusively recognize assets as Eligible Collateral when such assets conform to the criteria below. > i. Criteria for the Eligibility of Assets: > - United States Treasury Bills with a remaining time to maturity of 180 days or less. > - Wrappers of United States Treasury Bills such as money market fund units (in so-called tokenized form over appropriate distributed ledgers—such as Ethereum Mainnet—or traditional book entry form) or any other comparable wrapper, that comply with the above mentioned remaining time to maturity criteria - subject to specific definition of the financial product in scope. > List of approved wrappers: (1) Superstate Short Duration US Government Securities Fund (commonly referred to as USTB), (2) BlackRock USD Institutional Digital Liquidity Fund (commonly referred to as BUIDL). > ii. Ancillary Criteria for the Eligibility of Assets: > - So-called In-Transit Cash, defined as Deposit Equivalents in an amount equal to placed-and-executed-but-not-yet-settled buy orders for assets defined in (i). In case such orders are ultimately canceled, settled, or never settled, such balances shall no longer be recognized. > - So-called In-Transit Securities, defined as executed-but-not-yet-settled sell orders for assets defined in (i) (at the time of purchase) in case, for the avoidance of doubt, neither the securities nor balances in Deposit Equivalents are listed in the Collateral Storage (and more specifically Custody Account and Deposit Account of the SPV). **New** > We expect Validators to solely and exclusively recognize assets as Eligible Collateral when such assets conform to the criteria below. > <u>3.1.1. Criteria for the Eligibility of Assets</u> > i. Funds (denominated in the Reference Currency) credited to an account at a United States Federal Reserve Bank. > > ii. Funds (denominated in the Reference Currency) held as demand deposits or insured shares at an insured depository institution - subject to specific institution in scope. > > a. Such financial institutions shall be deemed to be automatically in scope if the totality of deposits are held in deposit placement networks. (Note: Minter must perform a credit suitability assessment prior to placing funds at such an institution.) > > b. List of institutions additionally deemed in scope: (1) The Bank of New York Mellon Corporation; (2) DekaBank Deutsche Girozentrale; (3) Lead Bank. > > iii. United States Treasury securities with a remaining time to maturity of 180 days or less. > > iv. Funds (denominated in the Reference Currency) received under repurchase agreements where the Minter is the seller and with an overnight maturity. > > v. Reverse repurchase agreements where the Minter is the cash lender and with an overnight maturity, that are backed by United States Treasury securities and other government securities such as securities issued or guaranteed by government agencies, including, among others, Fannie Mae, Freddie Mac, and the Federal Home Loan Bank. In the event that collateral is not in the form of United States Treasury securities, such reverse repurchase agreement must be overcollateralized at a rate deemed to be appropriate by the Minter. > > vi. Securities issued by a regulated investment company, regulated fund or supervised entity, that is subject to prudential supervision in its home jurisdiction, provided that such vehicle invests exclusively in assets described in items (i), (ii), (iv) and (v). Specific to the requirements in (iii), securities shall be permitted to have a remaining maturity of 397 days or less so long as the weighted average portfolio maturity is 60 days or less and the weighted average portfolio life to maturity is 120 days or less. > > vii. Any version of items (i), (ii), (iii), (vi) in tokenized form, provided that such versions comply with all applicable laws and regulations - subject to specific definition of the financial product in scope. > > a. List of approved products: (1) Superstate Short Duration US Government Securities Fund (commonly referred to as USTB); (2) BlackRock USD Institutional Digital Liquidity Fund (commonly referred to as BUIDL). > <u>3.1.2. Ancillary Criteria for the Eligibility of Assets</u> > - So-called In-Transit Cash, defined as Deposit Equivalents in an amount equal to placed-and-executed-but-not-yet-settled buy orders for assets defined in 3.1.1. In case such orders are ultimately canceled, settled, or never settled, such balances shall no longer be recognized. > - So-called In-Transit Securities, defined as executed-but-not-yet-settled sell orders for assets defined in 3.1.1 (at the time of purchase) in case, for the avoidance of doubt, neither the securities nor balances in Deposit Equivalents are listed in the Collateral Storage (and more specifically Custody Account and Deposit Account of the SPV). ---

0x159d8520…aef6sent to0xb024ac5a…a0162025-12-05·#23,943,881·0xe1e7fcb8…9ab8a1

# Add Agent USD (AgentUSD) as an Approved Earner **About** agentUSD is a fully compliant, EIP-3009-enabled stablecoin powered by M0, designed as the native payment and settlement currency for the Questflow AI agent economy. It enables seamless, gasless, and autonomous agent-to-agent payments across multiple blockchains, fully integrated with the x402 payment protocol. Learn more about Questflow at [https://questflow.ai/](https://questflow.ai/) • Extension Name: Agent USD • Targeted Chains: Base (initial deployment), with cross-chain interoperability to all major EVM and non-EVM chains supported by M0 and x402 • Extension Ticker: agentUSD **Yield Distribution** This uses the YieldToOne extension. All yield earned from underlying reserves will be directed back to the Questflow ecosystem treasury to provide incentives to agent builders. **Use Cases** agentUSD will serve two primary roles in the Questflow AI agent economy: 1. Autonomous agent-to-agent payment currency via x402 agentUSD is fully compatible with the x402 protocol (HTTP 402 Payment Required standard), allowing AI agents to discover, negotiate, and execute micro-payments instantly and autonomously. Agents can pay each other for tools, data, knowledge, or sub-task execution without human intervention, gasless approvals (via EIP-3009 TransferWithAuthorization), and with sub-second settlement on Base and bridged chains. 2. Preferred settlement currency for the entire agent economy Within Questflow’s orchestration layer, agentUSD will be the default token for: - Utility token for users to use agents within the network - Rewarding agents for completed tasks - Settling value between agents and users - On-chain incentive distribution in the Questflow marketplace - Cross-chain agent-to-agent payments, making it the unified dollar layer for the decentralized AI agent workforce **Roadmap for Inflows** Several upcoming milestones are expected to drive significant liquidity and adoption: 1. Full x402 facilitator integration – Launch of native x402 support in Questflow’s facilitator, enabling any Questflow agents to pay external APIs and tools with agentUSD automatically. 2. Cross-chain expansion – Deployment to additional high-throughput chains (Arbitrum, Optimism, Polygon, Solana via bridges) with one-click mint/redeem, creating unified agentUSD liquidity across the agent economy. 3. Major agent marketplace partnerships – Onboarding of leading agent providers (e.g., AIXBT, ElizaOS, SANTA, and others) that will default to agentUSD for intra-agent settlements and user payouts. 4. Incentive & reward campaigns – Provide incentives for agent builders and provide agent performance bounties, and ecosystem grants denominated exclusively in agentUSD starting Q1 2026\. **Security & Compliance** Agent USD will use the Predicate authorized freezer across all chains that AgentUSD is present on to enforce compliance with OFAC and sanctions. ---

0xdc010abe…e771sent to0xb024ac5a…a0162025-12-04·#23,942,621·0xb3d4ea3b…ed7479

# Update Mint Ratio to 99.50% The MAP (Monetary Adaptation and Policy) committee proposes increasing the Mint Ratio from 99.00% to 99.50%. The Mint Ratio sets the required level of overcollateralization for M issuance, balancing solvency resilience with capital efficiency. Moving to 99.50% further improves minters’ operational flexibility and capital utilization while preserving systemic overcollateralization. ---

0x98f9fbf1…992esent to0xb024ac5a…a0162025-12-04·#23,942,599·0xcb1895f1…e47006

# Add calUSD (a new stablecoin in the Caliber Money platform) as an approved earner # About **Caliber USD ($calUSD)** is a US Treasury-backed stablecoin powered by M0 intended for use on the Caliber Money platform and mobile app as the default settlement token. Caliber evolves neobanking into a **seedless, non-custodial neobrokerage** via a mobile app that unifies finance: access global banking rails with stablecoins, spend with VISA, earn instant US Treasury-backed yield, and execute gasless cross-chain trades with sub-2-second execution time via Caliber’s RFQ system. Transfers are all abstracted behind simple usernames for seamless bank and crypto money movement. **Learn more at [caliber.money](https://caliber.money)** ### Extension Details - **Extension Name**: Caliber USD - **Targeted Chain**: Base - **Extension Ticker**: $calUSD ### Yield Distribution This uses the **MEarnerManager** extension. - **Phase 1 (Launch)**: 100% of yield accrues directly to $calUSD holders. - **Phase 2 (Post-Traction)**: Introduce tiered yield allocation (e.g., higher APY for power users, premium features) and a modest platform fee share to Caliber for ongoing development and platform incentives. ### Primary Use Cases – $calUSD as the Core Settlement & Portfolio Token in Caliber - Direct-deposit payroll from virtual bank accounts instantly converts to $calUSD and begins earning Treasury yield from day one. - Primary USD balance for the Caliber app; may be used to fund the Caliber Visa card for spending globally and to trade for over 13,000 onchain assets. ### Roadmap for Inflows 1. Caliber Private Beta Launch 2. Caliber Official Production Launch in App Store 3. Google Play Launch 4. Web App for Portfolio Management 5. Miniapp campaigns 6. RWAs and Curated DeFi Vaults 7. Regional Expansion with bank and card rails **Caliber Money ($calUSD)** is purpose-built to be the everyday, programmatic yield-bearing dollar to bridge the gap between 716M crypto owners and just 40-70M DeFi Users. We are excited to bring it to Base as the first approved earner in the Base ecosystem. --- [IPFS](https://bronze-main-orca-252.mypinata.cloud/ipfs/bafkreidtjyzkyv322n3coybe5f6pfdkvcsrv62oy2cqb2coqqm4pro5ohm)

0x85b7b882…1b07sent to0xb024ac5a…a0162025-12-04·#23,942,325·0xa3acfffb…d36288

# Add Meridian USD (mrUSD) as an Approved Earner **About** - mrUSD is a US Treasury-backed stablecoin powered by M0 for the Meridian x402 ecosystem. Learn more about Meridian at https://mrdn.finance • **Extension Name**: MERIDIAN USD •**Targeted Chains**: BASE CHAIN • **Extension Ticker**: mrUSD **Yield Distribution** - This uses the YieldToOne extension. All yield earned will go to the Meridian ecosystem for future investments in growth of the ecosystem and gas subsidy of x402 payments. **Website**: [https://mrdn.finance](https://mrdn.finance) **Use Cases** mrUSD will have 2 main use cases in the Meridian ecosystem: 1. **Medium of Exchange** - mrUSD can be used in x402 transactions given it supports EIP-3009 enabling it to be used as a USD equivalent token in payments on Base. 2. **Payment Settlement & Float** - In Meridian’s first party x402 contract, mrUSD can be used as the primary asset with balances being held in mrUSD to earn yield to subsidize payments for the long-term. Our contract requires a user to withdraw their balance after payments are processed, in the interim funds can be held in mrUSD. **Roadmap for Inflows** There are 4 avenues that can drive inflows for mrUSD: 1. **Payment Volume** - x402 payment volumes are steady at over $2M of transaction volume per day, Meridian’s innovative approach to x402 will be able to capture a significant portion of that volume. We will offer no fees on x402 transactions made with mrUSD which should drive demand for mrUSD to be used. 2. **Contract Float** - Our x402 implementation has a middleware contract that enhances the standard while maintaining its interface, this contract holds balances of payments yet to be withdrawn. As the float grows inside the contract we can use mrUSD as the default within the user’s balances and can build a float that generates yield for Meridian Association. 3. **Treasury** - Meridian Association will hold its treasury in mrUSD instead of USDC or other equivalents. 4. **LP & Trading Pair** - We will be opening an LP with MRDN/mrUSD with lower trade fees to incentivize holding mrUSD and allowing an initial use case that encourages holding for those who collect payments in mrUSD. **Security & Compliance** Meridian USD will use the Predicate authorized freezer across all chains that mrUSD is present on to enforce compliance with OFAC and sanctions. ---

0xd83e243e…2cc1sent to0xb024ac5a…a0162025-12-04·#23,939,386·0x68fe9c1d…0745ee

# Add Qiro USD (USDQ) as an Approved Earner **Qiro USD** is a M0-backed stablecoin designed to power on-chain private credit. It serves as the core capital formation asset within the Qiro ecosystem, enabling investors to seamlessly earn yield from private credit opportunities on Qiro’s lending platform. **About Qiro** Qiro is building a stablecoin lending platform powered by enterprise grade credit underwriting, connecting global fintech borrowers with stablecoin investors. Backed by Alliance, CMT Digital, EV3 (Escape Velocity), Druid Ventures and Trident Digital. **Website:** [https://qiro.fi](https://qiro.fi/) **Extension Details** - Extension Name: Qiro USD - Ticker: USDQ - Targeted Chains: Arbitrum, Plume, Base, Ethereum - Yield Distribution Mechanics : Qiro offers a USDQ Staking Vault, where users can deposit USDQ to earn yield sourced from: 1. M0/T-bill backing, and 2. Institutional-grade private credit deals on Qiro. Predicate will be used to enforce compliance policies on USDQ, including OFAC sanction screening and related checks. We are requesting that Qiro USD (USDQ) be added as an approved earning asset, enabling USDQ Staking Vault depositors to earn yield from M0. ---

0x0f48a9d6…e3cbsent to0xb024ac5a…a0162025-12-04·#23,936,317·0x03e29493…e0b376

# Add Nami USD (USDna) as an Approved Earner Extension Name: **Nami USD** Extension Ticker: **USDna** Extension Model: *MYieldToOne* **About USDna** USDna will become the native stablecoin of the SEI blockchain, a regulated and foundation supported asset designed to be the base currency for liquidity, trading and ecosystem growth. **Core Use Cases** Nami USD is built with a dual structure: - **USDna** is the liquid stablecoin, fully backed through M0 with US Treasuries and full regulatory compliance. - **USDnav** is the yield bearing version of the stablecoin. The USDnav vault distributes yield coming from M0 and from strategies supported by Nami and the SEI Foundation across protocols such as AAVE and Morpho. It maintains a transparent price per share system and allows users to deposit USDna to receive USDnav. The yield bearing token will be supported by dedicated incentives and a points program rewarding deposits and ecosystem participation. All vault contracts are currently under audit by a tier one firm. Partnerships with financial transparency providers such as Credora and Accountable are in progress. Predicate will be used to enforce compliance policies on USDna, including OFAC sanction screening and related checks. **Integration within Nami DEX** USDna will be the core asset of the upcoming flagship DEX v4, serving as the primary settlement token and the default liquidity standard. • Nami Credit will use USDna as its main asset for deposits, yield generation and borrowing against veNFT collateral. • Core pools on the DEX will be paired with USDna. • Partner protocols will be encouraged to pair their tokens with USDna. • Voting rewards from the new d3,3 model can be paid out in USDna, creating consistent demand. **Roadmap** USDna, USDnav, Nami DEX v4 and Nami Credit will launch in Q1 26 alongside a coordinated, large-scale marketing campaign. The goal is to position USDna as the native stablecoin of SEI from day one. ---

0xd0fe2019…4331sent to0xb024ac5a…a0162025-11-05·#23,733,150·0xf093a7e0…56de6f

# Update eligible collateral criteria to include BlackRock USD Institutional Digital Liquidity Fund (BUIDL) #### Proposal This present proposal recommends the inclusion of **BlackRock USD Institutional Digital Liquidity Fund (BUIDL)** product as one of the explicitly approved so-called wrappers of United States Treasury Bills to be deemed Eligible Collateral as per section 3.1, and valued in accordance to section 3.2 in the Adopted Governance — i.e. without any additional haircuts given no additional risk overlay of the wrapping technology. The BlackRock USD Institutional Digital Liquidity Fund (BUIDL) was analyzed in detail by several teams in the M0 ecosystem, including members of M0 Labs, MXON, and the M0 Foundation. After thorough diligence, the product is being recommended to distributed governance as suitable for the ecosystem. For more information on BUIDL, see [https://securitize.io/blackrock/buidl](https://securitize.io/blackrock/buidl) . For any questions on the due diligence and findings, please contact [joao.reginatto@m0.org](mailto:joao.reginatto@m0.org). #### Change #1 **Section: 3.1. Criteria for Eligible Collateral** Old: > i. Criteria for the Eligibility of Assets: > … > - List of approved wrappers: Superstate Short Duration US Government Securities Fund (commonly referred to as USTB). New: > i. Criteria for the Eligibility of Assets: > … > - List of approved wrappers: Superstate Short Duration US Government Securities Fund (commonly referred to as USTB), (2) BlackRock USD Institutional Digital Liquidity Fund (commonly referred to as BUIDL). ---

0xc2d7fa89…2ed5sent to0xb024ac5a…a0162025-11-05·#23,730,349·0xf752a2c4…335848

# Add mantraUSD (a new stablecoin in the MANTRA ecosystem) as an earner **About** - mantraUSD is a US Treasury-backed stablecoin powered by M0 for the MANTRA ecosystem. Learn more about MANTRA at https://mantrachain.io/ • **Extension Name:** MANTRA USD • **Targeted Chains:** MANTRA CHAIN • **Extension Ticker:** mantraUSD **Yield Distribution** - This uses the YieldToOne extension. All yield earned will go to the MANTRA ecosystem for future investments in growth of the ecosystem. **Use Cases** - mantraUSD will have 2 main use cases in the MANTRA ecosystem: 1. **Hub of Liquidity Pools** - mantraUSD will be the default settlement token and the hub of liquidity pools in both DEXs (QuickSwap and Lotus) on MANTRA chain 2. **Preferred settlement currency** - In our signature 1st party app, MANTRA Finance, mantraUSD will be the preferred token in our licensed RWA launchpad, licensed RWA vaults, and the 1st licensed DEX in the world. **Roadmap for Inflows** - There are 4 upcoming milestones that should drive notable inflows: 1. **Launchpad** - First RWAs issued via MANTRA Finance launchpad will use mantraUSD as the primary token for settlement. 2. **Vaults** - Our first RWA Vaults will bring 4 notable TradFi funds onchain. All value will be stored in mantraUSD inside the vaults. 3. **CEX Listings** - We are in conversations with several CEXs to list mantraUSD. 4. **Incentive campaigns** - We are partnering with Turtle and Merkl to bring notable inflows of liquidity to MANTRA chain in Q1. **Freeze Manager Role** - In addition to our in-house ops team monitoring for wallets that should be frozen, **Predicate** will also be added to the freeze role to assure the highest level of AML & sanctions compliance. --- [Discussion](https://discuss.mantrachain.io/t/mantrausd-deployment-on-m0/91) [IPFS](https://apricot-given-snake-720.mypinata.cloud/ipfs/bafkreia6wholnftedklxj7rctfa3hxhy2rv7kwqlrkzudfobem75hxaj5e)

0xd0fe2019…4331sent to0xb024ac5a…a0162025-11-05·#23,730,213·0x78a17ebb…c83927

# Introduce Eligibility Criteria for Earners #### Proposal As more and more builders decide to create custom digital dollar products using the M0 platform, the set of tools made available for developers can include external service providers that offer specific functionality. In order to promote the development of these partner service providers, this proposal introduces an initial set of eligibility criteria for Earners in the Adopted Guidance - particularly when those Earners are building a bespoke digital dollar product using M0. The fulfilment of such eligibility criteria could in the future be assisted or even enforced by partner service providers which developers will have the option to use. #### Change #1 **Section: 2.1. Actors** Old: > … New: > … > **Earner**: An Earner is simply a blockchain address approved by Governance that is able to receive the Earner Rate. #### Change #2 **Section: 7 Earners** Old: *N/A* New: > **7 Earners** > **7.1. Eligibility Criteria for Earners** It is anticipated that Earners in the M0 ecosystem will correspond to institutional holders or builders of digital dollar products. The ultimate function of Earners is as a source of demand for M, making it more likely that Minters can efficiently generate it. This is effectively to say that Earners align nicely with the ultimate distributors of M to the broader market. > > Earners are approved by Governance as discrete blockchain addresses. These Earner addresses must not match any OFAC or EU sanctioned blockchain addresses. > > To the extent that an Earner address is used for the build out of a bespoke digital dollar product, specifically as a smart contract (or similar) that contains M and mints an asset that is itself made available to holders, then this smart contract must include a mechanism to ensure that the blockchain addresses of such holders do not match any OFAC or EU sanctioned blockchain addresses. ---

0xceec24ac…2ae1sent to0xb024ac5a…a0162025-10-31·#23,695,850·0xae617f0f…d3e3f9

# Add Startale USD (USDSC) as an Approved Earner **Startale USD**, built by Startale, is positioned to be Asia's most trusted USD stablecoin. Sitting at the gateway to the Soneium ecosystem, Startale USD enables instant, secure transactions, offers yield opportunities, and powers reward accumulation. Learn more about Startale at [https://startale.com/](https://startale.com/). - **Extension Name:** Startale USD - **Targeted Chains:** Soneium, Ethereum - **Extension Ticker:** USDSC - **Yield Distribution Mechanics:** Startale Earn Vault: users can deposit to earn rewards. We are requesting to add Startale USD as an approved earner so that Startale USD Earn Vault depositors can earn yield. ---

0xdc010abe…e771sent to0xb024ac5a…a0162025-10-06·#23,515,494·0x4d7678a8…667051

# Add Additional Addresses for Bridge as Approved Earners (3/3) Bridge, as a minter on the M0 network, proposes to add additional wallet addresses to the be Approved Earners. This proposal allows Bridge to earn on its inventory of M at its following address: 0xbc95b114268534B10FE1F95C7d60ebFfB7020448. ---

0xdc010abe…e771sent to0xb024ac5a…a0162025-10-06·#23,515,476·0xc6fbfed6…83212a

# Add Additional Addresses for Bridge as Approved Earners (2/3) Bridge, as a minter on the M0 network, proposes to add additional wallet addresses to the be Approved Earners. This proposal allows Bridge to earn on its inventory of M at its following address: 0xdFd3723A63c889f512Cf6e460d79fCFe50AD6cDb. ---

0xdc010abe…e771sent to0xb024ac5a…a0162025-10-06·#23,515,469·0x1bae99f7…c80554

# Add Additional Addresses for Bridge as Approved Earners (1/3) Bridge, as a minter on the M0 network, proposes to add additional wallet addresses to the be Approved Earners. This proposal allows Bridge to earn on its inventory of M at its following address: 0xCD1394d24e1E404F9eB3609F872B0736bEcb9d74. ---

0xdc010abe…e771sent to0xb024ac5a…a0162025-10-03·#23,499,156·0x54757d7f…77317b

# Update Penalty Rate to 0.01% [1 bp] The MAP (Monetary Adaptation and Policy) committee is proposing to lower the Penalty Rate from 5 bps to 1 bp. The Penalty Rate is the charge applied when a Minter fails to meet required operational obligations, such as timely collateral updates or exceeding permitted debt. Lowering it to 0.01% maintains an effective deterrent against non-compliance while balancing for proportionate impact in light of the significant increase in total value of the M0 network. ---

0xdc010abe…e771sent to0xb024ac5a…a0162025-10-03·#23,499,124·0x5a533dc8…0400ad

# Update Mint Ratio to 99% The MAP (Monetary Adaptation and Policy) committee is proposing to increase the Mint Ratio from 98.00% to 99.00%. The Mint Ratio defines the level of overcollateralization required for M issuance, balancing solvency protection with capital efficiency. Raising it to 99.00% provides minters with greater operational flexibility and capital efficiency, while the short-duration nature of eligible U.S. Treasuries ensures that systemic overcollateralization remains robust even under significant rate shocks. ---

0x329c395d…4ea8sent to0xb024ac5a…a0162025-09-05·#23,299,593·0x0d0bcceb…d2c25d

# Add Galaxy Opportunistic Holdings I, LLC as an Approved Earner Galaxy is a global leader in digital assets and data center infrastructure, delivering solutions that accelerate progress in finance and artificial intelligence. Galaxy Opportunistic Holdings I LLC is a Cayman Islands company associated with Galaxy. GOH I is seeking approval of M0 governance to be an Approved Earner at address 0x329c395d83493ea909ba3ce76b04766e17de4ea8. ---

0xdc010abe…e771sent to0xb024ac5a…a0162025-09-05·#23,298,434·0x83fbecb0…a8588c

# Add wM Yield Recipient (Arbitrum) Account as an Approved Earner The M0 Foundation is proposing to add the wM Yield Recipient (Arbitrum) account to the earner list. This wallet receives the yield generated/distributed by the wM/USDC liquidity pool on Arbitrum and will continuously hold certain amounts of wM. As such, the entity is requesting to earn on its holdings of wM in the future if it chooses to do so. ---

0xdc010abe…e771sent to0xb024ac5a…a0162025-09-05·#23,298,405·0xe0dbb45f…bc38f5

# Add M0 Foundation GnosisSafe Account as an Approved Earner The M0 Foundation is proposing to add its GnosisSafe account to the earner list. This account holds certain amounts of M and other stablecoin equivalents to facilitate the operational needs of the business. As such, the entity is requesting to earn on its holdings of M in the future if it chooses to do so. ---

0xdc010abe…e771sent to0xb024ac5a…a0162025-09-05·#23,298,391·0x42a7a463…7a26e8

# Add TNT GnosisSafe Account as an Approved Earner The Next Thing Ltd., the primary operating entity of the M0 project, is proposing to add its GnosisSafe account to the earner list. This account holds certain amounts of M and other stablecoin equivalents to facilitate the operational needs of the business. As such, the entity is requesting to earn on its holdings of M in the future if it chooses to do so. ---

0xdc010abe…e771sent to0xb024ac5a…a0162025-09-05·#23,298,376·0xe11a96e0…60dd47

# Add TNT Operational Account as an Approved Earner The Next Thing Ltd., the primary operating entity of the M0 project, is proposing to add its operational account to the earner list. This wallet will hold certain amounts of M to facilitate the operational needs of the business. As such, the entity is requesting to earn on its holdings of M in the future if it chooses to do so. ---

0xac5a574b…1b3csent to0xb024ac5a…a0162025-08-07·#23,087,762·0xb5e2c948…4e9c6c

# Add Additional Address of Minter One Ltd as an Approved Earner MXON, the first Minter on the M0 Network, proposes to add an additional wallet address of Minter One Ltd, to the Earner's list. Minter One Ltd is the BD Minter to the first entity permissioned in the Minter's list, Minter One Generator (SPV) Ltd (collectively operating as MXON). This proposal allows Minter One Ltd to earn on its inventory of M. ---

0x7a514337…ba7dsent to0xb024ac5a…a0162025-08-07·#23,086,668·0x42c8ed0b…4ae0e5

# Add M0 Labs Engineering Reserved 'EarnerLambda' Address as an Earner **M0 Labs Engineering Team** would like to add the pre-determined address `0x911c64B221d3509F4fe27a352D12d8A0615D0674` to the **Earners** list. This address will be used in the future for deployment of high priority Earner Contract like Extension or Bridging infrastructure that requires yield accrual and distribution. Earner Contract will be deployed by the wallet with the following address: `0xF2f1ACbe0BA726fEE8d75f3E32900526874740BB` Earner Contract relies on the ERC-1967 Proxy pattern for upgradability and the CREATEX Factory contract will be used to deploy the Earner contract via **CREATE3** at the following pre-deterministic address: `0x911c64B221d3509F4fe27a352D12d8A0615D0674` This address can be verified by calling [**CREATEX**](https://etherscan.io/address/0xba5Ed099633D3B313e4D5F7bdc1305d3c28ba5Ed#readContract%23F4 ) function **computeCreate3Address(bytes32 salt)** with this salt: `0x61cc9e0b396944f920078bf9aa2455441427fed038a151f4e6bc4b8c4862cd37` This salt is computed by concatenating the deployer address with the **EarnerLambda** contract name and is hashed with the deployer address to guard against deployment by another wallet. The Solidity code computing this guarded salt can be found [here](https://github.com/m0-foundation/m-portal/blob/ddf583b9bef971752ec1360f9b089e6fefa9c526/script/helpers/Utils.sol#L73-L100). ---

0x7a514337…ba7dsent to0xb024ac5a…a0162025-08-07·#23,086,639·0x29b1e150…a06623

# Add M0 Labs Engineering Reserved 'EarnerKappa' Address as an Earner **M0 Labs Engineering Team** would like to add the pre-determined address `0x15504dacA15Badb83209d6c5e29fF15b30A508Ff` to the **Earners** list. This address will be used in the future for deployment of high priority Earner Contract like Extension or Bridging infrastructure that requires yield accrual and distribution. Earner Contract will be deployed by the wallet with the following address: `0xF2f1ACbe0BA726fEE8d75f3E32900526874740BB` Earner Contract relies on the ERC-1967 Proxy pattern for upgradability and the CREATEX Factory contract will be used to deploy the Earner contract via **CREATE3** at the following pre-deterministic address: `0x15504dacA15Badb83209d6c5e29fF15b30A508Ff` This address can be verified by calling [**CREATEX**](https://etherscan.io/address/0xba5Ed099633D3B313e4D5F7bdc1305d3c28ba5Ed#readContract%23F4) function **computeCreate3Address(bytes32 salt)** with this salt: `0x109dfb6c9fa0bd2b4f23d8db19328e339fee0148f7c86cd12968e2ec82179887` This salt is computed by concatenating the deployer address with the **EarnerKappa** contract name and is hashed with the deployer address to guard against deployment by another wallet. The Solidity code computing this guarded salt can be found [here](https://github.com/m0-foundation/m-portal/blob/ddf583b9bef971752ec1360f9b089e6fefa9c526/script/helpers/Utils.sol#L73-L100). ---

1-50 of 161