Skip to main content

​
Overview

  • Helps you interpret errorReason and errorDetails fields returned on failed transactions.
  • Guides you through systematic checks to identify the root cause of a failure.

​
Prerequisites

Before you begin:
  • You have a failed transaction with an errorReason of ESTIMATION_ERROR or another error code.
  • You have reviewed the error fields in the transaction object. See Transaction states and errors for a full list of error codes and their meanings.

​
Steps

​
Step 1. Read the error message

Check the errorDetails field carefully. Many errors are self-explanatory, for example, “Insufficient balance” or “Not authorized.” Cross-reference the value against the ESTIMATION_ERROR details tables to identify the category and recommended remedy.

​
Step 2. Verify contract addresses

Confirm that you are interacting with the correct contract on the correct network. A transaction sent to the wrong contract address or the wrong network will fail or produce unexpected results.

​
Step 3. Verify transaction parameters

Ensure all addresses, amounts, and other parameters are correct:
  • Recipient addresses are valid and non-zero.
  • Token amounts meet or exceed any minimum thresholds.
  • ABI signatures match the function being called.

​
Step 4. Check token balances and allowances

Many errors stem from insufficient balances or missing approvals:
  • Verify the wallet has enough of the token being transferred.
  • For ERC-20 interactions involving a spending contract, confirm the wallet has called approve() to grant sufficient allowance.

​
Step 5. Review contract state

Some operations are only valid in certain contract states. Confirm that the contract is not paused and that any role-based access requirements are satisfied.

​
Step 6. Verify authorization

Ensure the calling wallet has the permissions required by the contract. Check for role assignments and blocklist status if you are working with regulated tokens such as USDC.

​
Step 7. Retry time-sensitive operations

For errors related to expired signatures, nonces, or network conditions, retry the operation:
  • Generate a fresh signature or nonce if the original has expired.
  • Retry after a short delay if the error suggests an RPC node was temporarily unavailable.

​
Debug with Tenderly

For complex errors where errorDetails does not provide enough information, use Tenderly to simulate and inspect the failing transaction. Tenderly lets you step through execution and identify exactly where and why the transaction reverts.