Interop Bridge

Non-consensus cross-L2 bridge service implementing the Ethereum Interop Layer protocol

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

L1 Mode

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.

L2 Mode

Combined Mode

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.