M0 Cross-Chain Architecture: M Portals
Overview
Native Multichain $M
The core objective of M0's multichain strategy is to make the native $M token accessible across various blockchains beyond Ethereum mainnet. This aims to provide users with a consistent experience, particularly regarding yield-earning capabilities, regardless of the chain they operate on, while maintaining Ethereum as the authoritative source for $M issuance and governance.
M Portals are the set of smart contracts that facilitate this cross-chain functionality. They are responsible for bridging the $M token itself, as well as propagating essential system information like the yield index and governance parameters between Ethereum and connected Spoke chains.
To cater to different ecosystem needs and technical requirements, M0 offers two distinct implementations of the Portal system.
M Portal Implementations: Standard vs. Lite
M0 provides two portal versions built on different underlying technologies. While they share the same core goal of bridging $M and its metadata, they have key differences in architecture, features, and chain support.
- M Portal (Standard): The original, feature-rich implementation built on the Wormhole Native Token Transfer (NTT) framework. It is designed for maximum compatibility, supporting both EVM and non-EVM chains (like Solana) and allowing for spoke-to-spoke transfers.
- M Portal Lite: A streamlined, gas-efficient, and more modular implementation built on the Hyperlane messaging protocol. It is designed specifically for EVM-only environments, follows a stricter hub-and-spoke model (no spoke-to-spoke transfers), and introduces enhanced security mechanisms and a developer-friendly upgradeable design.
At a Glance: M Portal vs. M Portal Lite
Feature | M Portal (Standard) | M Portal Lite |
---|---|---|
Bridge Technology | Wormhole NTT | Hyperlane |
Chain Support | EVM & non-EVM (e.g., Solana) | EVM-only |
Communication | Hub-Spoke & Spoke-Spoke | Strictly Hub-Spoke |
Contract Design | Monolithic (inherits NttManager ) | Modular & Extendable (uses IBridge interface) |
Security Model | Hub balance = Total locked | Hub tracks bridgedPrincipal per spoke chain |
Chain IDs | Wormhole uint16 IDs | Standard EVM uint256 IDs |
The Hub-and-Spoke Model
Both M Portal implementations employ a Hub-and-Spoke architecture for multichain deployment:

-
Hub Chain (Ethereum):
- The single source of truth for the native $M token (where it's initially minted and governed).
- Hosts the
HubPortal
contract. - Token Mechanism: Lock-and-Release. When bridging from the Hub, $M tokens are locked. When bridging back to the Hub, these locked tokens are released.
- Acts as the source for propagating the $M Earning Index and TTG Registrar values.
- (M Portal Lite Specific): The
HubPortal
also tracks the principal amount of $M bridged to each spoke chain to ensure it never releases more tokens than were locked for that specific spoke.
-
Spoke Chains (e.g., Optimism, Arbitrum):
- Host representations of the $M token.
- Host
SpokePortal
contracts. - Token Mechanism: Mint-and-Burn. When bridging to a Spoke chain, a corresponding amount of $M representation is minted. When bridging from a Spoke chain, the $M representation is burned.
- Receive and apply the $M Earning Index and TTG Registrar values propagated from the Hub.
This model ensures that the canonical $M supply originates and is controlled solely on Ethereum, while Spoke chains manage representations backed by the locked tokens on the Hub.