Architecture

System design, data flow, and bridge adapter layer behind the MNMX cross-chain routing protocol.

System Overview

MNMX sits between the user and the cross-chain infrastructure. It doesn't replace bridges — it searches across all of them to find the optimal path for each transfer.

Data Flow

1. Path Discovery

The PathDiscovery module enumerates all possible routes between source and destination:

• Direct bridges — Single-hop transfers via Wormhole, deBridge, LayerZero, etc.
• Multi-hop paths — Routes through intermediate chains when direct paths are suboptimal
• DEX combinations — Swap on source chain, bridge, swap on destination chain

For a transfer from ETH on Ethereum to SOL on Solana, this might produce 15–50 candidate paths depending on available bridges and intermediate chains.

2. State Collection

The StateCollector fetches real-time data for each candidate path:

3. Minimax Search

The routing engine constructs a game tree from the candidate paths and evaluates each under adversarial conditions:

1Route Tree:
2├── Path A: Wormhole direct (ETH → SOL)
3│   ├── Best case:  14.5 SOL  │  Worst case: 11.2 SOL  │  Minimax: 11.2
4│
5├── Path B: deBridge direct (ETH → SOL)
6│   ├── Best case:  14.8 SOL  │  Worst case: 12.1 SOL  │  Minimax: 12.1
7│
8├── Path C: Wormhole → Arbitrum → Jupiter (ETH → SOL)
9│   ├── Best case:  14.2 SOL  │  Worst case: 13.8 SOL  │  Minimax: 13.8 ← OPTIMAL
10│
11└── Path D: LayerZero → Base → Solana
12    ├── Best case:  13.9 SOL  │  Worst case: 12.5 SOL  │  Minimax: 12.5

Path C has the highest minimax score — it's not the best when everything goes right, but it has the best guaranteed minimum outcome.

4. Route Evaluation

Each path is scored across five weighted dimensions:

5. Route Execution

The RouteExecutor handles the multi-step execution:

1. Swap on source chain (if needed)
2. Initiate bridge transfer
3. Monitor bridge completion
4. Swap on intermediate/destination chain (if needed)
5. Verify final balance

Each step includes failure handling — if a bridge stalls or conditions change mid-execution, the engine can reroute through an alternative path.

Bridge Adapter Layer

Bridges are integrated as modular adapters. Each adapter implements a standard interface:

1interface BridgeAdapter {
2  name: string;
3  supportedChains: Chain[];
4
5  getQuote(params: QuoteParams): Promise<BridgeQuote>;
6  execute(quote: BridgeQuote, signer: Signer): Promise<BridgeResult>;
7  getStatus(txHash: string): Promise<BridgeStatus>;
8  getHealth(): Promise<BridgeHealth>;
9}

Adding a new bridge requires implementing the BridgeAdapter interface. The routing engine automatically incorporates new adapters into its path discovery — more bridges means more candidate paths means better optimization.

Design Decisions

Why aggregate instead of building a new bridge?

Bridges are commoditized infrastructure. Building another one adds no value. The value is in choosing the right bridge at the right time — and that's a search problem, not an infrastructure problem. MNMX treats bridges as interchangeable modules and focuses on the optimization layer above them.

Why optimize for worst case instead of expected value?

Expected value optimization assumes you know the probability distribution of outcomes. In cross-chain, you don't — bridge delays are unpredictable, MEV is adversarial, liquidity can drain between quote and execution. Minimax doesn't need probability estimates. It guarantees the best outcome under the worst conditions, which is the rational choice when uncertainty is high.

Why multi-hop routes?

Direct paths are often suboptimal. ETH → SOL direct via Wormhole might cost more than ETH → USDC on Uniswap → USDC bridge via deBridge → USDC → SOL on Jupiter. The extra hops add small fees but can avoid large slippage on illiquid direct pairs. The engine evaluates all combinations and picks the global optimum.