concept hybrid I2I + I2U
EIL (Ethereum Interoperability Layer)
Account-based cross-L2 interoperability where users sign once and execute transactions directly on multiple chains. Crosschain Liquidity Providers supply gas and liquidity via optimistic atomic swaps anchored in an L1 staking contract, but never execute calls on the user's behalf. Dispute resolution on L1 ensures funds cannot be lost or stolen.
CR
High
Censorship Resistance
O
Yes
Open Source
P
None
Privacy
S
High
Security
CROPS context
I2I
Between institutions, both counterparties have legal recourse and symmetric trust. Visible call targets and amounts across chains are tolerable given bilateral confidentiality agreements; the value is atomic multi-chain execution without custody intermediaries. Liquidity providers take on slashing risk under L1-enforced dispute rules, so no counterparty depends on operator honesty.
I2U
The user is asymmetric to any liquidity provider. The L1 dispute mechanism must guarantee funds cannot be stolen regardless of provider behavior; the user's unilateral exit must not require provider cooperation. Public UserOp contents expose end-user activity to MEV extraction and surveillance, making encrypted submission a priority for user-facing deployments.
Works best when
User needs to execute calls on multiple L2s with one signature.
Assets scattered across chains need to be used without bridging friction.
No gas on destination chain but funds available on source chain.
Avoid when
Contract-to-contract composability required (use crosschain messaging instead).
High-level intent without knowing specific contract calls (solvers better suited).
Institutional-scale transfers requiring immediate economic finality.
Intent
Account-based cross-L2 interoperability where users sign once and execute transactions directly on multiple chains. Crosschain Liquidity Providers supply gas and liquidity via optimistic atomic swaps anchored in an L1 staking contract, but never execute calls on the user's behalf. Dispute resolution on L1 ensures funds cannot be lost or stolen.
Components
- ERC-4337 account with multichain validation module signs a Merkle root over the set of UserOps, letting one signature authorize calls across many chains.
- CrossChainPaymaster contracts on each L2 accept vouchers from liquidity providers, pay gas, and release funds on the destination.
- L1CrossChainStakeManager tracks liquidity provider registrations and stakes, with an 8-day unstake delay.
- Liquidity providers stake on L1 once per network and quote fees via reverse Dutch auction; stake sizing is O(networks), not O(funds moved).
- P2P UserOp mempool propagates signed intents and vouchers permissionlessly.
- L1 canonical bridge serves as the arbiter for disputes when a liquidity provider misbehaves.
Protocol
1
[user] Discover registered liquidity providers operating on both source and destination chains. 2
[user] Sign a multichain UserOp. On the source chain, lock funds in the CrossChainPaymaster and request a voucher specifying provider list and fee schedule via reverse Dutch auction. Funds unlock automatically if no voucher arrives promptly. 3
[operator] A liquidity provider claims the source-chain funds by submitting a signed voucher. The same voucher releases provider funds on the destination. Source funds remain locked for one hour before crediting the provider's deposit. 4
[user] Append the provider voucher to the destination UserOp signature and submit to the destination chain. 5
[contract] Destination CrossChainPaymaster verifies the voucher, checks provider deposits, pays gas, and releases funds to the user. 6
[user] Calls execute on the destination. The same signature can traverse any number of additional L2s using more vouchers. 7
[contract] If a provider misbehaves, the L1 dispute mechanism slashes the violating stake and rewards any other provider that supplies a violation proof. Guarantees & threat model
Guarantees:
- Censorship resistance via a permissionless mempool where a single honest node is sufficient to propagate intents.
- No trusted intermediaries: users execute their own calls, and disputes resolve on L1.
- Inherits the security of each underlying chain. Providers cannot steal funds, only face slashing risk.
- One signature authorizes operations across all involved chains.
- Latency matches the slowest underlying chain.
Threat model:
- Requires the same account implementation or a compatible validation module on every involved chain.
- Requires the same signing key on every chain until an L1 keystore with L1SLOAD is available.
- Capital efficiency cost: one-hour fund lock on the source chain after voucher issuance.
- Reorg risk on destination chains with frequent reorganizations; a deep reorg can invalidate a voucher redemption.
- Out of scope: application-layer confidentiality. Call targets, amounts, and account identities are all visible.
Trade-offs
- Not suitable for contract-to-contract composability. The model is account-based only.
- ERC-4337 bundler overhead persists until EIP-7701 (Native AA) adoption.
- Dispute mechanism adds complexity compared to simple bridges; wallets must track open vouchers and their dispute windows.
- Requires wallet-side coordination to discover providers and construct cross-chain Merkle roots before signing.
Post-quantum
medium risk Vector: Signature schemes used by ERC-4337 accounts (ECDSA, BLS) are broken by a CRQC. HNDL risk is low since UserOp contents are public and non-confidential.
Mitigation: Migrate account validation modules to post-quantum signatures (hash-based or lattice-based) once standardized in EIPs.
Example
A user wants to mint a 1 ETH NFT on one L2. They hold 0.8 ETH on a second L2 and 0.5 ETH on a third. The wallet builds three UserOps (two transfers and one mint), signs the Merkle root once, and two liquidity providers supply vouchers on the source chains. Funds atomic-swap to the destination, the mint executes, and the whole flow settles within seconds.
Open-source implementations