What is a Bundler?
A bundler is a network participant in the ERC-4337 Account Abstraction stack that gathers users’ UserOperations (intents), validates them off-chain, and packages many of them into a single on-chain transaction. The bundler submits that one transaction to the EntryPoint contract, which then executes each UserOperation in turn. By aggregating many users’ actions into a single transaction, bundlers give smart-account users the convenience of intents while keeping gas costs efficient.
The bundler is the “relayer” of the account-abstraction world. Without it, every UserOperation would need its own transaction, defeating the purpose. With it, a user just signs an intent and some bundler somewhere takes care of getting it on-chain — analogous to how a block builder assembles transactions, but operating on the ERC-4337 alt mempool.
How a Bundler Works / Technical Details
The Bundling Pipeline
- Listen to the alt mempool. Bundlers monitor the ERC-4337 UserOperation mempool (separate from the regular transaction mempool) for incoming UserOps.
- Validate off-chain. For each UserOp, the bundler runs the account’s validation logic off-chain (via a simulation) to confirm the signature is valid, the account has funds or a paymaster, and the operation will succeed.
- Assemble a bundle. The bundler groups many validated UserOps into a single transaction targeting the EntryPoint contract.
- Submit on-chain. The bundler sends the bundle as a real Ethereum transaction, paying the gas up front.
- Execution and reimbursement. The EntryPoint executes each UserOp, collects gas (from the account or its paymaster), and reimburses the bundler. The bundler also earns any priority fee or MEV from the bundle.
The Validation/Execution Separation Rule
This is the trickiest and most important rule a bundler must follow. To safely include a UserOp, the bundler must confirm that simulating validation won’t depend on state that changes between simulation and execution. If account validation reads mutable state (e.g., the balance of some other contract), the bundle could become invalid mid-block and the entire bundle reverts — costing the bundler gas with no reimbursement.
ERC-4337 enforces this with banned opcodes/storage access rules during validation: a UserOp’s validation function may only touch the account’s own storage (and limited global state). Bundlers reject UserOps that violate this, because they cannot safely bundle them.
Reputation and Anti-Dos
Because bundlers pay gas up front and only get reimbursed if the bundle succeeds, they are vulnerable to denial-of-service: a malicious actor could flood the mempool with UserOps that simulate fine but then revert. To defend, the ERC-4337 ecosystem uses a reputation system for UserOp origins — bundlers throttle entities that repeatedly send failing ops.
Bundler Economics
Bundlers compete on:
- Inclusion speed and reliability
- Fee taken from each UserOp’s gas
- MEV captured by smart ordering within and across bundles
This mirrors the searcher/builder dynamic in MEV: bundlers can reorder UserOps or front/back-run them, which is why some wallets route UserOps through private, trusted bundlers or shared-bundle networks to protect users.
Notable Examples and Patterns
Bundler-as-a-Service Providers
Running a robust bundler (with simulation, reputation, and mempool management) is non-trivial, so most dApps use dedicated providers:
- Pimlico, Alchemy, Biconomy, Stackup, ZeroDev — popular bundler/RPC services that handle the alt mempool and submission
- These expose simple RPC endpoints (
eth_sendUserOperation) so wallets can submit intents without running bundler infrastructure
Bundlers and Paymasters Together
The most common modern flow combines a bundler (for submission) with a paymaster (for gas sponsorship): the user signs an intent with no ETH, the paymaster promises to cover gas, and the bundler assembles and submits the bundle. This is what powers gasless onboarding at scale.
Centralization and Censorship Concerns
Because running a high-quality bundler is hard, a handful of providers handle most traffic, raising questions about censorship (a dominant bundler could refuse to relay certain UserOps). The mitigations are the same as for any relayer: competition, open-source reference implementations (like aa-bundler from ERC-4337’s team), and user choice of bundler endpoint.
How to Use and Understand Bundlers
For Users
- You usually don’t choose a bundler directly — your wallet picks one. But if a transaction is slow or fails, switching wallet or RPC can route through a different bundler.
- Bundlers can see and order your UserOps. Use wallets that submit through trusted or private bundlers for MEV-sensitive operations, the same way you’d use private order flow for regular transactions.
For Developers
- Don’t build a bundler from scratch unless you have a strong reason — use a mature provider or the reference implementation.
- Respect validation rules. Write account validation logic that only touches allowed storage, or bundlers will reject your UserOps.
- Handle paymaster coordination if you sponsor gas, since the bundler, paymaster, and account must all agree on the bundle.
- Test revert paths. A UserOp that reverts at execution still costs the bundler gas; design so that validation accurately predicts execution success.
Frequently Asked Questions
Q: Is a bundler the same as a validator or miner? A: No. A bundler is a relayer specific to the ERC-4337 layer — it assembles UserOps and submits one transaction. Validators/miners produce the actual blocks; the bundler’s bundle is just one transaction inside a block.
Q: Who pays the bundler? A: The EntryPoint reimburses the bundler for gas using funds from the user’s account or its paymaster, plus any priority fee. The bundler pays gas up front and is repaid if the bundle succeeds.
Q: Can a bundler steal my funds? A: No. A bundler only relays already-signed UserOperations to the EntryPoint; it cannot alter them or move funds the user didn’t authorize. Its power is limited to ordering, inclusion, and (potentially) MEV extraction — not theft.