A bundler is an offchain actor that picks UserOperations out of an alternative mempool, simulates each one against the rules in ERC-4337 and ERC-7562, packs the valid ones into a single Ethereum transaction, and submits that transaction to the canonical EntryPoint contract. Bundlers are the engine that turns account abstraction from a specification into something users can actually click. Without them, a smart account holder's UserOperation is just a signed JSON blob sitting in a relayer's pending queue.
​

This article walks through how bundlers work in 2026: the alt-mempool that feeds them, the validation rules they must follow, the reputation system that polices spam, the banned opcodes that protect simulation, and the production bundlers shipping today (Pimlico, Alchemy Rundler, Stackup, Biconomy, Candide, Etherspot Skandha). It closes with pricing models and the self-hosting versus SaaS decision for teams building on ERC-4337.
​

ERC-4337, finalized in March 2023, introduced account abstraction without changing Ethereum's consensus layer. The spec lives at eips.ethereum.org/EIPS/eip-4337. Instead of teaching the protocol about smart accounts, the spec defines a parallel transaction format called UserOperation and a singleton contract called EntryPoint (deployed at 0x0000000071727De22E5E9d8BAf0edAc6f37da032 on most major chains in the v0.7 release).
​

A bundler is the offchain piece that connects UserOperations to EntryPoint. The job has four parts:

The bundler is paid in gas. EntryPoint refunds the bundler from each UserOperation's prefunded gas (or from the paymaster sponsoring it), plus the priority fee the sender attached. A bundler that includes a bad UserOperation that reverts during validation eats the gas itself, which is why simulation rules are strict.
​

Walking the path of a single UserOperation from sender to inclusion shows why bundlers exist as their own role.
​

A user signs a UserOperation in their smart account UI. The UserOperation includes the sender address, nonce, calldata, gas limits, signature, and optional paymaster data. The wallet posts it to a bundler RPC endpoint using eth_sendUserOperation. That bundler now owns the UserOperation.
​

The bundler runs the validation phase. It calls simulateValidation on EntryPoint, which executes the account's validateUserOp function plus the paymaster's validatePaymasterUserOp if a paymaster is attached. During this simulation the bundler enforces the ERC-7562 opcode restrictions and storage access rules. If validation passes and the UserOperation pays at least the bundler's minimum priority fee, it goes into the local mempool.
​

The bundler also gossips the UserOperation to peers on the alt-mempool P2P network defined in the ERC-4337 reference spec. This is structurally similar to Ethereum's devp2p mempool but runs as a separate libp2p topic so UserOperations do not pollute the canonical mempool. The reference implementation lives in the eth-infinitism bundler at github.com/eth-infinitism/bundler.
​

When the bundler is ready to build a block (typically every 1 to 12 seconds depending on chain), it selects a profitable set of UserOperations, re-simulates the entire bundle to confirm none have become invalid (a sender's nonce moved, a paymaster's deposit drained), and calls handleOps(userOps[], beneficiary) on EntryPoint. The transaction is signed by the bundler's EOA and broadcast to the regular mempool. Once mined, EntryPoint loops through each UserOperation, calls the sender account's execution, and refunds the bundler.
​

ERC-4337 deliberately keeps UserOperations out of Ethereum's public mempool. Two reasons drive this.
​

First, UserOperations are not transactions. Ethereum nodes built around devp2p expect signed transactions with a sender EOA, gas price, and standard fields. A UserOperation has none of those at the protocol level. Trying to gossip them over devp2p would mean modifying every node.
​

Second, validation logic for UserOperations is contract-defined, not protocol-defined. A smart account can have any signature scheme: ECDSA, secp256r1 passkeys, multisig, social recovery. Validating a UserOperation requires running EVM code, not just checking a signature. Public mempool nodes cannot afford to run arbitrary contract code on every pending message, but bundlers can because they are specialized and reputation-bound.
​

The result is a parallel system: wallets send to bundler RPCs, bundlers gossip to other bundlers over a P2P alt-mempool topic, and the canonical mempool only ever sees the final handleOps transaction. The P2P spec is documented in the ERC-4337 reference repo under eth-infinitism/bundler-spec.
​

The hardest part of running a bundler is making sure a UserOperation that passes validation in simulation will still pass validation when included onchain. If a UserOperation reverts during the real handleOps call, the bundler pays the gas with no refund. ERC-7562, the validation rules spec, exists to prevent this.
​

ERC-7562 restricts what a UserOperation's validation phase can do. The rules fall into a few buckets:

Bundlers enforce these rules using a tracer. The eth-infinitism reference bundler uses a custom debug_traceCall tracer that records every opcode and storage access during simulation. Production bundlers like Pimlico's Alto and Alchemy's Rundler use their own tracer implementations tuned for the chains they support.
​

The alt-mempool is permissionless, which means anyone can send any UserOperation. Without a reputation layer, a single attacker could flood bundlers with UserOperations that pass simulation but waste gas at inclusion. ERC-4337 defines a reputation system for the three roles a UserOperation depends on: the account factory, the paymaster, and the aggregator.
​

Each bundler tracks opsSeen and opsIncluded per entity. The ratio defines reputation. An entity is "OK" if opsSeen / opsIncluded stays within a window (the default is 10x). An entity becomes "throttled" if it exceeds the window, meaning the bundler will only accept one UserOperation from it per block. An entity becomes "banned" if it badly exceeds the window, meaning all its UserOperations are rejected.
​

This means a paymaster that signs too many UserOperations that later fail (because the paymaster runs out of deposit, or the signature has gone stale) gets throttled by every bundler watching the alt-mempool. The same logic protects against malicious factories that deploy accounts which immediately self-destruct or revert. The reputation rules are documented in ERC-7562 alongside the opcode rules.
​

Six bundler implementations are in production use on mainnet and major L2s as of mid-2026. Each is open source.
​

Pimlico's bundler is written in TypeScript and is one of the most widely used in production. Pimlico operates a hosted bundler across more than 60 chains and publishes the source at github.com/pimlicolabs/alto. Alto supports ERC-4337 v0.6 and v0.7 plus the ERC-7702 hybrid flow for accounts that delegate from an EOA.
​

Rundler is Alchemy's Rust bundler, open sourced in 2023. The Rust implementation is built for throughput and is the engine behind Alchemy's hosted bundler endpoints. Source at github.com/alchemyplatform/rundler. Rundler is also the bundler shipped inside Coinbase Smart Wallet's infrastructure stack.
​

Stackup's bundler is written in Go and was one of the earliest production implementations. Source at github.com/stackup-wallet/stackup-bundler. Stackup runs hosted bundler endpoints and ships an SDK that wraps the JSON-RPC interface.
​

Biconomy's bundler powers its modular smart account stack and is integrated tightly with the Biconomy paymaster. Biconomy publishes hosted endpoints across most EVM L2s and uses its bundler as the execution backbone for its "supertransactions" routing product.
​

Voltaire is Candide's Python bundler. The implementation lives at github.com/candidelabs/voltaire and emphasizes EIP-7702 support and a clean abstraction over the validation tracer. Candide also runs a hosted bundler on Ethereum mainnet and several L2s.
​

Skandha is Etherspot's TypeScript bundler, published at github.com/etherspot/skandha. Skandha was one of the first bundlers to ship the P2P alt-mempool integration and is commonly used by teams that want to self-host on chains where the major SaaS bundlers do not have endpoints.
​

Hosted bundler providers charge in two main ways.
​

The first is a per-UserOperation fee. Pimlico, Alchemy, and Stackup all publish tiered plans where the user pays a fixed dollar amount per UserOperation processed, with volume discounts. Typical 2026 pricing on the major providers runs from free for the first few thousand UserOperations per month up to enterprise plans negotiated at six figures annually.
​

The second is a gas markup. The bundler builds the bundle and submits the onchain transaction, paying gas in ETH. The provider reimburses itself by charging the UserOperation sender slightly more than the actual gas cost, capturing the spread. Markup rates are typically a single-digit percentage on top of the priority fee the bundler sets.
​

Most hosted providers combine both: a per-call fee for the RPC endpoint plus a markup on the actual gas. Self-hosting eliminates the per-call fee but leaves the operator responsible for gas float, infrastructure, and chain coverage.
​

Teams shipping account abstraction in 2026 face a build-or-buy decision on the bundler layer.
​

SaaS bundlers (Pimlico, Alchemy, Biconomy, Stackup) give a team a JSON-RPC endpoint, multi-chain coverage out of the box, monitoring, SLAs, and the option to layer a hosted paymaster on top. The team pays per UserOperation or per gas unit but writes no infrastructure code. This is the common path for consumer wallets and apps where bundler throughput is not on the critical path.
​

Self-hosting (Alto, Rundler, Voltaire, Skandha all run on commodity hardware) gives a team full control. The operator runs the bundler binary, funds an EOA with enough ETH to submit bundles, configures the alt-mempool peers, and monitors inclusion. This makes sense when:

The eth-infinitism reference bundler is the canonical starting point for self-hosting because it is the implementation against which the spec is tested. Most production deployments fork or replace it once they hit performance limits.
​

Bundlers are the reason a stablecoin payment app can let a user pay with a passkey instead of a seed phrase, sponsor the user's gas in USDC instead of ETH, and batch a swap plus a transfer plus an approval into one signature. Every smart account interaction at scale ends in a bundler submitting handleOps to EntryPoint. Picking a bundler (or running one) is one of the load-bearing decisions in an account abstraction stack, alongside the paymaster and the account factory.
​

Eco's stablecoin orchestration layer treats the bundler as one component in a larger routing decision: which chain to settle on, which paymaster to charge, which bundler to relay through. For a deeper walk through the full stack, see the account abstraction stack guide, the paymaster explainer, and the 2026 ERC-4337 infrastructure comparison.
​