Recovery

Recovery explains how to recover long-pending transactions with a same-nonce replacement transaction, and how to resubmit rejected transactions after resolving the cause. The procedure consists of checking the pending state with a transaction lookup, submitting a replacement transaction with a higher fee, and then checking which transaction was included in a block.

Withdrawal delays are mostly caused by one of fee, nonce, or balance, and each cause has a defined response. When you define response procedures by symptom in advance, you can respond quickly to customer inquiries and internal escalations during a withdrawal delay.

Use Cases

Withdrawal OpsAccelerate pending withdrawals
Resubmit a withdrawal that is pending because its fee is lower than the network rate, using a same-nonce replacement transaction. Later withdrawals that were waiting on the same address are processed as well.
Withdrawal OpsCancel an incorrect withdrawal
Before block inclusion, submit a transaction with the same nonce that sends to your own address. If the replacement transaction is included in a block, the original withdrawal is not processed.
EngineeringResubmit dropped transactions
Resubmit, with the same nonce, a transaction that was dropped from the node and can no longer be retrieved. The earlier transaction can still be included in a block later, so check the inclusion of both transactions.

Available APIs

Responses by Symptom

Symptom	Cause	Response
A transaction stays pending for a long time	The fee is lower than the network rate	Submit a same-nonce replacement transaction with a higher fee
All later transactions are pending	A transaction with an earlier nonce is pending or missing	Replace or resubmit starting from the lowest pending nonce
`nonce too low` is returned on submission	The nonce has already been used	Retrieve the next nonce again and rebuild the transaction
`insufficient funds` is returned on submission	The balance is insufficient to cover the gas fee and the transfer amount	Top up the balance and submit again
The transaction cannot be retrieved	It was dropped from the node's pending transaction list	Resubmit with the same nonce, and check whether the earlier transaction is included later

Replacement Rules

The replacement transaction must have the same sender address and nonce as the original transaction.
Set both maxFeePerGas and maxPriorityFeePerGas higher than the original values. Node clients allow a replacement only when the fees are raised by a minimum percentage (for example, the Geth default of 10%), and return replacement transaction underpriced when the increase is below that threshold.
Even after you submit a replacement, the original transaction can still be included in a block first. Store both transaction hashes, check which one was included in a block with eth_getTransactionReceipt, and reflect that one in the ledger.