Skip to content
Alchemy Logo

EntryPoint v0.7 Revert Codes

Learn about the revert codes returned by the ERC-4337 EntryPoint v0.7

Bundler JSON-RPC error codes are often accompanied by an additional AAxx code provided by the EntryPoint.

  • AA1x error codes relate to creating an account
  • AA2x error codes relate to the sender or the user operation itself (nonce, signature, prefund, time validity, verification gas)
  • AA3x error codes relate to paymasters (deposit, expiration, verification)
  • AA9x error codes are general and not related to a certain theme (invalid addresses, failed sends, invalid aggregator, etc.)

The sender (smart account) has already been created. This error may occur if you attempt to create the same account multiple times using initCode.

Possible Solutions:

  1. Remove the initCode if you're re-submitting a UserOp for an existing account.
  2. Ensure the initCode is only used for initial account creation.

The initCode ran out of gas (OOG) or reverted during the account creation process. The smart account was not successfully deployed.

Possible Solutions:

  1. Ensure the account has sufficient native token to pay for deployment if you aren't using a paymaster.
  2. Verify the factory address (the first 20 bytes of the initCode) is correct.
  3. Increase the verificationGasLimit to ensure the initCode can execute fully.
  4. If the initCode reverted, investigate the cause (e.g., incorrect factory bytecode, logic errors).

The initCode returned a different address than the expected sender. The code that handles the creation must return the sender address as the newly deployed contract.

Possible Solutions:

  1. Check your factory or account creation logic to ensure it returns the correct address.
  2. Verify that the deployed account address matches the address specified in the UserOperation.

After executing initCode, the sender address must have code (the account contract must be deployed). If the sender remains a non-contract address (EOA-like), this error is raised.

Possible Solutions:

  1. Ensure that initCode actually deploys a contract at the sender address.
  2. Verify your factory contract logic to ensure a contract is always deployed.

The sender did not have enough deposit to cover the required prefund for the operation (if no paymaster is used).

Possible Solutions:

  1. Increase the deposit of the sender to cover the gas costs (via depositTo on the EntryPoint).
  2. Use a paymaster to cover the operation costs if funds are insufficient.

The operation is either expired or not yet valid based on its validUntil or validAfter time fields.

Possible Solutions:

  1. Check that the current block timestamp is within the valid time range for your UserOp.
  2. Ensure you haven’t missed the operation’s validity window and resubmit within its allowed timeframe.

The account’s validateUserOp call reverted. This could indicate a logical error within the account validation step.

Possible Solutions:

  1. Investigate the revert reason returned by the account contract using tools like Tenderly.
  2. Ensure the validateUserOp logic in the account contract is correct and doesn’t revert under normal conditions.

The validateUserOp call or signature verification failed. The signature provided did not pass validation.

Possible Solutions:

  1. Verify that you’re using the correct private key and signature scheme.
  2. Check that the aggregator (if used) is correct and that the signature is properly formatted.

The nonce provided by the sender in the UserOp is invalid, possibly out of sync with the EntryPoint’s stored nonce.

Possible Solutions:

  1. Fetch the current nonce from the EntryPoint before submitting the UserOp.
  2. Ensure the UserOp uses the correct nonce sequence.

The account or paymaster validation exceeded the specified verificationGasLimit.

Possible Solutions:

  1. Increase verificationGasLimit in the UserOp to cover the complexity of validateUserOp.
  2. Optimize the validation logic to consume less gas.

The paymaster did not have enough deposit to cover the prefund of the UserOp.

Possible Solutions:

  1. Increase the paymaster’s stake and deposit into the EntryPoint.
  2. Ensure the paymaster deposit is sufficient before submitting a UserOp that relies on it.

The paymaster validity window has expired or is not yet active.

Possible Solutions:

  1. Check the paymaster’s time validity parameters.
  2. Submit within the valid timeframe specified by the paymaster’s validation logic.

validatePaymasterUserOp call reverted. This indicates a logic error in the paymaster’s validation code.

Possible Solutions:

  1. Investigate the revert reason using debugging tools.
  2. Ensure that the paymaster’s validation logic is correct and doesn’t revert under the given conditions.

The paymaster’s signature verification (or other form of authorization) failed.

Possible Solutions:

  1. Check the paymaster’s signature or authorization mechanism.
  2. Confirm the correct aggregator or verification method is used if applicable.

The paymaster’s validation logic exceeded its assigned paymasterVerificationGasLimit.

Possible Solutions:

  1. Increase the paymasterVerificationGasLimit.
  2. Reduce the complexity of validatePaymasterUserOp so it fits within the assigned gas limit.

The beneficiary address (the entity that receives the collected fees) is address(0) or invalid.

Possible Solutions:

  1. Set a valid beneficiary address in the handleOps call.
  2. Ensure the beneficiary parameter is not empty.

The EntryPoint failed to transfer the collected fees to the beneficiary.

Possible Solutions:

  1. Ensure the beneficiary is able to receive ETH.
  2. Check if the beneficiary address is a contract that reverts on ETH reception.

A function intended only for internal calls within the EntryPoint was called externally. This occurs if innerHandleOp is invoked by an address other than the EntryPoint itself.

Possible Solutions:

  1. Do not call innerHandleOp directly from outside the EntryPoint.
  2. Ensure you are calling the EntryPoint’s main methods (handleOps, etc.) rather than internal helper methods.

The paymasterAndData field is invalid, too short, or not formatted correctly.

Possible Solutions:

  1. Ensure that paymasterAndData includes the paymaster address and any additional data as required by the paymaster.
  2. Verify that the paymasterAndData length meets the minimum expected size.

One or more gas-related fields in the UserOperation exceed the maximum allowed value (overflows the 120-bit range the EntryPoint uses internally).

Possible Solutions:

  1. Ensure that all gas-related parameters (verificationGasLimit, callGasLimit, paymasterVerificationGasLimit, paymasterPostOpGasLimit, preVerificationGas, maxFeePerGas, maxPriorityFeePerGas) fit within a 120-bit unsigned integer.
  2. Use smaller values for gas parameters to avoid overflow.

The entire operation (or a sub-call) ran out of gas. This is usually due to too low gas limits passed to handleOps.

Possible Solutions:

  1. Increase the gas limit provided to the bundler or handleOps call.
  2. Optimize your code to require less gas.

The aggregator address is invalid. For example, it might be the special address(1) marker used internally or not meet aggregator requirements.

Possible Solutions:

  1. Use a proper aggregator address that implements the IAggregator interface.
  2. Check that you’re not using reserved addresses that are disallowed by the EntryPoint.
Was this page helpful?