---
title: "How to fix precheck failed errors"
description: "How to resolve precheck failed error"
---

# How to fix precheck failed errors

The following `precheck failed` errors are typically related to gas and/or fees.

Our [Bundler](/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 on chain and;
1. Protect the bundler from potential attacks in order to support scalability

There are many different checks bundlers run before accepting a UO.

For all possible precheck violations see [here](https://github.com/alchemyplatform/rundler/blob/21018301fe54d6e5328849b7e3649b55e67b26d5/crates/types/src/pool/error.rs#L103).

Below are common pre-check errors including gas and fees being too low or too high.

## Gas or fee estimates too low

Here are a few example error messages:

- `maxPriorityFeePerGas is X but must be at least XXXX`
- `callGasLimit is X but must be at least XXXX`
- `preVerificationGas is X but must be at least XXX`
- `maxFeePerGas is X but must be at least XXX`

### Explanation

Our bundler currently rejects upon sending userOps if they are underpriced compared to the network rate to ensure inclusion in a block. 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.

### Solution 1: using API

- Use our gas estimations
  - see [`eth\_estimateUserOperationGas`](https://www.alchemy.com/docs/wallets/api-reference/bundler-api/bundler-api-endpoints/eth-estimate-user-operation-gas)
  - see [`alchemy\_requestGasAndPaymasterAndData`](https://www.alchemy.com/docs/wallets/api-reference/gas-manager-admin-api/gas-abstraction-api-endpoints/alchemy-request-gas-and-paymaster-and-data)

- Reduce the time between estimation and sending
  - Any small delay can cause estimates to be out of date as they may fluctuate quickly

- Implement retries
  - If your UO gets rejected, re-estimate gas and resend the User Operation

- Add a multiplier on top of fee estimates to account for fluctuation
  - Read the parameters section of [`alchemy\_requestGasAndPaymasterAndData`](https://www.alchemy.com/docs/wallets/api-reference/gas-manager-admin-api/gas-abstraction-api-endpoints/alchemy-request-gas-and-paymaster-and-data)
  - Read more about [user operation overrides](https://www.alchemy.com/blog/user-operation-overrides)

### Solution 2: using the SDK

- If you are using Alchemy's infra for AA:
 - recommended — use an Alchemy client via any of the `createAlchemyClient` \(e.g. `createLightAccountAlchemyClient`\)
  - alternative — if for some reason you must use `createSmartAccountClient`, import the `alchemyFeeEstimator` middleware from `aa-alchemy` or `account-kit/infra` \(depending on which version of the SDK you're on\), and override the `feeEstimator` field in your client constructor

- Implement retries
  - Re-estimate, sign and send the user operation with updated gas and fee fields

- Add a multiplier
  - On top of fee estimates to account for fluctuation using [UserOperationOverrides](https://www.alchemy.com/docs/wallets/resources/types#useroperationoverrides)
  - Read more about [user operation overrides](https://www.alchemy.com/blog/user-operation-overrides)

## Gas limit too high

Here are a few example error messages:

- `verificationGasLimit is X but must be at most XXX`
- `total gas limit is X but must be at most XXX`

### Explanation

Gas limits are based on the max block size and max transaction size per chain. We make sure a single op is not larger than the max bundle gas and also that the combination of user operations being bundled are not larger. Total gas limit is checked against the aggregate between `preVerificationGas`, `verificationGasLimit`, and `callGasLimit`.

### Solution

To reduce the gas needed, try reducing the size of your call data and/or sending your call data in multiple `UserOperation`s rather than one.