Skip to main content

Stellar Soroban: Smart Contracts for Stablecoin Infrastructure

How Soroban, Stellar's Rust and WASM smart contract platform live since February 2024, powers programmable stablecoins like MGUSD, USDC, and EURC on Stellar.

Written by Eco


Soroban is Stellar's smart contract platform, written in Rust and executed in WebAssembly (WASM), that went live on Stellar mainnet on February 20, 2024 with the Protocol 20 upgrade. It gives Stellar a programmable layer for stablecoins, tokenized real-world assets, and DeFi primitives on top of the network's classic asset issuance and anchors. The platform is referenced in MoneyGram's June 2, 2026 MGUSD launch announcement as part of the stack behind the new stablecoin, with M0 providing the mint and burn smart contract infrastructure and Stellar serving as the settlement network.

Stablecoin issuers historically chose Stellar for its low fees, sub-five-second settlement, and anchor network. Soroban adds a contract layer that lets those stablecoins carry programmable behavior. Specific MGUSD contract mechanics beyond what the launch release describes are not yet publicly detailed as of June 2026.

What is Soroban?

Soroban is Stellar's smart contract platform, launched on mainnet February 20, 2024 with Protocol 20 and opened to public dApp deployment in March 2024. Contracts are written in Rust, compiled to WASM, and executed by the Stellar core protocol. The platform targets payments, stablecoins, tokenized assets, and DeFi, with five-second finality on Stellar's existing consensus.

The platform was developed inside the Stellar Development Foundation over a roughly two-year testnet cycle that drew about 190 projects into a minimum viable ecosystem before mainnet. SDF allocated $100 million to a Soroban Adoption Fund at launch, per the March 2024 announcement. The platform is branded "Stellar smart contracts" in product surfaces and "Soroban" in developer docs. Soroban inherits the Stellar Consensus Protocol. There is no separate Soroban chain or rollup. Contract execution happens on the same ledger that settles XLM, USDC, EURC, YLDS, and now MGUSD.

How does Soroban differ from Stellar's classic asset issuance?

Stellar's classic model lets any account issue an asset by setting trustlines and signing payment operations on the core ledger, with no contract code involved. Soroban adds a contract execution environment. The two coexist. A classic Stellar asset gains a contract-level interface through the Stellar Asset Contract, so issuers keep classic distribution and layer programmable behavior on top.

USDC and EURC, issued by Circle since 2021, work through trustlines, the path payment system, and Stellar's decentralized exchange. That model handles issuance, transfers, swaps, and anchor on-ramps without contract code. The trade-off is that classic assets cannot enforce custom logic; rules are limited to what the protocol exposes natively.

Soroban introduces a programmable layer. Contracts can hold state, enforce custom rules, and call into other contracts. A stablecoin issuer using Soroban can write mint and burn logic, whitelist or freeze accounts where regulation requires it, attach yield distribution, or expose integrator hooks. The classic asset and its Soroban contract interface refer to the same balance, which avoids the fragmentation problem early L1s saw when wrapped versions diverged from native tokens.

Soroban architecture: host functions, SAC, contract storage, fees

Soroban's architecture combines Rust and WASM contract code with host functions exposed by the Stellar core, the Stellar Asset Contract for classic assets, three-tier contract storage with explicit rent costs, and a fee model that prices CPU, memory, ledger reads and writes, and rent independently. The design targets predictable execution cost and state bloat control.

Host functions. Soroban contracts run inside a sandboxed WASM VM and cannot read or write arbitrary state. Every call out of the contract, whether reading ledger entries, transferring an asset, or calling another contract, goes through a defined host function in the Stellar core. The host function set is versioned per protocol release, giving contract authors a stable target.

Stellar Asset Contract. The Stellar Asset Contract, or SAC, is a built-in contract that exposes any classic Stellar asset through the SEP-41 token interface, implementing CAP-46-6. Each issued classic asset has a reserved SAC instance on the network. A USDC, EURC, or MGUSD holder, depending on how MoneyGram configures the asset per the launch release, gets a contract-level API for the same balance the classic account holds. SAC tokens have been benchmarked at roughly 97 percent less CPU and 98 percent less RAM than pure Soroban token implementations, with about 47 percent lower fees, per third-party analyses.

Contract storage. Soroban storage has three tiers. Instance storage lives with the contract. Persistent storage survives across calls and pays rent per entry. Temporary storage expires after a fixed ledger window at a much lower rent. This split is the protocol's response to state bloat. Stablecoin contracts typically keep balance records in persistent storage and short-lived approvals in temporary storage.

Fees. A Soroban transaction pays for CPU instructions, memory, ledger reads, ledger writes, transmission bytes, and storage rent. Each axis is metered. Typical token transfers settle for fractions of a cent in XLM, and finality lands inside five seconds. The fee model tracks real resource consumption, so a heavy contract call costs more than a simple SAC transfer.

What does Soroban enable for stablecoin infrastructure?

Soroban gives stablecoin issuers programmable mint and burn, integrator hooks for distribution partners, onchain compliance primitives, and composability with Stellar's classic anchor and payment systems. Issuers can layer custom logic onto a stablecoin without leaving the chain that already handles fiat anchors, FX paths, and on-network exchange.

Programmable mint and burn. Classic Stellar lets the issuing account create or remove supply directly. Soroban lets that same logic sit in a contract, with named admin roles, multi-sig conditions, oracle inputs, or reserve-attestation checks baked into the mint function. M0's general architecture, described publicly on m0.org, is built around a programmable mint and burn primitive. The June 2, 2026 launch release names M0 as the smart contract infrastructure for MGUSD, with the specific configuration not detailed publicly.

Integrator hooks. A Soroban stablecoin can expose hooks that other contracts call into. A payments app can read live supply, check whether a destination address is on an issuer-maintained sanctions list, or trigger a redeem flow. The launch release names Fireblocks as the wallet infrastructure for MGUSD, which is custody rather than contract logic, but the contract layer is what lets a Fireblocks-managed wallet move MGUSD with programmable rules attached.

Compliance primitives. Soroban contracts can freeze, claw back, or whitelist accounts when the issuer holds the relevant authority. The launch release describes Bridge as a "regulated, GENIUS Act-ready issuer" for MGUSD; for GENIUS Act mechanics themselves, see the GENIUS Act explainer.

Composability with the classic stack. A SAC-fronted asset can flow through Stellar's path payments and anchor network the same way a classic asset does, while being readable and callable by Soroban contracts. A remittance can settle MGUSD between anchors at sub-five-second finality and a contract can record the transfer in the same transaction.

How do MGUSD's M0 contracts relate to Stellar's contract layer?

Per MoneyGram's June 2, 2026 launch release, MGUSD is built on M0's smart contract infrastructure for minting and burning, with Stellar as the deployment network and Bridge as the issuer. Which Soroban primitives M0's MGUSD configuration uses, whether the asset is SAC-fronted, and how the contract surface is exposed to integrators are not publicly documented as of June 2026.

What can be said from the release: M0 provides the contract layer that mints and burns MGUSD against the dollar reserve Bridge holds, and Stellar provides the settlement network. M0 has discussed its model publicly as a mint and burn primitive with extensions and integrators on top. The release frames Bridge as the "regulated, GENIUS Act-ready issuer" and Fireblocks as the wallet layer.

Luke Tuttle, MoneyGram's chief product and technology officer, is quoted in the release: "MGUSD enables MoneyGram's monetary layer to run on stablecoin rails by design." That positions the contract stack as the substrate for MoneyGram's roughly 500,000-location distribution network, with contracts doing the supply mechanics and the classic Stellar stack doing the settlement. The release does not specify the rollout schedule for international corridors beyond foregrounding the U.S. market with planned global scale.

Other stablecoin and tokenized-asset projects on Soroban

Soroban now hosts a mix of stablecoins, tokenized funds, and yield-bearing instruments. Circle's USDC has SAC-level support on Stellar, EURC followed, Figure's YLDS is a yield-bearing instrument, and MGUSD is the most recent named arrival per the June 2, 2026 launch release. SDF has reported the tokenized real-world asset base on Stellar in the billion-dollar range as of 2026.

The SAC pattern means classic assets that predate Soroban gain contract-level functionality without reissuance. USDC and EURC sit in that category. YLDS, the yield-bearing stablecoin from Figure described in Stellar's YLDS explainer, exposes interest accrual through contract logic. MGUSD enters this set as a Bridge-issued, M0-contracted, Stellar-deployed asset per the launch release.

Beyond stablecoins, Stellar's tokenized RWA ecosystem includes tokenized money market funds and treasury-backed instruments. The Stellar RWA ecosystem article covers the wider asset list. Soroban is the contract layer that lets those instruments expose custom accounting and integrate with payment paths in the same transaction envelope.

Where does Soroban fit in the broader Stellar stack?

Soroban sits as the programmable layer above Stellar's classic asset and payment system, and below the anchor and application layers. A stablecoin flow on Stellar touches all four: an issuer mints supply through a contract, the asset moves over classic payment rails, an anchor converts between the asset and local fiat, and a wallet drives the user-facing flow.

Layer

Role

Example for a Stellar stablecoin

Consensus

Validators agree on ledger state via Stellar Consensus Protocol

Stellar core nodes settle blocks roughly every five seconds

Classic asset and payment

Trustlines, path payments, decentralized exchange

USDC, EURC, MGUSD move between accounts and anchors

Soroban contracts

Programmable mint, burn, compliance, integrator hooks

M0 contracts for MGUSD per the launch release

SAC

Contract-level API onto a classic asset

Any classic stablecoin gets a SEP-41 surface

Anchor

Fiat on and off ramps

MoneyGram retail locations for MGUSD cash-out per the release

Application

Wallets, payment apps, distribution partners

MoneyGram app, third-party Stellar wallets

Cross-chain reach for Stellar stablecoins runs through bridges and intent routers outside the Stellar protocol. Circle's CCTP supports USDC across more than ten chains including Stellar. Intent routing layers like Eco Routes aggregate stablecoin paths across rails and could compose with Stellar-native assets when corridor-level routing is needed. Per the launch release, MGUSD is Stellar-native at launch.

Sources and methodology. MGUSD launch facts are sourced directly from MoneyGram's June 2, 2026 launch announcement. Soroban architecture and SAC details are sourced from Stellar developer documentation and the March 2024 Soroban mainnet announcement. M0 architecture references draw on m0.org public material. As of June 2026, MGUSD-specific contract configuration is described in the launch release but not detailed beyond the stack-level framing. Updated June 2026.

Related reading

Did this answer your question?