Nonce Increment Gaps After web3js Pending Transaction Drop

Question

When a web3js sendTransaction remains pending, the library does not automatically increment the sender's nonce on retry. The precise goal is to identify a retry pattern that guarantees write-idempotency for signed transactions without requiring the developer to manually maintain a nonce counter that survives mempool eviction and chain reorganization.If the original transaction mines successfully and a resend reuses the same nonce, the network rejects the duplicate, preventing unintended writes. However, if the pending transaction is dropped from the mempool before mining, the nonce does not advance, leaving a gap that subsequent transactions must offset. This gap can cause sequence errors or, if the developer resends without incrementing, silently duplicate the write once the original eventually confirms. EIP-1559's maxFeePerGas and maxPriorityFeePerGas do not influence nonce behavior, leaving retry safety dependent solely on nonce management.How should a developer detect mempool eviction before resending? What nonce value should be used if the original transaction's status remains ambiguous? Can transaction receipt polling reliably prevent duplicate writes in all network conditions?

Tasadduq Burney · Answer

Direct answerDetect mempool eviction with a heuristic, not an on-chain event. Use nonce = max(confirmed nonce + 1, highest still-visible pending nonce for the sender). Receipt polling alone cannot guarantee duplicate prevention under reorgs or node-specific mempool views.Confirmed factsweb3.js does not maintain a durable nonce counter for raw signed transactions. Nonce is chain-determined.EIP-1559 fields maxFeePerGas and maxPriorityFeePerGas do not influence nonce behavior.Reusing the same nonce with identical call data is rejected by the network if the original is mined, providing natural idempotency for replacements.eth_getTransactionCount with 'pending' returns the next nonce assuming mempool inclusion; 'latest' returns only confirmed nonce.Mempool eviction has no on-chain event.Likely explanationSilent duplicate writes arise only when a developer increments the nonce on retry while the original is still pending and later mines. Keeping nonce stable for retries and only advancing after confirmed inclusion preserves write idempotency. Node mempool views differ by provider and region, so a tx absent on one RPC may still be pending elsewhere. Chain reorganizations can make a receipt appear then disappear.Steps for this caseRecord at send time: txHash, from, nonce, data, and fee parameters. Do not rely on web3.js internal state across restarts.Poll receipt for a bounded block window. Poll eth_getTransactionReceipt and eth_getTransactionByHash every few seconds. If receipt is null and the tx is no longer retrievable on your RPCs, treat as evicted.Before resend, query eth_getTransactionCount('latest') and 'pending' for the sender. Determine highest visible pending nonce.If the original tx is still visible: resend the same call data with the same nonce and a higher fee for replacement.If the original tx is not visible: treat it as evicted. The next usable nonce is confirmed nonce + 1. Do not skip. For a new logical operation, use that nonce. For a retry of the same operation, reuse the original nonce with higher fee until visibility is confirmed.Receipt polling is not sufficient alone for all network conditions. Treat a receipt as final only after sufficient confirmations for your target security level.One missing diagnosticAre you sending raw signed transactions off-chain where you control nonce persistence, or using web3.eth.sendTransaction with the provider managing nonce? The recommendation for durable storage differs.

Nonce Increment Gaps After web3js Pending Transaction Drop

1 answer

Direct answer

Confirmed facts

Likely explanation

Steps for this case

One missing diagnostic

Your perspective belongs here.

0 question comments