Bundler Endpoints

Candide's Bundler endpoint includes methods for ERC-4337. Learn more about the various ERC-4337 Methods.

Supported Networks

Public endpoints below are accessible with rate limiting, while production-grade endpoints are available through our dashboard.

tip

If you require a specific network not listed below, send us a note and we will let you know if we can support it.

Mainnet

Network	Chain ID
Arbitrum One	42161
Base	8453
BnB Smart Chain	56
Celo	42220
Ethereum	1
Gnosis	100
Optimism	10
Polygon PoS	137

Testnet

Network	Chain ID
Arbitrum Sepolia	421614
Avalanche Fuji Testnet	43113
Base Sepolia	84532
Optimism Sepolia	11155420
Polygon Amoy	80002
Sepolia	11155111
Celo Alfajores	44787
BnB Smart Chain Tesnet	97

Unifed Mempool

ERC-4337 aims to bring Account Abstraction to Ethereum while maintaining strong decentralization and censorship-resistance, aligning closely with the block production security of the underlying chain. Launching a truly public and decentralized mempool for ERC-4337 is a complex process, and development will progress with “training wheels” — a controlled setup that allows for system updates and bug fixes in a safer environment. While necessary in the early stages, these training wheels will be gradually removed, enabling Bundlers to fully adopt the decentralized principles of the base layer.

To guide this evolution, the ERC-4337 Team introduced a framework, inspired by Vitalik’s proposed milestones for Rollups and L2Beat Stages Framework, which categorizes Bundler Mempool development into distinct stages. Each stage defines specific conditions and requirements for advancing, building toward a fully open and decentralized mempool. As the framework progresses, it enhances user benefits at every stage, such as censorship resistance, decentralization, and permissionless.

Stage 0 — Independent Operation

At Stage 0, bundlers operate individually, receiving and submitting UserOperations directly to the network without a shared mempool.

• User Advantage: Minimal setup allows bundlers to begin integrating quickly.
• Mechanism: Each bundler creates bundles independently, reducing initial complexity.
• Trade-off: No shared mempool means no cross-communication between bundlers, not censorship proof, and not decentrlizated.

Protection: Some protection against front-running can be achieved using Flashbot Protect on Ethereum Mainnet.

The Bundler is compliant with the ERC-4337 Standard

To confirm that a Bundler is following ERC-4337, it should demonstrate consistent adherence to the guidelines set out in the standard. This includes handling User Operations as specified and ensuring accurate validation processes. Compliance can be verified through audits, source code transparency, and through the Compatibility Test Suite published on erc4337.io/bundlers that validate the Bundler’s correct behavior within an Account Abstraction framework.

The Bundler software source code is available

A Bundler software processing User Operations should be available, contributing significantly to transparency and trust. This allows anyone to review, audit, and run the software, enabling users and external observers to independently validate that the Bundler is following the Account Abstraction Standard.

Stage 1 — Permissioned Mempool

Stage 1 introduces a shared, permissioned mempool where only whitelisted bundlers can participate.

• User Advantage: Greater transaction inclusion, visibility, and consistency across bundlers.
• Mechanism: A whitelist allows select bundlers to validate and submit transactions in the mempool, providing faster transaction handling.
• Validation: All bundlers follow standardized validation rules for gas fees and transaction requirements, ensuring alignment across the network.

Reliability: A system like Fastlane on Polygon is able to ensure prioritized visibility for UserOperations and reduces front-running risks. This stage tests robustness through Fuzz Testing simulation, ensuring bundlers can handle invalid transactions without spreading spam.

A Bundler must apply a consistent set of validation rules for transaction gas requirements and UserOperation formats.

A core requirement in this stage is the uniform validation of transaction gas values, including preVerificationGas, by participating bundlers. Each transaction must meet predefined gas requirements, so every bundler’s understanding of a “valid transaction” remains aligned. Any UserOperation that doesn’t meet these requirements is disregarded, preventing discrepancies across bundlers.

Network	Chain ID	RPC
Arbitrum One	42161	https://arbitrum.test.bundler.candide.dev
Ethereum	1	https://ethereum.test.bundler.candide.dev
Optimism	10	https://optimism.test.bundler.candide.dev

Stage 2 — Controlled Decentralization

In Stage 2, the mempool is semi-permissioned, but validation processes begin to open up with fewer restrictions.

• User Advantage: Increased security through active validation and accountability.
• Mechanism: Whitelisted bundlers validate and flag potential spam transactions but do not disconnect for minor discrepancies.
• New: A “mempool explorer” tool is introduced for transparency, allowing users to monitor mempool activity and bundler performance.

Robustness: This stage tests robustness, with tools like antithesis. This is used by Ethereum clients, and bundlers will benefit. This end criterion is met when no false-positive warnings are generated.

The Bundler must be resilient to invalid User Operations under p2p stress testing

Using fuzz testing, each Bundler should be able to consistently reject invalid User Operations without propagating them across the network. This ensures that each Bundler accurately filters out potentially harmful or spam transactions under high-volume conditions.

The Bundler accurately identify and flag spammers without generating false positives

The Bundler should undergo tests for robustness, using tools like antithesis, to confirm it can correctly mark genuine spammers without mistakenly labeling valid transactions or honest Bundlers as spammers. This end criterion is met when no false-positive warnings are generated.

Stage 3 — Full Decentralization

Stage 3 enables a fully permissionless mempool, where any bundler can participate.

• User Advantage: Complete decentralization and enhanced censorship resistance.
• Mechanism: All bundlers must meet full validation criteria, and non-compliant participants are marked as “spammers” and disconnected.
• Monitoring: Continuous monitoring helps detect and resolve any rule misalignments to prevent splits in the mempool.

There is a strict validation process that enforces consistency across Bundlers

Full validation rules must be applied between all Bundlers. Any Bundler that fails to comply with the rules should be flagged as a "spammer" and disconnected from the network. Continuous monitoring is necessary to ensure that there are no discrepancies or splits caused by differences in rule interpretation or implementation.

Any Bundler can enter the mempool without permission

The mempool should be open to all Bundlers, allowing anyone to participate without restrictions. This ensures a truly permissionless environment where any Bundler can submit User Operations to the public mempool.