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.)

AA10 sender already constructed

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.

AA13 initCode failed or OOG

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).

AA14 initCode must return sender

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.

AA15 initCode must create sender

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.

AA21 didn't pay prefund

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.

AA22 expired or not due

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.

AA23 reverted

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.

AA24 signature error

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.

AA25 invalid account nonce

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.

AA26 over verificationGasLimit

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.

AA31 paymaster deposit too low

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.

AA32 paymaster expired or not due

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.

AA33 reverted

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.

AA34 signature error

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.

AA36 over paymasterVerificationGasLimit

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.

AA90 invalid beneficiary

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.

AA91 failed send to beneficiary

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.

AA92 internal call only

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.

AA93 invalid paymasterAndData

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.

AA94 gas values overflow

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.

AA95 out of gas

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.

AA96 invalid aggregator

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.
ReadMe