# Bundler FAQs

> Frequently asked questions about the Bundler

> For the complete documentation index, see [llms.txt](/docs/llms.txt).

## userOperation

### How can I track the status of a userOp?

To understand the status of a userOp you can use the `eth_getUserOperationByHash` method as follows: loop over `eth_getUserOperationByHash` for as long as you are willing to wait for the userOp to land. If it still returns `null` after the timeout, there are two possibilities:

1. **The userOp is still pending**: This is the most common scenario and typically means *the fees are too low*. In this case, you should drop and replace the userOp with higher fees.
2. **The userOp has been dropped**: The most common (but rare) reason is that they paymaster signature has expired. However, this should rarely happen if you set a reasonable sponsorship expiry time, unless there is a significant delay in sending the userOp after the paymaster signs it.

### How do I get my userOp unstuck from the mempool?

For EIP-1559 fee markets, the base fee is fixed per block. To prioritize the inclusion of your userOp and get it unstuck from the mempool, you need to increase the `maxPriorityFeePerGas`. This can be achieved by dropping and replacing the userOp with a new one that has a higher `maxPriorityFeePerGas`.

### Can accepted userOps be dropped?

This is a possible but rare scenario and can occur due to several reasons:

* The userOp is replaced by another userOp from the same sender with the same nonce.
* The signature of the Gas Manager has expired, rendering the userOp ineligible for sponsorship.
* The validation function of the userOp fails when it is being bundled into a transaction for onchain submission.
* The mempool runs out of memory, causing the bundler to drop userOps with the lowest fees.

### Get bundle hash before mining

The transaction hash is not included in the response of `eth_sendUserOperation` for the following reasons:

* The hash of the bundle transaction that a userOp is included in can change before that userOp is mined. This can happen for multiple reasons, such as the pending bundle transaction being dropped and replaced by the bundler if it’s underpriced, or the bundle transaction being frontrun by another bundle that includes the userOp.
* Adding the transaction hash to the response of `eth_sendUserOperation` is incompatible with the future P2P mempool, since any bundler can bundle the userOp and land it onchain.

## Common Errors

### What are `precheck failed` errors and how do I handle them?

`precheck failed` errors are typically related to gas and/or fees. The bundler follows the standard [ERC-4337 implementation](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4337.md#client-behavior-upon-receiving-a-useroperation) for gas and fee checks to 1) ensure your userOp lands onchain and to 2) protect the bundler from potential attacks to support scalability.

These errors are often related to market movement between the time gas and fees are estimated and the time when userOps are submitted to the bundler. This issue is especially prevalent on testnets. The bundler rejects userOps upon sending if they are underpriced compared to the network rate, to ensure inclusion in a block.

To handle these errors, you should:

* add buffers on top of the gas estimates to account for market fluctuations
* implement retry mechanisms.

### Resolve `Replacement Underpriced` errors

You might get a `"Replacement Underpriced Error"` when using `eth_sendUserOperation`. This error occurs when a user already has an existing userOp in the mempool. userOps can become "stuck" in the mempool if their gas fee limits are too low to be included in a bundle.

To resolve this, you need to increase both `maxFeePerGas` and `maxPriorityFeePerGas` by at least 10%.

To do so, follow the next steps:

1. **Re-estimate gas fees**: This can be done in various ways which are mentioned below:

   1. Use [`eth_maxPriorityFeePerGas`](/docs/chains/ethereum/ethereum-api-endpoints/eth-max-priority-fee-per-gas) to obtain `maxPriorityFeePerGas`. This method is also available on web3 libraries like `ethers.js` and can be accessed through the provider as `provider.getFeeData()`.

2. **Choose the suitable increase values**: Once you have the re-estimated gas fees, choose the maximum of a 10% increase or the re-estimated values. This ensures that your new gas fee is competitively priced to be included in a block.

3. **Account for Rundler's service tip**: Rundler requires a small tip for its services via `maxPriorityFeePerGas`. Detailed information about this can be found [below](/docs/reference/bundler-faqs#fees).

After calculating the new values, send your `userOp` again with the updated fees and it should go through successfully.

### Debug `-32521: Execution reverted` errors

These occur when the `userOp` reverts during execution. These errors typically contain `revertData`, which are optional bytes with additional information about the revert.

What revertData contains:

1. **First 4 bytes**: the error selector (e.g., 0x08c379a0 = Error(string)). This is the Keccak-256 hash of the error signature.
2. **Remaining bytes**: ABI-encoded arguments for that error (if any).

To debug these errors, you should:

* Isolate the first 4 bytes of `revertData`.
* Paste into a signatures DB (e.g. [4byte.sourcify.dev](https://4byte.sourcify.dev)).
  * If it matches a known error, you’ll see the standard signature.
  * If not, it's a **custom error** - check the contract's ABI or source for error declarations.
* Decode any arguments (using a tool like [calldata.swiss-knife.xyz](https://calldata.swiss-knife.xyz/decoder) or your ABI).
* Map the error back to the contract source code to understand under what conditions it reverts.

## Parallel nonces

### What is the maximum number of supported parallel nonces?

The bundler supports up to 4 parallel nonces (default value from ERC-7562) for unstaked senders and unlimited parallel nonces for staked senders. See [below](/docs/reference/bundler-faqs#minimum-entrypoint-stake-amount) for stake requirements.

Unstaked accounts that attempt to exceed this limit will receive the error `Max operations (4) reached for account`. Staking the account removes the restriction. Accounts can be staked by calling `addStake(uint32 unstakeDelaySec)` on the EntryPoint contract, and later `unlockStake()` followed by `withdrawStake(address payable)` to recover the stake.

Staked senders are subject to ERC-7562 reputation rules. If a sender submits a large number of userOps and subsequently invalidates them all, they may be throttled or banned.

### Can I include multiple parallel nonces in a single bundle?

To include multiple parallel nonces in the same bundle, the account must stake the [minimum stake amount](/docs/reference/bundler-faqs#minimum-entrypoint-stake-amount) with the EntryPoint.

## Signatures

### What is a dummy signature?

The APIs are compatible with any type of smart account. This means regardless of the smart account you're using, the endpoints work with it. However, different smart accounts have unique ways of signing transactions, known as signature patterns. A dummy signature is a template or example signature that aligns with the signature pattern of your specific account type.

For certain API endpoints (ex: [eth\_estimateUserOperationGas](/docs/wallets/api-reference/bundler-api/bundler-api-endpoints/eth-estimate-user-operation-gas)), particularly those involved in gas estimation, a dummy signature is required in the request. This is because these endpoints need to simulate or estimate the transaction without actually executing it, and the dummy signature helps in this process.

## Fees

### What are the bundler fees?

Rundler requires fees when using [`eth_sendUserOperation`](/docs/wallets/api-reference/bundler-api/bundler-api-endpoints/eth-send-user-operation), and these fees differ based on the mainnet or testnet in use. Rundler's requirements for priority fees are expressed via the [`rundler_maxPriorityFeePerGas`](/docs/wallets/api-reference/bundler-api/bundler-api-endpoints/rundler-max-priority-fee-per-gas) endpoint.

Each Bundler API endpoint has an [associated compute unit cost](/docs/reference/compute-unit-costs#gas-manager--bundler-apis).

The following table provides a detailed breakdown of the fee logic and recommendations for each network type:

| Network Type | Network Name          | Extra Fee Requirement                                                  |
| ------------ | --------------------- | ---------------------------------------------------------------------- |
| Mainnet      | All except Arb chains | Priority fee buffer: 25% Base fee buffer: 27% minimum, 50% recommended |
| Mainnet      | Arbitrum Nitro chains | Priority fee buffer: None Base fee buffer: 27%, 50% recommended        |
| Testnet      | All testnets          | Priority fee buffer: None Base fee buffer: 27%, 50% recommended        |

Recommended Actions for Calculating `maxFeePerGas`:

1. **Fetch Current Base Fee**: Use the method [`eth_getBlockByNumber`](/docs/reference/eth-getblockbynumber) with the `'latest'` parameter to get the current `baseFeePerGas`.

2. **Apply Buffer on Base Fee**: To account for potential fee changes, apply a buffer on the current base fee based on the requirements and recommendations in the table shown above. (27% is the minimum for bundler acceptance, but at least 50% is recommended)

3. **Fetch Current Priority Fee with Rundler**: Use the [`rundler_maxPriorityFeePerGas`](/docs/wallets/api-reference/bundler-api/bundler-api-endpoints/rundler-max-priority-fee-per-gas) method to query the current priority fee for the network.

4. **Apply Buffer on Priority Fee**: Once you have the current priority fee using `rundler_maxPriorityFeePerGas`, increase it according to the fee requirement table shown above for any unexpected changes (No buffer for Arbitrum Mainnet and 25% buffer for all other mainnets).

5. **Determine `maxFeePerGas`**: Add the buffered values from steps 2 and 4 together to obtain the `maxFeePerGas` for your user operation.

<Warning>
  The bundler requires the simulated gas limit efficiency of both a UO's pre-operation gas and call gas to be greater than or equal to 15%. (Note: the 15% efficiency value is subject to change and docs will be updated if it does.)

  **Gas limit efficiency** = gas used / gas limit

  **Pre-operation gas** = `preVerificationGas` + `verificationGasLimit` + `paymasterVerificationGasLimit`

  **Note**: for EP v0.6 `paymasterVerificationGasLimit` == `verificationGasLimit`

  This check is intended to prevent user operations from taking up gas limit space in a bundle, but then not using the gas onchain. This could prevent other UOs from being bundled that otherwise could have. Use the results from the `eth_estimateUserOperationGas` endpoint, with slight buffers if desired while keeping above 15% efficiency.
</Warning>

<Info>
  Use the [Wallet APIs
  SDK](https://www.alchemy.com/docs/wallets) to minimize the complexities of
  estimating userOp gas fees.
</Info>

### How fee values are determined

* [alchemy\_requestGasAndPaymasterAndData](/docs/wallets/api-reference/gas-manager-admin-api/gas-abstraction-api-endpoints/alchemy-request-gas-and-paymaster-and-data) is an opinionated endpoint that tries to set fee values that give your userOps a high chance of landing onchain. The estimates may be slightly high, but this is intentional to land your UOs faster.

* Try different fee percentages and determine what works best for you as a balance between cost and chance/time to mine.

* For [alchemy\_requestGasAndPaymasterAndData](/docs/wallets/api-reference/gas-manager-admin-api/gas-abstraction-api-endpoints/alchemy-request-gas-and-paymaster-and-data), the ability to override fee estimates is available with the `feeOverride` parameters.

  * The defaults increase baseFee by 50% and priorityFee by 5%.
  * **Note**: The feeOverride parameters don't include preVerificationGas (PVG). The method always increases the estimated PVG by 5% to give the UO a better chance to mine if the L1 /L2 fee ratio changes. To modify this value, use [alchemy\_requestPaymasterAndData](/docs/wallets/api-reference/gas-manager-admin-api/gas-abstraction-api-endpoints/alchemy-request-paymaster-and-data) instead.

## EntryPoint

### Which EntryPoint versions are supported?

Versions v0.6, v0.7, and v0.8 of ERC-4337 are currently supported.

### Which EntryPoint version should I use?

The latest version of ERC-4337 is v0.8, which builds on v0.7 with additional improvements including native support for [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) account delegation and further gas optimizations.

The appropriate version to use is determined by the smart account for which you are trying to send a userOp. Typically, a smart account is written to be compatible with a specific EntryPoint version. To determine which version is compatible, look at the smart account’s source code and check the first parameter of the `validateUserOp` function. If it has type `UserOperation`, the account uses v0.6. If the parameter type is `PackedUserOperation`, the account uses v0.7 or v0.8.

For more information about the differences between the versions, refer to the specifications for [ERC-4337 v0.6.0](https://github.com/eth-infinitism/account-abstraction/blob/v0.6.0/eip/EIPS/eip-4337.md), [ERC-4337 v0.7.0](https://github.com/eth-infinitism/account-abstraction/blob/v0.7.0/erc/ERCS/erc-4337.md), and [ERC-4337 v0.8.0](https://eips.ethereum.org/EIPS/eip-4337), particularly the description of the user operation fields.

### EntryPoint contract addresses (v0.6, v0.7, v0.8)

The EntryPoint contracts for v0.6, v0.7, and v0.8 are deployed at the following addresses across all chains supported by Alchemy:

EntryPoint v0.8: `0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108`\
EntryPoint v0.7: `0x0000000071727De22E5E9d8BAf0edAc6f37da032`\
EntryPoint v0.6: `0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789`

### When will EntryPoint v0.6 be deprecated?

There is not currently a date set to deprecate support for EntryPoint v0.6 but deprecation is planned sometime in 2026. Ensure that you have migrated to EntryPoint v0.7 or v0.8 by that time. If you have any questions or need assistance with the migration process, file a ticket via the [Discord server](https://discord.com/channels/735965332958871634/1115787488838033538).

## Entity Staking Requirements

### Minimum EntryPoint stake amount

Mainnets:

| Chain Name          | Min Stake (Native Token) |
| ------------------- | ------------------------ |
| Ethereum Mainnet    | 0.1 ETH                  |
| BNB Mainnet         | 0.1 BNB                  |
| Polygon Mainnet     | 100 MATIC                |
| Arbitrum One        | 0.1 ETH                  |
| Optimism Mainnet    | 0.1 ETH                  |
| Zora Mainnet        | 0.1 ETH                  |
| Frax Mainnet        | 0.1 ETH                  |
| Base Mainnet        | 0.1 ETH                  |
| Polynomial Mainnet  | 0.1 ETH                  |
| World Chain Mainnet | 0.1 ETH                  |
| Shape Mainnet       | 0.1 ETH                  |
| Berachain Mainnet   | 0.1 BERA                 |
| Anime Mainnet       | 0.1 ETH                  |
| Race Mainnet        | 0.1 ETH                  |
| Unichain Mainnet    | 0.1 ETH                  |
| Soneium Mainnet     | 0.1 ETH                  |
| Ink Mainnet         | 0.1 ETH                  |
| Story Mainnet       | 0.1 ETH                  |
| Celo Mainnet        | 0.1 CELO                 |
| OpBNB Mainnet       | 0.4 BNB                  |

Testnets:

| Chain Name          | Min Stake (Native Token) |
| ------------------- | ------------------------ |
| Ethereum Sepolia    | 0.1 ETH                  |
| BNB Testnet         | 0.1 BNB                  |
| Polygon Amoy        | 10 MATIC                 |
| Arbitrum Sepolia    | 0.1 ETH                  |
| Optimism Sepolia    | 0.1 ETH                  |
| Zora Sepolia        | 0.1 ETH                  |
| Alchemy Sepolia     | 0.1 ETH                  |
| Base Sepolia        | 0.1 ETH                  |
| Polynomial Sepolia  | 0.1 ETH                  |
| World Chain Sepolia | 0.1 ETH                  |
| Shape Sepolia       | 0.1 ETH                  |
| Anime Sepolia       | 0.1 ETH                  |
| Race Sepolia        | 0.1 ETH                  |
| Unichain Sepolia    | 0.1 ETH                  |
| Soneium Minato      | 0.1 ETH                  |
| Ink Sepolia         | 0.1 ETH                  |
| Monad Testnet       | 0.1 ETH                  |
| Openloot Sepolia    | 0.1 ETH                  |
| Wylerchain Sepolia  | 0.1 ETH                  |
| Gensyn Testnet      | 0.1 ETH                  |
| Rise Testnet        | 0.1 ETH                  |
| Story Aeneid        | 0.1 ETH                  |
| Converge Testnet    | 0.1 ETH                  |
| Celo Alfajores      | 0.1 CELO                 |
| Tea Sepolia         | 0.1 ETH                  |
| Educhain Testnet    | 0.1 ETH                  |
| OpBNB Testnet       | 0.4 BNB                  |

Paymasters and factories must have at least the above stake or their userOps will be rejected. Accounts only need to stake if they wish to exceed 4 parallel nonces in the Bundler's mempool; otherwise, userOps beyond this limit will be rejected. The same stake amounts apply to accounts.

### What is the minimum delay value?

The minimum unstake delay required by Rundler is 1 Day. Paymasters and factories must configure at least this delay or their userOps will be rejected. Staked accounts are subject to the same delay requirement.