A Modular Execution Environment (MEE) is an execution layer that processes ERC-4337 UserOperations across multiple blockchains from a single smart account. Rather than requiring a separate account deployment and signature on every chain, MEE infrastructure coordinates cross-chain nonces, gas payments, and transaction batching so a user signs once and the MEE layer handles the rest. Biconomy Fusion and Rhinestone are among the early providers building this infrastructure, with Biconomy's Fusion network launching on mainnet in late 2024 across seven EVM chains.
​

By Eco research. Updated April 2026.
​

A Modular Execution Environment is the cross-chain execution layer for ERC-4337 smart accounts. It receives signed UserOperations, coordinates gas payments on each destination chain, manages cross-chain nonce sequencing, and batches or orders transactions to satisfy the user's intent. The "modular" label means the execution logic plugs into ERC-7579 modular smart account architectures as swappable modules, rather than being locked into a single proprietary account contract.
​

The concept addresses a specific structural gap in account abstraction infrastructure. ERC-4337 introduced smart accounts and bundlers in 2023, but each deployment is scoped to one chain. A user who wants to execute a DeFi position on Base, Arbitrum, and Optimism in a single workflow must maintain funded accounts on all three networks, sign three separate UserOperations, and track three independent nonce sequences. MEE providers abstract that complexity behind a single signing event: the user expresses intent, and the MEE handles chain-by-chain orchestration.
​

The execution environment typically consists of three components working together. The first is a cross-chain intent parser, which translates a user's high-level instruction ("swap USDC on Base, deposit proceeds into Aave on Arbitrum") into chain-specific UserOperations addressed to each chain's bundler pool. The second is a gas abstraction module, which funds the user's account on destination chains through a gas pool or paymaster contract when the user holds no native gas token there. The third is a nonce sequencer, which assigns an ordered nonce to each sub-operation and enforces dependencies between chains when one operation must complete before another starts.
​

The modular design is not incidental. ERC-7579, ratified in 2024, standardized how validator modules, executor modules, and hook modules attach to smart accounts. MEE providers implement the executor module interface, meaning their execution logic attaches to any ERC-7579-compliant account without modifying the account's core contract. An operator who built their account on Biconomy's Nexus can switch to a different MEE executor later by uninstalling one module and installing another. The account address stays the same; no fund migration occurs.
​

The result is an infrastructure primitive that separates three concerns previously bundled together: who owns the account (the user), who verifies transactions (the validator module), and who orchestrates cross-chain execution (the MEE executor module). This separation is what allows the MEE market to be competitive, with providers like Biconomy Fusion and Rhinestone building on a shared account standard rather than walled gardens.
​

An MEE receives a signed UserOperation bundle, identifies which destination chains are required, constructs chain-specific sub-operations, funds gas on each chain when needed, and submits each sub-operation to that chain's bundler pool. The provider tracks confirmation events across all chains and resolves the top-level operation as complete only when every sub-operation finalizes. The user sees a single receipt, not a per-chain status feed.
​

The full transaction flow breaks into five stages. The first stage is intent capture. The user signs a high-level operation targeting their smart account. That operation might say: "using 500 USDC from my Base account, enter a long ETH position on Arbitrum's GMX and stake the remainder into a liquidity pool on Uniswap V3 on Optimism." The signed payload references the user's account, a nonce, and the MEE executor's address, but contains no chain-specific transaction formatting.
​

The second stage is decomposition. The MEE's intent parser splits the signed payload into three separate UserOperations: one for the Base USDC transfer, one for the Arbitrum GMX deposit, and one for the Optimism Uniswap stake. Each UserOperation carries the user's smart account address on that chain, the encoded call data for the target contract, and a fee budget. The parser also resolves ordering constraints: the Arbitrum operation cannot execute until the Base transfer confirms, because the funds are only available after the bridge settlement.
​

The third stage is gas provisioning. The user's account may hold ETH on Base but not on Arbitrum or Optimism. The MEE gas abstraction module checks the destination chain accounts and determines whether each has sufficient gas. If not, the module routes a gas prepayment through a paymaster contract that fronts the native gas on the destination chain and bills the user from a shared stablecoin balance. Biconomy's Fusion paymaster handles this billing across seven EVM chains as of Q1 2026.
​

Stage four is nonce sequencing. ERC-4337 smart accounts track a nonce per chain to prevent replay attacks. When a user submits a multi-chain bundle, the MEE sequencer maps the global bundle nonce to the per-chain account nonce on each network. If two sub-operations target the same chain, the sequencer assigns them sequential nonces. If a sub-operation on chain B depends on a result from chain A, the sequencer holds the chain B operation in a staging queue until it receives the chain A confirmation event from the MEE's chain monitoring system.
​

The fifth stage is bundler submission. Each chain-specific UserOperation is submitted to that chain's ERC-4337 alt mempool. A bundler on the destination chain picks it up, packs it with other UserOperations into a single transaction, and submits to the EntryPoint contract deployed on that chain. The EntryPoint validates the UserOperation against the smart account's validator module, executes the call data, and emits a confirmation event. The MEE monitors confirmation events from each chain's EntryPoint and marks the bundle complete when all sub-operations finalize within the bundle's validity window.
​

Failure handling is where providers differ. If one sub-operation times out, the MEE can resubmit with higher priority gas, surface an error to the user, or submit compensating transactions to revert partial state. Users building production workflows on MEE infrastructure should verify the provider's failure policy before deployment.
​

A standard ERC-4337 bundler operates on one chain only. It collects UserOperations from multiple users, packs them into a single transaction, and submits that transaction to the chain's EntryPoint contract. MEE adds three capabilities that a bundler never provides: cross-chain coordination across multiple chains, gas abstraction that provisions funds on chains where the user has no balance, and nonce management that orders operations with dependencies across networks.
​

The difference matters because bundlers and MEE providers optimize for different problems. A bundler reduces gas cost per user by batching multiple operations into one transaction, so each user pays a fraction of the base transaction overhead. The bundler's job ends when the transaction lands onchain. An MEE's job spans the entire execution lifecycle across multiple chains: it owns the gas, the ordering, and the completion guarantee. These are complementary roles, not competing ones. An MEE still submits to bundlers on each destination chain; it is not a bundler replacement but a coordination layer above the bundler tier.
​

The table below shows the full capability comparison across a single-chain bundler, manually managed multi-chain smart accounts, and an MEE provider.
​

This comparison explains why MEE is not simply "a bundler that knows about multiple chains." The gas abstraction and nonce coordination layers are net-new infrastructure that does not exist in any bundler software, including the reference implementation maintained by the eth-infinitism team.
​

ERC-7579 defines the module interface standard for smart accounts. It specifies exactly how validator modules, executor modules, hook modules, and fallback handlers attach to a smart account, letting MEE providers plug their execution logic into any compliant account without owning the account contract. Without this standard, every MEE provider would need to ship its own account implementation, and users who wanted to switch providers would face fund migrations and address changes.
​

ERC-7579, authored by developers including zeroknots, konradkopp, and leekt, was finalized in 2024. It defines four module types with distinct permission boundaries. Validators approve or reject individual transactions by checking signature validity or custom conditions. Executors initiate transactions on behalf of the account, which is the role an MEE takes. Hooks run before and after execution to enforce invariants or perform side effects. Fallback handlers route calls that the account contract does not natively handle.
​

The executor module role is precisely scoped. An MEE installed as an executor can initiate transactions on the account but cannot withdraw funds arbitrarily. The executor's permissions are limited to the call data specified in the submitted UserOperation. This permission model is analogous to how OAuth delegated authorization works: the MEE has a specific, revocable scope, not blanket access. Users who no longer want a specific MEE provider can uninstall the executor module from their account in a single transaction, and the provider loses all execution rights immediately.
​

Rhinestone, a prominent ERC-7579 infrastructure provider, maintains an open ModuleKit repository on GitHub with tooling for building, testing, and deploying ERC-7579 modules. Rhinestone also operates a module registry where modules are audited and verified before listing, addressing the trust question that arises when users grant executor rights to third-party code. As of Q1 2026, the registry lists over 30 modules across validator, executor, and hook categories.
​

The practical effect of ERC-7579 for MEE adoption is that the market can be competitive without fragmenting account addresses. A developer who builds on Safe's modular account, Biconomy's Nexus, or ZeroDev's Kernel can switch MEE providers without migrating funds, because all three accounts implement the same ERC-7579 interface. This portability lowers switching costs and creates pressure on MEE providers to compete on reliability, chain coverage, and fee efficiency rather than account lock-in.
​

MEE infrastructure enables cross-chain DeFi execution from a unified account, automated treasury rebalancing across chains, chain-agnostic wallet UX, and stablecoin payment flows where users never select a network. Consumer app developers can remove the "select network" step that currently breaks user flows; institutional tool builders can route treasury operations across 15 or more chains without building per-chain orchestration code.
​

Cross-chain DeFi is the primary use case driving current MEE adoption. Consider a user who holds USDC on Ethereum mainnet and wants to provide liquidity in Aerodrome Finance's Base pool while also depositing into Aave's Arbitrum lending market. Without MEE, this requires two wallets, two gas token balances, two separate signing sessions, and manual tracking of both positions. With an MEE that supports Ethereum, Base, and Arbitrum, the user signs once. The MEE handles the USDC bridge, the Aerodrome LP deposit, the Aave deposit, and gas on all three chains from the user's USDC balance.
​

Automated position management is a second category that MEE enables at scale. Institutional treasury managers running stablecoin allocations across Hyperliquid, Solana, and EVM chains today must either run custom scripts that monitor positions and sign rebalancing transactions, or accept the latency of manual rebalancing. MEE hook modules can trigger executor actions when onchain conditions are met: if an Aave position's health factor on Arbitrum drops below 1.5, automatically move reserves from a Curve pool on Optimism to replenish collateral. The trigger is onchain data; the execution is coordinated by the MEE without user intervention after initial setup.
​

Gas abstraction opens a third category: payment apps and consumer wallets where users hold only stablecoins and never acquire native gas tokens. Today, users must hold ETH on each EVM chain they use, which creates friction for anyone new to a specific network. An MEE paymaster covers gas on every supported chain and deducts the cost from the user's USDC or USDT balance. Biconomy's Fusion paymaster supports this model on Base, Arbitrum, Optimism, Polygon, BNB Chain, and two additional EVM chains as of late 2024.
​

The DeFi ecosystem relies on users managing positions across multiple protocols and chains. MEE infrastructure reduces the operational overhead of that management from N separate signing sessions to one, which broadens the accessible user base to anyone who can hold a smart account, including users whose primary identity is a passkey rather than a raw private key.
​

Infrastructure providers that route stablecoin transfers across chains, like Eco, integrate with MEE execution layers when payment flows involve smart account-native transactions on multiple networks. When a payment requires a smart account on Base to complete a settlement on Arbitrum, MEE-style coordination handles the sequencing without requiring the end user to manage chain-specific accounts or gas.
​

Most current MEE implementations do not guarantee atomicity across chains in the strict computer science sense. They provide best-effort, ordered coordination with failure detection: if a sub-operation fails, the MEE surfaces an error and may attempt rollback via compensating transactions, but there is no instant cross-chain rollback mechanism that can undo a confirmed transaction on chain A when chain B fails. True atomic cross-chain execution requires infrastructure that does not yet exist at production scale as of Q1 2026.
​

Distributed systems atomicity requires either a two-phase commit (lock resources on all chains, then commit) or an intent-settlement layer that holds funds in escrow until the full multi-chain outcome is verifiable. Most current MEE infrastructure uses intent-settlement: funds are pre-committed to a solver or escrow, and settlement occurs when the solver proves delivery. This is the same model that Across uses for single-hop asset transfers, extended to multi-hop execution workflows.
​

The practical risk from non-atomicity is scenario-specific. A two-step workflow (bridge to chain B, then deposit) has different failure characteristics than a three-step workflow (bridge from A to B, swap on B, bridge result from B to C). In the two-step case, if the deposit fails, the user has bridged funds sitting on chain B but no position. The MEE can detect this and attempt the deposit again, or return the funds to chain A. In the three-step case, partial completion on the middle chain creates a more complex recovery path, because the intermediate state involves both a completed bridge and a pending swap.
​

Progress toward stronger guarantees is tied to shared sequencer infrastructure. Espresso Systems' shared sequencer allows multiple rollups to order transactions together before finalizing separately. Once integrated with MEE providers, a bundle could specify that chain A and chain B operations are both included in the same ordered block or neither is. This ordered-atomicity is weaker than ACID atomicity but stronger than best-effort coordination. As of Q1 2026, these integrations remain experimental.
​

MEE security depends on the smart account's access control, the executor module's code correctness, and the MEE provider's infrastructure reliability. The executor module installation step carries the highest risk: installing a module grants it the ability to initiate transactions from the account within the scope of the account's approvals. Rhinestone's registry mitigates this by requiring module audits before listing, but registry participation is opt-in. Users installing modules from outside the registry accept unaudited code risk.
​

Nonce management introduces a subtler risk. Cross-chain nonce sequences are maintained by the MEE provider off-chain until sub-operations are submitted. If the MEE provider's sequencer is misconfigured, out-of-order nonce submissions will cause transactions to revert. The EntryPoint contract handles nonce enforcement onchain as the final authority, but sequencer bugs can cause wasted gas before the onchain check catches the error.
​

Key management at the paymaster level is also material. Bundler operators hold no user funds, so a bundler compromise affects uptime. An MEE provider that operates a gas pool holds capital to cover cross-chain gas fronting. Users should verify that the paymaster contract is audited before relying on it in production workflows. The non-custodial wallet model underlies all MEE security analysis: the user's private key never leaves their device, and revoking the executor module in a single transaction immediately terminates the MEE provider's execution rights.
​

MEE providers, cross-chain intent protocols, and traditional bridges address related problems at different abstraction levels. Intent protocols like Across and LI.FI focus on asset transfer and swap routing across chains; MEE providers focus on smart account execution coordination. Bridges move tokens; MEE providers orchestrate UserOperations. The defining difference is the abstraction level: bridges work at the token transfer layer, MEE providers work at the account execution layer where contract calls, not just token transfers, are the unit of work.
​

The practical boundary is: if the task is moving USDC from Base to Arbitrum, a bridge or intent protocol handles it. If the task is moving USDC and then calling a contract with the proceeds, from a smart account with no Arbitrum gas, triggered by a single user signature, that is MEE territory. The MEE may call a bridge internally as one step of the execution plan, but the coordination and gas management are MEE responsibilities, not bridge responsibilities.
​

Some intent protocols are developing MEE-like capabilities. LI.FI added smart account support in 2024, and Jumper Exchange routes cross-chain swaps through smart accounts on EVM chains. The distinction between an advanced intent protocol and an MEE provider is narrowing, but the underlying ERC-4337 UserOperation format and ERC-7579 executor module architecture differentiate true MEE infrastructure from intent-layer additions that use smart accounts as a UX improvement rather than as a core execution primitive.
​

Account abstraction via EIP-7702 introduces a third category: smart accounts created by temporarily upgrading an EOA's code, rather than deploying a separate smart account contract. EIP-7702 wallets could theoretically use MEE infrastructure if the upgraded code implements the ERC-7579 executor interface, but as of Q1 2026, MEE providers target dedicated ERC-4337 smart accounts, not EIP-7702 upgraded EOAs.
​

For a broader view of how cross-chain communication standards underpin both bridges and MEE infrastructure, see the article on blockchain interoperability and cross-chain communication.
​

An ERC-4337 bundler operates on one chain, packing multiple users' UserOperations into a single transaction submitted to that chain's EntryPoint contract. An MEE coordinates UserOperations across multiple chains, manages cross-chain nonce ordering, and abstracts gas on each destination chain. See the full ERC-4337 explainer for bundler mechanics and the EntryPoint role.
​

Not necessarily. MEE providers that comply with ERC-7579 install as executor modules on an existing modular smart account. The user keeps the same account address across chains. Wallets that do not yet support ERC-7579, including most current EOA-based wallets, require migration to a compatible smart account before MEE execution is available.
​

MEE providers maintain cross-chain gas pools or partner with paymaster services that front native gas on destination chains. The cost is deducted from the user's stablecoin balance or invoiced from a shared account. This extends the same gas-sponsorship model that ERC-4337 paymasters introduced for single-chain accounts to the full cross-chain execution lifecycle.
​

No. MEE is an execution layer that processes transactions on behalf of a smart account. The smart account is non-custodial: the user's private key controls the account. The MEE provider holds delegated executor rights via an ERC-7579 module, revocable at any time, and cannot move funds outside the scope of an authorized UserOperation. See the article on non-custodial wallets for the custody model distinction.
​

Some MEE providers are extending to non-EVM environments. Solana uses program-derived addresses and a different transaction model, not ERC-4337 UserOperations, so full MEE parity requires chain-specific adapters. As of Q1 2026, EVM chain coverage is production-ready across providers; Solana and other SVM chains are in active development, with Biconomy and Rhinestone both publishing roadmap timelines for SVM support.
​

Sources and methodology. ERC standard texts verified against eips.ethereum.org as of April 2026. Provider capabilities sourced from official Biconomy and Rhinestone documentation and press releases. ERC-7579 module standard verified from the EIP text. EntryPoint contract source verified from eth-infinitism/account-abstraction. All protocol statuses as of Q1 2026.
​