Skip to main content

Multichain Architecture

MAGMA uses a hub-and-spoke multichain model. All oracle resolution, conviction scoring, Forge distributions, and Echo Pool mechanics happen on Solana — the canonical settlement hub. Users on other chains commit capital through spoke contracts that communicate with the Solana hub via bridge protocols.

This design means:

  • Oracle resolution is always on Solana, using the same M-of-N consensus regardless of which chain the backer is on.
  • Conviction Score and Eruption Streak accumulate on Solana regardless of where capital came from.
  • The Forge, Seam, Core, and Echo pools all live on Solana.
  • EVM and TRON backers receive settlements routed back to their chain after Solana resolution.

Chain groups​

Group A — Solana and SVM chains​

SVM-compatible chains use the same Anchor programs, the same IDL, and the same wallet adapter as Solana. No new wallet integration is needed — existing Phantom / Solflare / Backpack connections work for all of them. The only change is the RPC endpoint.

ChainStatusGas tokenNotes
Solana mainnetLive (devnet)SOLCanonical hub
EclipseV2ETH (bridged)SVM chain
SOONV2ETH (bridged)SVM chain
SonicV2SOLSVM chain

Deploying to an SVM chain requires only: deploy the existing Anchor programs to that chain's RPC, register the new program IDs, and update the backend's RPC routing — roughly 2–3 days of effort per chain once Solana mainnet is stable.

Group B — EVM chains via Chainlink CCIP​

EVM chains use LockVault.sol contracts. When a user backs a narrative from Base or Arbitrum, their capital enters the LockVault on that chain. When oracle resolution completes on Solana, a Chainlink CCIP settlement message is sent to the LockVault, which distributes funds accordingly.

ChainStatusYield protocolCCIP status
BaseV2 (Base Sepolia testnet ready)Morpho BlueLive
ArbitrumV2Morpho BlueLive
OP MainnetV2Morpho BlueLive
BNB ChainV2Morpho BlueLive
HyperEVMV2Felix (Liquity V2 fork)Verify at docs.chain.link
MonadV3TBDVerify at docs.chain.link
BerachainV3TBDVerify at docs.chain.link
MegaETHV4TBDV4 only
Why Chainlink CCIP and not LayerZero

Following the April 2026 KelpDAO exploit ($292M lost via compromised single-verifier LayerZero infrastructure), MAGMA permanently switched to CCIP. CCIP runs two completely separate verification networks (a Committing DON and an Executing DON) plus an independent Risk Management Network, making the single-point-of-failure attack architecturally impossible. See the CCIP decision article for the full rationale.

Group C — TRON via Wormhole​

TRON uses Wormhole for bridge messaging, not CCIP — CCIP does not support TRON. TRON backing is USDT-TRC20 only: no ETH, no TRX, no USDC.

ChainStatusBacking tokenBridgeYield
TRON mainnetV3USDT-TRC20WormholeJustLend (50% cap)

V3 activates only after EVM mainnet has been live and stable for 3+ months and has passed a separate TronLockVault.sol audit.

The LockVault architecture (EVM)​

Each EVM chain has one LockVault.sol contract that:

  1. Accepts user deposits (ETH or USDC, depending on chain).
  2. Routes capital to Morpho Blue yield vaults immediately on deposit.
  3. Records the backing via backend confirmation.
  4. Receives settlement messages from Solana via CCIP after oracle resolution.
  5. Distributes funds to backers after a 48-hour timelock following settlement-message receipt.

The 48-hour EVM timelock mirrors the Solana challenge window, so users can dispute an incorrect resolution during the same period.

Supported EVM chains at mainnet​

CCIP chain selectors for the V2 set (verify others at docs.chain.link):

ChainVersionCCIP chain selector
BaseV215971525489660198786
ArbitrumV24949039107694359620
OP MainnetV23734403246176062136
BNB ChainV211344663589394136015
HyperEVMV2Verify at docs.chain.link
MonadV3Verify at docs.chain.link
BerachainV3Verify at docs.chain.link
MegaETHV4Verify at docs.chain.link

Base Sepolia testnet addresses​

ContractAddress
LockVault0x5501A1bcCfF02825138EbFA379C39A8db2343f71
ForgePool0xe85314D7bF6D70b43788BC46E771F5c95B0e9108
SeamPool0x18246618911550b813b3A9733dd1ac7Ab476fCf1
CorePool0x7c8Cc90B7620C43dbb3B8F1c220e6bf4F02572Db

Net-settlement coordinator (Model A)​

The hub-and-spoke flow above is the locked cross-chain design MAGMA calls Model A — chain-local custody: a bettor bets in USDC on their own chain, that USDC never leaves that chain, and only data crosses to Solana, where the coordinator computes canonical odds, resolves once, and sends settlement instructions back. Winners are paid locally, from local custody. On-chain this is the magma_ccip_coordinator program.

  • Only data crosses on the betting path. CCIP carries messages only — deposit notifications, per-chain pool sizes, yield reports, settlement instructions. The coordinator's ccip_receive hard-rejects any inbound tokens (require!(message.token_amounts.is_empty()) — the Model A "data only" invariant), so no individual bet's collateral is ever bridged.
  • One global outcome, one global payout ratio. The coordinator aggregates every chain's YES/NO pools into a single canonical price and pays every winner at the same global ratio, regardless of which chain they bet on — liquidity is never fragmented per chain.
  • Net-settle once. Because a two-sided market split across chains won't leave each chain's local pool balanced, each chain is either a surplus chain (holds more forfeited loser-stake than it owes local winners) or a deficit chain. The coordinator moves only that imbalance — one batched CCIP token transfer per chain-pair, once per market, never per bet. This NET_SETTLE leg is the only token-carrying message; every other dollar is paid in local USDC from local custody.
 At resolution — per market (illustrative):
   Surplus chain   ── holds +$40 more loser-stake than it owes winners ──┐
   Deficit chain X ── owes its winners $25 more than it holds            │  coordinator nets
   Deficit chain Y ── owes its winners $15 more than it holds            │  the imbalance once
                                                                         ▼
   Netted transfers (one per chain-pair, once per market):  → X: $25 ,  → Y: $15

Provably solvent, host-tested​

The settlement math (net_settlement.rs) is pure, deterministic Rust covered by host unit tests. It enforces a solvency invariant so no deficit chain is ever left short:

sum(transfers) == total_deficit == total_surplus − residual_dust

The protocol fee is taken only from a winner's net profit (never principal) and capped at 20% (MAX_FEE_BPS = 2000); integer-division dust is floored in the safe direction, so rounding can only ever leave a tiny residual on the surplus side — never underpay a winner.

Built + host-tested — not yet wired live, not audited

The coordinator's net-settlement math and anti-double-claim ledger are built and host-unit-tested, and the program bytecode exists on devnet — but the live omnichain path is not operational: the CCIP Router CPI is emit-only until live account metas are supplied, the backend relay is a stub that nothing invokes yet, and the EVM gateway's authorized Solana source is still unset. Nothing here is audited. Native markets run per-chain-solvent on Solana today; cross-chain net-settlement is a launch-phase deployment step (rollout is Base-first, gated on live Solana↔chain CCIP lanes). Only the NET_SETTLE leg ever moves value, and only between MAGMA's own per-chain custody vaults.

Wallet requirements per chain type​

Chain groupWallet
Solana + SVM (Eclipse, SOON, Sonic)Phantom, Solflare, Backpack — existing connection works
EVM chainsMetaMask, Coinbase Wallet, Rainbow — via Privy (WalletConnect v2)
TRONTronLink — separate integration, V3 only

Echo Pool cross-chain​

The Echo Pool lives on Solana. For EVM and TRON backers to earn Echo tickets, they must have a linked Solana wallet — the backend maps EVM/TRON backing to a Solana wallet for ticket issuance. This wallet linking is enforced during onboarding for EVM-chain users.

RPC endpoints​

RPC endpoint addresses are available in the MAGMA app settings and via the SDK configuration. Public chain RPC endpoints are documented at each chain's official developer portal:

Functional status

At beta, Solana is the only functional chain. EVM deposit/withdraw flows activate when LockVault contracts are deployed to mainnet; the web app already exposes chain switching across the full target set. See Security for the current beta scope.