MGUSD is the USD-pegged stablecoin MoneyGram launched on June 2, 2026 to power its global cash-in and cash-out network, and M0 is the smart contract platform that handles its mint and burn logic. Per the launch announcement, Bridge (a Stripe company) is the issuer of record, M0 supplies the programmable token infrastructure, Fireblocks holds the operational wallets, and Stellar is the settlement network. This article unpacks the M0 layer specifically: what M0 is, how its mint and burn architecture works in general, what the launch release does and does not say about MGUSD's contract configuration, and how the four-party stack splits responsibilities.
For the explainer on MGUSD itself, see what is MGUSD. For the issuance counterpart on Bridge, see MoneyGram and Bridge. For the custody piece on Fireblocks, see MoneyGram and Fireblocks.
What is M0?
M0 is a modular stablecoin issuance platform that lets integrators launch custom-branded dollar tokens on programmable mint and burn infrastructure. Per m0.org, the platform separates token logic from reserve custody, exposes configurable extensions for token behavior, and routes liquidity through an onchain orchestration layer. Integrators choose their own issuance posture rather than inheriting one.
The model treats stablecoin issuance as a stack of independent layers. An application layer configures token behavior, rewards, and access controls. A distribution layer handles cross-chain delivery and liquidity routing. An issuance layer lets each integrator pick an M0-powered regulated issuer or self-issue, depending on their license posture. Bridge, MetaMask, KAST, PayPal, Anchorage, and MoonPay are listed on m0.org as integrators or named partners.
Per The Defiant's coverage, M0's design point is that the underlying $M token is a "stablecoin building block" canonically minted on Ethereum and ported to other chains, with extensions wrapping it into branded tokens that carry their own compliance rules, yield mechanics, and access controls. The MetaMask USD token (mUSD) is the most-cited live example to date.
How does M0's mint and burn architecture work?
M0's general architecture controls mint and burn through a permissioned minter contract that gates token creation against off-chain reserve attestations. Per m0.org's public material and The Defiant's writeup, an integrator's branded token wraps M0's $M building block. The wrapping contract handles token-specific logic like compliance hooks and yield routing, while the underlying mint and burn flow stays gated by M0's permissioned actors.
Two design choices matter for understanding the MGUSD context. First, mint and burn rights are not open. A defined set of permissioned actors can call the mint function, and the contract enforces that on-chain supply never exceeds attested off-chain reserves. Second, mint operations are time-windowed. Public documentation describes delay and time-to-live mechanisms that create a review window between a proposed mint and its execution, so any single action is reviewable before it settles.
For MGUSD specifically, the launch release names M0 as the smart contract layer and Bridge as the regulated issuer, but does not publish the contract addresses, the exact extension configuration, the validator set, or the parameter values for any review windows. Treat M0's general mint and burn architecture as the framing; the MGUSD-specific instantiation is described publicly only at a high level as of June 2026.
What role does M0 play in the MGUSD launch?
Per the June 2, 2026 launch announcement, M0 is the smart contract layer that handles MGUSD's mint and burn logic on Stellar. Bridge is the regulated issuer of record. Fireblocks holds the operational wallets that move MGUSD to MoneyGram's customer wallets. Stellar is the settlement network. The release describes the four-party split at a high level and does not detail M0's specific contract configuration.
This is a structural pattern M0 has used with other integrators. The integrator chooses how to wrap and brand the underlying token, what compliance rules apply, what yield (if any) accrues, and what cross-chain footprint to support. Per The Defiant, this is what differentiates M0's posture from monolithic issuers like Circle, which controls token logic and reserve custody as one tightly coupled stack. Per the launch announcement, MoneyGram's MGUSD takes the modular path: separate parties for issuance, contracts, custody, and settlement.
As of June 2026, public technical material on MGUSD itself remains limited to the launch release and re-reporting. M0's docs cover the general $M extension model but do not yet publish MGUSD-specific contract artifacts. Treat any deeper claim about MGUSD's mint cadence, validator quorum, or wrapping configuration as not yet publicly detailed.
How does the Bridge-plus-M0-plus-Fireblocks stack split responsibilities?
The MGUSD stack assigns each party one job. Bridge is the regulated issuer, named in the launch release as a "GENIUS Act-ready issuer." M0 provides the mint and burn contracts that gate token supply against reserve attestation. Fireblocks holds the operational wallets that route MGUSD to MoneyGram customer wallets embedded in the MoneyGram app. Stellar settles the resulting transfers. Each layer is replaceable in principle, which is the core of M0's modular pitch.
For a payments company operating across 200 countries and roughly 500,000 retail locations, this split matters operationally. The issuer license sits with Bridge. The contract code sits with M0. The custody operation sits with Fireblocks. The network sits with Stellar. MoneyGram orchestrates the product layer (the wallet, the app, the cash-out flow) on top. In practice, swaps of regulated layers are not casual; issuer changes require license refiling, custody migrations require operational reconfiguration, contract upgrades require governance steps. The modular framing describes what is structurally possible, not what is operationally trivial.
What does the launch release describe versus what is not yet public?
The June 2, 2026 launch release names the four parties, describes the high-level split of responsibilities, and quotes executives from MoneyGram, Stellar, and (with attribution) describes Bridge as a "regulated, GENIUS Act-ready issuer." It does not publish contract addresses, validator lists, mint and burn parameters, or per-corridor rollout schedules. Most secondary coverage in the first 24 hours re-reports the release itself.
Specifically, the following items are described publicly in the launch release: MGUSD launched on Stellar, Bridge issues it, M0 supplies the smart contract stack, Fireblocks holds operational wallets, MoneyGram embeds customer wallets in its app, the network spans roughly 500,000 retail locations. The following items are not yet publicly detailed: the exact contract address of MGUSD on Stellar, the configuration of any M0 extensions used, the validator set or governance threshold for mints, the cadence of reserve attestation publication, and the country-by-country rollout schedule.
For independent verification, Stellar explorers will reflect token issuance once the contract is publicly indexed. Per Stellar's account model documented at stellar.org, asset issuers are addressable onchain and circulation can be observed without trust assumptions. As of June 2026 the canonical reference is the press release.
How does M0's stack compare with other stablecoin issuance contracts?
Stablecoin issuance contracts fall along a spectrum from fully coupled (one entity owns issuance, custody, and token logic) to modular (each layer is a separate party). USDC's Circle-issued model sits near the coupled end. Bridge's issuance-as-a-service model, including USDB and now MGUSD, sits closer to the modular end. M0's extension model sits further along the modular axis again, decoupling token logic from the underlying stablecoin building block.
The table below summarizes the structural differences. Coupled stacks reduce coordination cost and centralize accountability. Modular stacks reduce single-point dependency and let specialized parties handle issuance, contracts, custody, and settlement independently.
Model | Token logic | Issuer of record | Custody | Example |
Coupled | Issuer-controlled | Issuer | Issuer-managed | USDC (Circle) |
Issuance-as-a-service | Issuance platform | Regulated issuance partner | Third party | USDB, MGUSD (Bridge) |
Modular extension | Integrator-wrapped | Permissioned minters | Integrator choice | mUSD (MetaMask on M0) |
MGUSD blends two of these patterns. Bridge is the regulated issuance partner, which is the issuance-as-a-service pattern. M0 supplies the underlying contracts, which is the modular extension pattern. The combination, per the launch release, is what lets MoneyGram bring a digital dollar to its existing 500,000-location network without becoming a stablecoin issuer itself. Cross-chain intent routers like Eco Routes aggregate rails such as CCTP, Hyperlane, and LayerZero, and can compose with stablecoins issued under any of the three structural patterns once those stablecoins are available on supported chains.
Why does a remittance-network stablecoin need programmable mint and burn?
A remittance network mints dollars when senders fund a transfer and burns dollars when recipients cash out. Programmable mint and burn lets the network anchor circulating supply to attested reserves in real time, gate which actors can call mint, and apply compliance hooks at the contract level. For a network that touches 200 countries and roughly 500,000 retail locations, contract-level control is more auditable than off-chain reconciliation.
Three properties matter for the MoneyGram use case. First, supply must track reserves. Per the launch release, Bridge is the regulated issuer with the attested reserve, and M0's contracts gate mint against that attestation. Second, the network must enforce who can move tokens at high volume. Fireblocks holds operational wallets; Bridge controls issuance. Third, compliance hooks (sanctions screening, frozen addresses, KYC tier limits) sit at the contract or wallet layer rather than relying on every downstream integration to enforce them.
None of those properties is unique to M0. Circle's USDC supports a blocklist on every chain it deploys to, and Tether's USDT enforces issuer-level freeze actions. What M0's extension model adds is the ability to configure these properties per integrator. Other M0 integrators like MetaMask USD and KAST Dollar use the same underlying stack with different extension settings.
Where can teams read more on M0 and MGUSD?
For M0's general architecture and extension model, the canonical references are m0.org (platform overview), m0.org's documentation site, and third-party explainers like The Defiant's coverage of M0's modular posture. For MGUSD specifically, the primary source as of June 2026 is the June 2, 2026 launch announcement.
For the regulated issuance layer, see Bridge's public material at bridge.xyz and the cluster article on the Bridge stablecoin stack. For the custody layer, see Fireblocks' public docs and the cluster article on MGUSD custody and wallet infrastructure. For the settlement layer, see Stellar's docs at stellar.org and the cluster article on MGUSD on Stellar. For GENIUS Act framing, see the GENIUS Act explainer rather than restating regulatory mechanics here.
Related reading
Sources and methodology. Primary source for MGUSD-specific claims: the MoneyGram launch announcement dated June 2, 2026. Secondary sources for M0's general architecture: m0.org and The Defiant's coverage of M0. As of June 2026, MGUSD-specific contract addresses, extension parameters, and validator configurations are not yet publicly detailed; this article distinguishes M0's general mechanics from MGUSD's specific instantiation throughout. Figures and named partners refresh as additional disclosure becomes available.

