Interop Bridge

note

Status: Design phase. Depends on: L1/L2 Node (Phases 1–3), Modular TX Pipeline, EIP-8141 Frame Transactions (Phase 3+).

The Interop Bridge enables cross-L2 interoperability based on the EIL (Ethereum Interop Layer) protocol. It is an add-on service component for the L1/L2 Node — a separate goroutine that observes chain state and injects EIP-8141 frame transactions into the local mempool. It never touches block validation, state transitions, or commitment.

It follows the same non-consensus service pattern as Caplin, TxPool, and Sentry. All cross-chain semantics live in smart contracts executed by the EVM; the bridge service only decides which transactions to build and submit.

Key Capabilities

Wallet-centric cross-chain operations: A user signs one message covering operations on multiple L2s (a merkle tree of per-chain ops, single signature over the root). The bridge verifies the signature and merkle proofs, finds available liquidity providers, and assembles a frame transaction that executes atomically on each destination chain.

Non-consensus by design: The bridge service can be deployed, upgraded, or disabled without any consensus-critical changes. Frame transactions it submits go through the normal mempool and are executed by the EVM like any other transaction.

Combined-mode advantage: In combined mode, XLP state is read directly from the L1 database with zero latency. No RPC cache needed. Multi-chain solvency checks are atomic. The AutoDisputer can detect insolvent liquidity providers across all chains locally and submit slashing proofs to L1 directly.

Separation of Concerns

Consensus-critical path (mempool → builder → EVM → commitment):
  Knows about EIP-8141 frame txns, VERIFY/SENDER/DEFAULT modes, APPROVE opcode.
  Does NOT know about vouchers, XLPs, fee auctions, or cross-chain semantics.
  All cross-chain logic lives in smart contracts executed by the EVM.

Bridge service (non-consensus, separate goroutine):
  Observes chain state via chainReader.
  Decides: auction participation, dispute detection, relay routing.
  Injects frame transactions into the local mempool via txInjector.

Architecture

The bridge service is composed of six internal subsystems:

Subsystem	Purpose
`XLPRegistry`	Tracks Cross-chain Liquidity Providers (XLPs) and their stake on L1
`VoucherPool`	Lifecycle management for cross-chain vouchers
`AuctionBook`	Reverse Dutch auction — fee discovery for cross-chain operations
`FrameTxAssembler`	Builds EIP-8141 frame transactions from cross-chain operations
`CrossChainRelayer`	P2P gossip relay for cross-chain operations in L2-only mode
`DisputeResolver`	Detects insolvent XLPs and submits slashing proofs (combined mode only)

Key interfaces:

type XLPStateReader interface {
    GetXLPStake(xlp common.Address, chainId uint64) (*uint256.Int, error)
    IsXLPActive(xlp common.Address) (bool, error)
    GetSolvency(xlp common.Address) (*SolvencyReport, error)
}
// L1/Combined: reads directly from L1 DB. L2-only: remote RPC with cache.

type TxInjector interface {
    Submit(tx types.Transaction) error
}

Operating Modes

Active subsystems: L1StakeMonitor (indexes L1 XLP staking events), DisputeIndexer (tracks 8-day dispute windows).

RPC methods: interop_getXLPStake, interop_getActiveXLPs, interop_getDisputeStatus.

No cross-chain assembly or P2P relay in this mode — observation only.

Active subsystems: XLPCacheRefresher (polls L1 RPC for XLP state, refreshes per L1 epoch ~6.4 min), VoucherTracker, AuctionEngine, FrameTxAssembler, CrossChainRelayer.

L1 dependency: --interop.l1-rpc=http://... (remote, cached).

P2P relay gossips cross-chain operations to peer L2 nodes via new message types: CrossChainOpMsg, VoucherGossipMsg, XLPHeartbeatMsg. An "interop" ENR field advertises which chain IDs this node serves.

All L1 + L2 subsystems, plus:

Direct L1 DB reads — zero-latency XLP state, no RPC cache needed
Per-chain mempool injection — TxInjector routes to the correct chain's mempool
Atomic cross-chain solvency checks — all chain balances available locally
AutoDisputer — detects insolvent XLPs across chains and submits slashing proofs to L1 directly
No P2P relay needed — direct mempool injection across local chains

This is the combined mode's concrete advantage: zero-latency cross-chain state reads and atomic multi-chain operations.

Cross-Chain Operation Flow

User signs ONE message covering operations on multiple L2s
  → merkle tree of per-chain ops, single signature over the root

Bridge service receives via interop_sendCrossChainOps RPC:
  1. Verify merkle proofs for each op
  2. Verify single signature covers merkle root
  3. Check XLP registry for available liquidity providers
  4. Post voucher request to AuctionBook
  5. AuctionEngine claims if profitable (XLP mode)
  6. FrameTxAssembler builds type 0x06 frame transaction:
       frame[0] VERIFY:  validate(merkleRoot, proof, sig)
       frame[1] SENDER:  CrossChainPaymaster.lockFunds()
       frame[2] DEFAULT: user's actual call
  7. txInjector.Submit(frameTx) → local mempool
  8. Relay peer-chain ops via P2P (L2 mode) or direct injection (Combined)

Smart Contracts

The bridge service depends on deployed smart contracts. These are standard Solidity contracts — Erigon does not need to know about their semantics, only that they conform to the EIP-8141 frame transaction interface.

Contract	Chain	Purpose
`L1CrossChainStakeManager`	L1	XLP registration, staking, slashing, dispute resolution
`CrossChainPaymaster`	Each L2	Accepts vouchers, locks/releases funds
`MultichainAccount`	Each L2	Validates merkle proof signatures
`ETHLiquidity`	Each L2	XLP liquidity pool

Development Plan

Phase	Scope	Prereqs
1	Service skeleton + L1StakeMonitor (index-only)	L1/L2 Node Phase 1
2	VoucherTracker + XLPRegistry cache	L1/L2 Node Phase 3 (L1DataSource)
3	FrameTxAssembler + TxInjector	EIP-8141 in mempool + EVM
4	AuctionEngine	Bridge Phase 3, testnet contracts
5	CrossChainRelayer (P2P gossip)	L1/L2 Node Phase 2 (L2 P2P)
6	Combined mode coordination	L1/L2 Node Phase 3 + Bridge Phase 4
7	AutoDisputer (combined mode only)	Bridge Phase 6

Critical path: EIP-8141 is the long pole — Bridge Phases 3–4 cannot start without frame transaction support in the mempool and EVM. Phases 1–2 and 5 can proceed independently.

Key Capabilities​

Separation of Concerns​

Architecture​

Operating Modes​

Cross-Chain Operation Flow​

Smart Contracts​

Development Plan​