The EIL SDK is the developer-facing wrapper around Ethereum’s new Interoperability Layer, giving you a way to script multi-chain operations (transfers, swaps, gas payments) as a single logical flow rather than a pile of per-chain transactions. Launched around Devconnect Buenos Aires and showcased at the trustless interoperability workshops, it sits on top of the EIL protocol that aims to unify Ethereum’s fragmented L2 landscape under a single, account-based model.
What problem the EIL SDK is trying to solve
Today, any serious Ethereum user lives on several rollups at once. Assets and approvals are scattered across Base, Arbitrum, Optimism and friends. Moving value or running a strategy across them usually means:
- juggling a different smart account instance per chain
- wiring yet another bridge or RPC provider
- signing the same intent repeatedly, one network at a time
The EIL protocol tackles this by defining a trust-minimised way to:
- move assets between L2s using atomic swaps with cross-chain liquidity providers (XLPs),
- pay gas on destination chains using funds on a source chain, and
- execute user operations across chains from a single “multichain” account and signature.
The EIL SDK packages that machinery into a TypeScript library that hides most of the plumbing: developers describe what they want to happen on each chain; the SDK deals with user operations, vouchers, provider selection and execution order.
Inside the EIL SDK: accounts, batches and vouchers
At its core, the EIL SDK is built around a small set of concepts:
• Multichain account
You start by creating a multichain smart account, essentially one logical user spread across multiple ERC-4337 accounts, with the SDK tracking nonces and deployment state per chain. You give it an owner (a key or wallet interface), and the EIL SDK handles signing and verification for all chains in one go.
• Crosschain builder and batch builders
You then use a “crosschain builder” to construct the operation. For each chain involved you open a batch builder. A batch is simply: “these are the calls I want on chain X”. Under the hood, each batch becomes a single UserOperation for that chain.
Within a batch you add actions, for example:
- token transfers (using a multi-chain token object so you don’t hard-code per-chain addresses),
- arbitrary function calls on DeFi contracts, or
- special “voucher” actions that lock tokens on one chain and request them on another.
The idea is that you write the flow once; the EIL SDK worries about which address to use on which chain.
• Vouchers and cross-chain value
When you call the voucher action, you are telling the EIL protocol:
- lock this set of tokens on chain A,
- ask for a matching voucher on chain B,
- use those tokens on chain B to pay gas and fund the next batch.
Cross-chain liquidity providers watch for these requests, post a voucher, and are repaid (with a fee) via an atomic swap. From the SDK’s point of view, that complexity collapses into two steps:
- build and sign – prepare all UserOps and have the multichain account sign the Merkle root once;
- execute – run the sequence, waiting for vouchers where necessary and surfacing progress and failures through callbacks.
For more dynamic flows (for example, “swap on chain A, then send whatever I ended up with to chain B”) the EIL SDK exposes runtime variables. An action can read a value such as a post-swap balance into a variable; later actions and vouchers reference that variable rather than a hard-coded amount.
Where the EIL SDK fits for wallets and apps
The EIL SDK is designed for two rather different audiences.
For dApp developers, it is a cross-chain orchestration layer. You describe the per-chain work as batches and actions, add voucher requests where value must move, and call the builder’s build-and-sign method. In the current samples this runs in a CLI or React front end; over time, the expectation is that wallets ship first-class support and handle the signing and execution loop themselves.
For wallet teams, it is a reference implementation of how to turn EIL’s protocol design into a concrete UX:
- one signature per multi-chain operation,
- gas abstraction via cross-chain paymasters and vouchers,
- clear progress reporting while the sequence moves between chains.
The result, if done properly, is that users see a single “do this across chains” confirmation, while the EIL SDK steers the mess of UserOps, vouchers and providers in the background.
Disclaimer: This article is for information and education only. It is not investment, legal, tax or financial advice.
