​Bundler networks are the off-chain layer that turns ERC-4337 UserOperations into on-chain transactions. Instead of broadcasting to the public Ethereum mempool the way an EOA does, a smart-account UserOperation goes to a parallel mempool — the alt-mempool — where bundler nodes pick it up, validate it, package multiple UserOps into one Ethereum transaction, and submit that batch to the EntryPoint contract. The architecture is intentionally permissionless, but with strict validation rules that prevent denial-of-service against the bundler operators themselves.
​

This guide explains bundler networks at the level a developer or infrastructure engineer needs: the alt-mempool design, the off-chain validation rules, the economics of bundler operation, the mainstream operators who run them, and how the network behaves under stress. By the end you will know what storage-access rules a bundler enforces, why some UserOperations get dropped, who the major bundler operators are, and how an L2 bundler differs from an Ethereum mainnet bundler.
​

A bundler network is the set of nodes that listen for UserOperations, validate them off-chain, package them into Ethereum transactions, and submit those transactions on behalf of smart-account users. The network is permissionless — anyone can run a bundler — and decentralized only in the sense that no single party can prevent a UserOp from being included if at least one bundler chooses to honor it.
​

The reason the bundler exists is that ERC-4337 ships out-of-protocol. The Ethereum protocol does not natively understand UserOperations, separate validation logic, or paymaster sponsorship. Instead, the EntryPoint contract handles all of that on-chain, and the bundler handles the off-chain orchestration: which UserOps are valid, which are profitable to include, and how to pack them into a single regular transaction.
​

The full ERC-4337 spec is at eips.ethereum.org/EIPS/eip-4337. The reference bundler implementation list is maintained at eth-infinitism/account-abstraction. Multiple bundlers (Pimlico's Alto, Stackup's bundler, Voltaire) interoperate against the same EntryPoint, which is what makes the network usefully decentralized.
​

The alt-mempool is logically separate from the public Ethereum mempool. UserOperations do not propagate through Ethereum's eth_sendRawTransaction. Instead, smart-wallet clients submit to a bundler RPC endpoint via the eth_sendUserOperation method, defined in the ERC-4337 RPC spec.
​

What happens after submission depends on the bundler's policy. Most production bundlers maintain a private alt-mempool (their own pool of accepted UserOps) and forward to peers selectively. Some bundlers participate in a public alt-mempool where UserOps are broadcast to all participating bundlers — this is the closest the system gets to the public Ethereum mempool model, but it is opt-in.
​

The propagation pattern matters because it affects censorship resistance and inclusion latency. A UserOp submitted only to one private bundler is at the mercy of that bundler's uptime and willingness to include. A UserOp broadcast to a public alt-mempool is more censorship-resistant but exposes more information about pending operations to MEV searchers and potential front-runners.
​

By Q1 2026, the breakdown is roughly: private bundler mempools handle ~85% of UserOp volume, with public alt-mempools handling the remainder. The convention is that wallets submit to a primary bundler RPC, with fallback to a secondary bundler if the primary stalls.
​

Before a bundler accepts a UserOperation into its local mempool, it runs the UserOp's validation step off-chain to check that on-chain validation will succeed. This is necessary because ERC-4337 validation is arbitrary contract code — without simulation, the bundler would risk including a UserOp that reverts on-chain, leaving the bundler to pay the gas with no compensation.
​

To make off-chain simulation reliable, ERC-4337 imposes restrictions on what validation logic can do. The full list is in ERC-7562 (the ERC-4337 validation rules), but the high-level points are:

If a UserOperation violates any rule, the bundler drops it. The smart account can pass validation but still revert on the execution step — that risk is borne by the smart account owner (their gas is consumed) and does not penalize the bundler.
​

The bundler's lifecycle for a UserOperation is six steps.
​

Step 1: Receive. Wallet client calls eth_sendUserOperation on the bundler's RPC endpoint. The bundler returns a UserOperation hash for tracking.
​

Step 2: Off-chain validate. Bundler runs the UserOp's validateUserOp against the current chain state. If the UserOp uses a paymaster, also run validatePaymasterUserOp. Verify validation rules (no banned opcodes, no external storage reads).
​

Step 3: Add to local mempool. If validation passes, the bundler keeps the UserOp in its local pool, indexed by sender address and nonce. Each sender has limited pool capacity to prevent spam.
​

Step 4: Bundle. When the bundler decides to submit (typically once per block or once a profit threshold is met), it selects N UserOps from its pool, ordered by gas-price-per-gas-used to maximize fee revenue.
​

Step 5: Submit. Bundler constructs an Ethereum transaction calling EntryPoint.handleOps(userOps[], beneficiary) with the bundle. The bundler is the EOA that submits this transaction; it pays the gas upfront and gets reimbursed when the EntryPoint settles each UserOp.
​

Step 6: Re-bundle on revert. If a UserOp reverts during execution, the EntryPoint still pays the bundler for validation and the gas-up-to-revert. Bundlers re-validate any UserOps that did not finalize and either re-bundle them or drop them depending on the cause.
​

The lifecycle is fast — typically 1-2 blocks from submission to inclusion on L2s, 1-3 blocks on Ethereum mainnet. The bottleneck is not the bundler; it is the L1 or L2 block time itself.
​

Bundlers earn the spread between what UserOps pay and what the bundler's outer transaction costs in gas. The math is straightforward:
​

Per UserOp revenue = (UserOp gas price) × (UserOp gas used) + preVerificationGas × gasPrice
Per bundle cost = (Outer tx gas) × (gas price)
Net profit = Sum of UserOp revenues − Bundle cost
​

The preVerificationGas field exists specifically to compensate the bundler for off-chain validation work and the per-UserOp overhead of being included in a bundle. Bundlers reject UserOps with insufficient preVerificationGas; well-behaved wallet clients use bundler-provided RPCs (pm_sponsorUserOperation or similar) to estimate the right value.
​

At scale, bundler operation is a thin-margin business. BundleBear tracks per-bundler revenue. The major operators (Pimlico, Stackup, Coinbase, Alchemy) earn cumulative bundler revenue measured in the millions of dollars per year — substantial in absolute terms but small as a percentage of total gas paid by users.
​

Self-hosted bundlers operated by single dApps or wallets typically run at break-even or slight loss as an infrastructure cost, treating bundler ops as table-stakes for shipping a smart-wallet experience rather than a profit center.
​

Six operators dominate the network as of Q1 2026.
​

Pimlico. Largest by UserOp count, with roughly 38% market share. Open-sources Alto, the most widely-deployed open bundler implementation. Permissionless RPC access at api.pimlico.io, including a sponsored "permissionless bundler" anyone can use without an API key.
​

Coinbase. Roughly 22% market share, dominated by Coinbase Smart Wallet UserOps on Base. Tightly integrated with Coinbase's paymaster infrastructure for sponsored UX.
​

Stackup. Roughly 15% market share. One of the original ERC-4337 bundler implementations; runs hosted RPCs and offers a self-hostable bundler client.
​

Alchemy. Roughly 12% market share. Powers Account Kit and Embedded Accounts; bundler endpoints are part of Alchemy's broader RPC service.
​

Biconomy. Roughly 8% market share. Strong on Polygon, BNB Chain, and other L2s where their paymaster service is widely used.
​

ZeroDev. Roughly 5% market share. Bundler is part of the ZeroDev hosted SDK; some teams self-host with Alto and pair with ZeroDev's account contracts.
​

Plus a long tail of self-hosted bundlers run by individual dApps and wallets — exact share is hard to track, but estimated at 5-10% of total volume.
​

The bundler network behaves differently on L2s than on Ethereum mainnet, mostly because L2 gas is cheaper and block times are faster.
​

On Ethereum mainnet, the per-UserOp validation cost (~60,000 gas) is a non-trivial fraction of the total gas budget. Bundlers tend to bundle larger batches (5-10 UserOps per outer tx) to amortize the fixed overhead. Block time is 12 seconds, so inclusion latency is typically 12-24 seconds.
​

On L2s (Base, Arbitrum, Optimism, Polygon zkEVM), gas is sub-cent, block time is 2 seconds or less, and bundlers often submit smaller batches (1-3 UserOps) more frequently. Inclusion latency is typically 2-4 seconds. The economic incentive to wait for a larger batch is much weaker because the gas savings are small in absolute terms.
​

L2 bundler networks also tend to have more concentration in a few major operators. On Base specifically, Coinbase's bundler handles a majority of volume; on Arbitrum, Pimlico and Stackup split most volume. This is a feature of consumer apps converging on hosted bundler stacks rather than self-hosting.
​

The bundler network has several known failure modes that production operations need to plan for.
​

Bundler downtime. If your primary bundler stalls, UserOps queue locally on the wallet client. Mitigation: configure a fallback bundler. Most SDKs (Pimlico's Permissionless.js, ZeroDev SDK, Coinbase's Smart Wallet) support multi-bundler failover.
​

Mempool eviction. Bundlers cap per-sender pool depth. A user submitting many UserOps faster than they get included may see older ones evicted. Mitigation: throttle per-user submissions on the wallet side.
​

Validation rule violations. A poorly written smart account that reads external storage during validation will be rejected by all compliant bundlers. Mitigation: build smart accounts on audited reference implementations (Safe, Kernel, Coinbase Smart Wallet, Light Account) that comply by construction.
​

Paymaster failure. If a paymaster's deposit runs out mid-validation, the UserOp fails. Mitigation: monitor paymaster ETH balance, top up automatically, and degrade gracefully on the client side (fall back to user-paid gas if sponsorship is unavailable).
​

Cross-bundler censorship (theoretical). If all major bundlers refused to include a UserOp, the user would be effectively censored. In practice the diversity of operators plus the option to self-host or use the public alt-mempool makes this hard to engineer. The structural mitigation is network-level: more bundler operators means stronger censorship resistance.
​

For stablecoin and cross-chain products, two bundler-network properties matter most.
​

First, multi-chain bundler support. A stablecoin app that ships across Ethereum, Base, Arbitrum, Optimism, and Polygon needs bundler endpoints on each chain. Pimlico, Alchemy, and Biconomy ship the broadest chain coverage; Coinbase is concentrated on Base; Stackup is broad but some chains run smaller mempools. Pick a bundler stack whose footprint matches the chains your product targets.
​

Second, paymaster + bundler latency. Sponsored UX requires both the paymaster and the bundler to validate quickly. If the paymaster signs eligibility tokens via a slow backend, the bundler timeout can drop UserOps before they make it into a bundle. Production stacks measure end-to-end latency from "user signs" to "tx mined" and tune the paymaster backend accordingly. Most major paymaster services hit p95 latencies under 1 second.
​

For an Eco Routes integration that combines smart-wallet UX with cross-chain stablecoin orchestration, the bundler layer is the part that matters least to product teams day-to-day — pick a reliable operator (Pimlico is the most common choice for stablecoin teams), configure a fallback, and focus engineering effort on the paymaster strategy and the cross-chain routing layer. The integration shape is in Account Abstraction for Stablecoin Apps, and the broader smart-wallet SDK breakdown is in Best Smart Wallet SDKs for Developers.
​

Because UserOperations have different validation logic than regular Ethereum transactions, including arbitrary contract code that runs during validation. A regular Ethereum node does not know how to validate a UserOp, and the public mempool's transaction format does not accommodate the additional fields (paymasterAndData, separate validation/call gas, etc.). The alt-mempool is the design choice that lets bundlers handle this complexity off-chain.
​

Yes. Pimlico's Alto, Stackup's bundler, and Voltaire are all open-source and production-ready. Operating one means running an Ethereum node (or RPC connection), maintaining the bundler service, and monitoring uptime. Most consumer apps use a hosted bundler instead because the operational lift is substantial.
​

UserOperations in private bundler mempools have less MEV exposure than transactions in the public mempool — fewer searchers see them. Public alt-mempools have more MEV exposure but are still less prone to front-running than the public Ethereum mempool, partly because UserOp execution depends on the bundler's specific submission. Some bundlers explicitly partition flow into private order channels to reduce MEV impact.
​

The EntryPoint still charges the user (or paymaster) for the validation step plus the gas-up-to-revert during execution. The user sees a failed transaction; the bundler is still paid for inclusion. Wallet clients usually surface the revert reason so users understand what happened.
​

On L2s, typically 2-4 seconds (one to two blocks). On Ethereum mainnet, typically 12-24 seconds. Latency is dominated by block time rather than bundler processing — most bundlers can validate and bundle within 100-500ms of receipt.
​

The regulatory question is open and jurisdiction-specific. Most operators position themselves as transaction-relay infrastructure, similar to RPC providers, rather than financial-service providers. Different jurisdictions are taking different approaches, and several major operators have engaged regulators proactively.
​