Magic Router: Automatic Transaction Routing Across ERs

Applications with a global user base, like trading platforms following market hours, DePIN with geographically distributed nodes, or games with regional match rooms, all benefit from Ephemeral Rollup dynamic colocation: users interact with the nearest ER for minimal latency. But node colocation means the application state must be delegated only to one specific regional instance. Some accounts stay on Solana. Others are delegated to an ER in Asia. Others to Europe. Others to the US.

For applications supporting only a handful of regions, this is manageable. But with tens or hundreds of ER instances, it becomes untenable. Without abstraction, developers must track delegation status per account, maintain connections to each regional endpoint, and implement routing logic for every transaction.

Magic Router eliminates this complexity for the most hardcore use cases. It's a single RPC endpoint that inspects transaction metadata and routes to the correct destination: Tokyo ER, Solana, Berlin ER, or any other instance, completely automatically. Developers connect once to the endpoint, and routing happens transparently.

This article explains how Magic Router works, the routing logic, edge cases, and integration patterns.

The Routing Problem

Consider a game with the following state structure:

• Player accounts: Delegated to ER for real-time position updates
• Inventory accounts: Delegated to ER for fast item transfers during gameplay
• Leaderboard account: Remains on L1 for global visibility
• Token accounts: Remain on L1 for composability with DeFi

Without routing abstraction, the client must:

1. Track which accounts are currently delegated
2. Route each transaction to the correct endpoint based on which accounts it touches
3. Handle edge cases when delegation status changes mid-session

Single Endpoint Architecture

Magic Router provides a single RPC endpoint that handles all routing decisions:

https://devnet-router.magicblock.app

Clients connect to this endpoint exactly as they would connect to a standard Solana RPC. The router accepts transactions, inspects their metadata, and forwards them to the appropriate execution environment.

import { Connection } from "@magicblock-labs/ephemeral-rollups-kit";

// Single connection handles both Solana and ER transactions
const connection = await Connection.create(
  "https://devnet-router.magicblock.app",
  "wss://devnet-router.magicblock.app"
);

// Send transaction - router determines destination automatically
const txHash = await connection.sendAndConfirmTransaction(
  transactionMessage,
  [userKeypair],
  { commitment: "confirmed", skipPreflight: true }
);

Routing Logic

Magic Router evaluates each transaction in three steps:

Step 1: Extract Writable Accounts

The router parses the transaction and extracts the list of accounts marked as writable. Read-only accounts don't affect routing - they can be read from either environment.

Transaction {
  instructions: [
    {
      program_id: "GameProgram...",
      accounts: [
        { pubkey: "PlayerA...", is_writable: true },   // Affects routing
        { pubkey: "PlayerB...", is_writable: true },   // Affects routing
        { pubkey: "GameConfig...", is_writable: false } // Ignored for routing
      ]
    }
  ]
}

Step 2: Check Delegation Status

For each writable account, the router checks whether it's currently delegated to an Ephemeral Rollup. An account is delegated if its owner is the Delegation Program (DELeGGvXpWV2fqJUhqcF5ZSYMS4JTLjteaAMARRSaeSh). If delegated, the router identifies the delegated validator identity and its Ephemeral Rollup endpoint based on the respective delegation record PDA created upon account delegation.

PlayerA: owner = DELeGGvXpWV2fqJUhqcF5ZSYMS4JTLjteaAMARRSaeSh → Delegated
PlayerB: owner = DELeGGvXpWV2fqJUhqcF5ZSYMS4JTLjteaAMARRSaeSh → Delegated

Step 3: Route Based on Delegation

The routing decision follows strict rules for each transaction:

The mixed-state failure is intentional. A single transaction cannot atomically modify accounts in different execution environments. If an application needs to update both delegated and non-delegated states, it must use separate transactions or restructure its account model.

Handling Edge Cases

Delegation Status Changes

Accounts can be delegated or undelegated during an application session. Magic Router checks delegation status at routing time, meaning:

• If an account was delegated but is now undelegated, transactions route to Solana
• If an account was on Solana but is now delegated, transactions route to ER

Applications should handle the case where routing behavior changes mid-session, typically by refreshing account state after delegation/undelegation operations.

Multiple ERs

An application might delegate different accounts to different regional ERs (e.g., Asia vs Europe validators). Magic Router handles this by routing to the specific ER where each account is delegated.

If a transaction touches accounts delegated to different ERs, it fails following the same logic as mixed Solana/ER transactions. Accounts that need to be modified atomically should be delegated to the same ER instance.

Program Accounts

Program accounts (executable = true) are never delegated. They remain on Solana and are cloned into ERs via JIT State Cloning when needed. This doesn't affect routing - the router only considers data accounts.

Consistent Latency, Anywhere

The VRF Dice Roll Demo demonstrates the result: users roll dice and experience consistent ~30-50ms latency regardless of where they're located, because they're automatically routed to their nearest regional ER.

A user in Singapore rolling dice:

• Transaction routes to Asia ER (devnet-as.magicblock.app)
• VRF generates verifiable randomness
• Result returns in ~35ms

A user in Frankfurt rolling dice:

• Transaction routes to Europe ER (devnet-eu.magicblock.app)
• Same VRF logic executes
• Result returns in ~40ms

Decentralization

Magic Router is also designed with decentralization in mind:

• Any RPC can implement routing: The routing algorithm is deterministic based on onchain delegation state defined in delegation record PDA
• No central coordination: Routers don't communicate with each other; they read delegation status from the delegation program on Solana
• Validators can run routers: ER validators can expose Magic Router endpoints alongside their validator RPC

This means routing doesn't introduce a centralization vector. Multiple independent routers can operate, and clients can choose which to use.

Summary

Magic Router abstracts the complexity of multi-environment execution:

1. Single endpoint: One RPC connection handles all transactions
2. Automatic routing: Transactions route based on the delegation status of writable accounts
3. Strict consistency: Mixed-environment transactions fail, preventing inconsistencies
4. Standard SDK compatibility: Works with existing Solana tooling

For developers building applications with global usage, Ephemeral Rollup integration becomes simpler: the routing logic, delegation tracking, and endpoint management are handled automatically.

Implementation resources:

• Magic Router Documentation — full API reference
• Magic Router Demo — interactive example
• Ephemeral Rollups SDK — client integration