Hardhat Network and Ethers.js: Transaction Retry Logic and Nonce Synchronization

Question

Managing Transaction Retries in Local Environments
When integrating Ethers.js with the Hardhat Network, the provider manages the transaction lifecycle by wrapping RPC calls. A challenge arises when implementing custom retry logic for transactions that fail to reach a confirmed state due to network timeouts or provider-level interruptions.
The Hardhat Network enforces strict sequential nonce management. If a transaction is submitted and successfully included in a block, any subsequent retry using the same nonce is rejected by the EVM. Conversely, incrementing the nonce for a retry to bypass this rejection can create gaps in the sequence, potentially stalling future transactions from the same account.
Given that Hardhat does not provide a native retry mechanism, the responsibility falls on the client-side implementation to determine if a transaction was actually processed before attempting a resubmission.

How can a provider verify the inclusion of a transaction in the Hardhat Network before initiating a retry to avoid duplicate nonce errors?
What is the recommended strategy for handling retries without creating nonce gaps that block subsequent transaction execution?

Tasadduq Burney · Answer

Answering the Core Questions
1. How to confirm a transaction was actually mined before retrying?

After calling provider.sendTransaction(tx), wait for the txHash and then call provider.waitForTransaction(txHash, 1) (or simply await provider.getTransactionReceipt(txHash)). If a receipt is returned and receipt.status === 1, the transaction reached a confirmed state.
If the receipt is null or the call throws a timeout or execution reverted error, treat the transaction as “unconfirmed” and consider a retry.
Never assume that a thrown error means the transaction was mined; always double‑check the receipt.

2. Recommended retry strategy that avoids nonce gaps

Before each send, fetch the current pending nonce:
const nonce = await provider.getTransactionCount(address, "pending");

This returns the number of transactions that are already queued or mined, ensuring you use the next free nonce.
Bundle your retry logic into a helper that:

Attempts to send the transaction.
Waits for a receipt or a timeout.
If the receipt is missing or the gas price is too low, re‑fetch the pending nonce and resend with a higher gas price.
Limit the number of retries (e.g., 3 attempts) and back‑off exponentially.

Do not increment the nonce manually; let getTransactionCount(..., "pending") handle it. This keeps the nonce sequence continuous even after a reset or a fork.
When you reset the Hardhat chain (e.g., hre.network.reset()), the nonce counter clears. Run a fresh getTransactionCount(..., "pending") immediately after to sync.

Practical Verification Steps

Send two transactions concurrently from the same account and log nonce before each send. Verify that Hardhat increments correctly.
Simulate a timeout by setting a very short timeout on waitForTransaction and confirm your retry logic re‑fetches the nonce.
After a hre.network.reset(), call provider.getTransactionCount(address, "pending") and ensure it returns 0.

Missing Diagnostic Detail
Could you share how your current retry loop is structured? Knowing whether you use waitForTransaction or getTransactionReceipt directly will help fine‑tune the guidance.

Hardhat Network and Ethers.js: Transaction Retry Logic and Nonce Synchronization

Managing Transaction Retries in Local Environments

1 answer

Answering the Core Questions

Practical Verification Steps

Missing Diagnostic Detail

Your perspective belongs here.

1 question comment

Version-specific nonce release on timeout

Prefer receipt existence over pending nonce

Concurrent sends need explicit nonce assignment