Skip to content

Core Bridging Process

The transfer of $M (or its extensions like Wrapped $M) between the Hub and Spoke chains follows a similar logical flow in both implementations, orchestrated by the Portals and their underlying messaging bridge.

Transfer: Hub Chain -> Spoke Chain

Hub & Spoke Architecture

  1. User Interaction: The user initiates a transfer by calling a function on the HubPortal contract on Ethereum, specifying the destination chain and amount. Beforehand, users can call a function to get the estimated delivery fee for the cross-chain transaction.

    • M Portal (Standard): The function is quoteDeliveryPrice, inherited from the Wormhole NTT framework.
    • M Portal Lite: The function is quoteTransfer.

    After getting the fee and approving the HubPortal to spend their $M or Wrapped $M, the user makes the final transfer call.

  2. Token Handling:
    • If the user transferred Wrapped $M, the HubPortal first unwraps it to the native $M token.
    • The native $M tokens are then locked within the HubPortal contract.
    • (M Portal Lite Specific): The HubPortal increments its internal bridgedPrincipal counter for the destination spoke chain.
  3. Message Creation & Sending:
    • The HubPortal constructs a cross-chain message containing transfer details (amount, recipient, destination chain) and additional metadata (like the current $M Index).
    • It interacts with its configured bridge to send this message.
      • M Portal (Wormhole): Interacts with the Wormhole Transceiver via the NttManager logic to publish a message to the Wormhole network.
      • M Portal Lite (Hyperlane): Interacts with the HyperlaneBridge contract, which dispatches the message via the Hyperlane Mailbox.

  4. Cross-Chain Relaying (Off-Chain): The message is validated by the underlying bridge's security mechanism (Wormhole Guardians or Hyperlane's Interchain Security Modules (ISMs)). Once validated, the message is delivered by relayers to the destination Spoke chain.

  5. Message Reception & Processing:
    • The bridge contract on the Spoke chain receives the message and passes it to the SpokePortal.
  6. Token Minting & Delivery:
    • The SpokePortal processes the message.
    • It mints the corresponding amount of the $M token representation on the Spoke chain.
    • If the original transfer was for Wrapped $M, the SpokePortal wraps the newly minted $M.
    • The final token is transferred to the recipient address on the Spoke chain.

Transfer: Spoke Chain -> Hub Chain

This is largely the reverse process.

  1. User Interaction: User calls the SpokePortal on a Spoke chain to send tokens back to the Hub.
  2. Token Handling:
    • If transferring Wrapped $M, it's unwrapped to the native $M representation.
    • The native $M tokens are burned by the SpokePortal.
  3. Message Creation & Sending: The SpokePortal sends a cross-chain message back to the Hub Chain (Ethereum).
  4. Cross-Chain Relaying: The message is relayed back to Ethereum.
  5. Message Reception & Processing: The bridge on Ethereum receives the message and passes it to the HubPortal.
  6. Token Releasing & Delivery:
    • The HubPortal processes the message and releases (unlocks) the equivalent amount of native $M tokens.
    • (M Portal Lite Specific): The HubPortal first verifies that the requested release amount does not exceed the bridgedPrincipal for that source spoke chain. It then decrements the bridgedPrincipal counter.
    • The released tokens (wrapped if necessary) are delivered to the recipient on Ethereum.

Transfer: Spoke Chain -> Spoke Chain

  • M Portal (Wormhole): Supported. This process involves burning tokens on the source Spoke and minting them on the destination Spoke, with a message relayed via Wormhole.
  • M Portal Lite (Hyperlane): Not Supported. The system is strictly Hub-and-Spoke. To move assets between spokes, a user must first bridge back to the Hub (Ethereum) and then out to the new Spoke chain.