Skip to content

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.

  1. 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.
  2. 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

FeatureM Portal (Standard)M Portal Lite
Bridge TechnologyWormhole NTTHyperlane
Chain SupportEVM & non-EVM (e.g., Solana)EVM-only
CommunicationHub-Spoke & Spoke-SpokeStrictly Hub-Spoke
Contract DesignMonolithic (inherits NttManager)Modular & Extendable (uses IBridge interface)
Security ModelHub balance = Total lockedHub tracks bridgedPrincipal per spoke chain
Chain IDsWormhole uint16 IDsStandard EVM uint256 IDs

The Hub-and-Spoke Model

Both M Portal implementations employ a Hub-and-Spoke architecture for multichain deployment:

Hub & Spoke
  • 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.