One missing nonce can block every later transaction from your payout wallet. A zero difference between pending and latest does not prove the queue is clear.
To detect that failure, track submitted transactions alongside your node's pending nonce. This guide shows which JSON-RPC calls to poll, when to alert, and how to replace a blocked transaction. It applies to Ethereum wallets, relayers, and payout services.
Read the account nonce with both block tags
Set RPC_URL to your Ethereum endpoint and WALLET to the sender's address. Query both tags through the provider you use for transaction submission:
for TAG in latest pending; do
curl -sS "$RPC_URL" \
-H 'content-type: application/json' \
-d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"eth_getTransactionCount\",\"params\":[\"$WALLET\",\"$TAG\"]}"
done
The result is a hexadecimal account nonce. For an ordinary sender, interpret the difference as follows:
| Tag | What it tells you | Limit |
|---|---|---|
latest | Account nonce at the node's current head | The head can reorganize |
pending | Account nonce after the node's executable pending sequence | Queued transactions beyond a missing nonce may not advance it |
pending - latest | Length of that executable sequence | It does not count every submitted transaction |
For example, suppose latest is 10. If the node has executable transactions at nonces 10, 11, and 12, pending is 13. The difference is 3.
Now suppose nonce 10 disappears while nonce 11 remains queued. Both tags can return 10. The difference is zero, but transaction 11 cannot execute. Geth distinguishes executable pending transactions from queued transactions.
Keep a durable record of every allocated nonce and submitted hash. Polling account nonces cannot replace that record.
Use a consistent submission endpoint, but check how it routes requests. A shared URL can distribute requests across nodes with different transaction pools. Ask your provider about routing guarantees before treating that URL as one node.
Detect blocked transactions
Start with a 15 to 30 second poll interval for Ethereum L1. Treat this as an initial setting, then tune it to your settlement deadline.
- Read
latest,pending, and the current block number for each sender. - Compare both nonces with your allocation records and unresolved hashes.
- Flag the lowest unresolved nonce when new blocks arrive without progress.
- Check for a missing nonce below higher submitted nonces, including when
pending == latest. - Look up every candidate hash at the blocked nonce with
eth_getTransactionByHashandeth_getTransactionReceipt.
A null transaction result means that endpoint cannot find the hash. It does not prove that no other node holds it. A receipt identifies an included transaction, but your application must still apply its confirmation policy.
Compare your allocator's next nonce with chain state before changing it. A higher local nonce can reflect reserved or submitted transactions that this node has not seen. Resetting it blindly can replace valid work.
Parallel senders need one allocator per wallet, or another allocation mechanism that guarantees unique nonces. Two services can read the same pending value before either transaction reaches the node.
Replace the lowest blocked nonce
Resolve the lowest blocked nonce before submitting more transactions from that wallet. Higher nonces cannot bypass it.
| Symptom | Check first | Recovery |
|---|---|---|
| Transaction remains pending across new blocks | Fee caps and sender balance | Replace at the same nonce if the fee is inadequate |
| A tracked hash returns null | Receipts, replacement hashes, and submission logs | Rebroadcast the original or submit a replacement |
nonce too low | Current chain nonce and receipts | Reconcile the allocator before submitting again |
replacement transaction underpriced | The node's replacement threshold | Increase both EIP-1559 fee caps as required |
| Higher nonces remain queued | The lowest missing or blocked nonce | Resolve that nonce before resuming the sender |
For an EIP-1559 replacement, keep the same nonce and increase maxFeePerGas and maxPriorityFeePerGas. Geth's default transaction replacement bump is 10%. Other clients and provider configurations can use different thresholds.
The replacement also needs enough fee capacity for the current base fee. Satisfying the replacement rule does not guarantee inclusion.
For a sender with no account code, a zero-value self-transfer can replace the original action. Use empty data and the same nonce. This cancellation races the original transaction. Check which hash receives a receipt before updating application state.
Check eth_getCode before using that cancellation pattern. EIP-7702 delegation lets an externally owned account execute code when called, including by a self-transfer. Follow the wallet's cancellation procedure when account code is present.
Rejected submissions do not consume onchain gas. A transaction that reaches the chain can consume gas even if execution reverts. RPC billing is separate.
After inclusion, reconcile the consumed nonce and all replacement hashes. Keep later nonce reservations intact.
Understand the node's mempool limits
A node only reports transactions it has received. Its pending view can differ from another provider's view or a builder's private transaction flow.
Standard submission through an authenticated RPC URL does not make a transaction private. The node can still broadcast it to peers. Use a service that explicitly supports private submission when your application requires it.
Geth's txpool_content exposes pending and queued transactions, but it is a nonstandard method. Check whether your endpoint supports it. Keep the core monitor usable with standard nonce, transaction, and receipt methods.
For accounts you do not control, you cannot reconstruct every submitted transaction from one public mempool feed. Label such monitoring as partial visibility.
Set alerts from settlement deadlines
Alert on unresolved work and elapsed time. A large queue can be normal during a payout batch; an idle queue with one missing nonce can be an incident.
| Signal | Initial rule | Action |
|---|---|---|
| No nonce progress | Unresolved submissions persist across 8 to 12 new Ethereum L1 blocks | Inspect the lowest unresolved nonce |
| Missing nonce | A higher nonce is submitted while the lower nonce has no known transaction | Reconcile allocation and submission records |
| Missing hash | The endpoint stops returning a tracked hash without a known receipt or replacement | Investigate before rebroadcasting |
| Inadequate fee cap | maxFeePerGas is below the current base fee | Reprice or wait according to the deadline |
| Low priority fee | The offered tip trails recent inclusion samples | Assess inclusion delay; this alone does not prove failure |
| Provider disagreement | Endpoints return different pending nonces | Check routing and propagation before resetting the allocator |
The 8 to 12 block window is a starting example, not an Ethereum rule. Tune alerts against observed inclusion times and your user-facing deadline. For L2s, measure sequencer behavior instead of copying an L1 block threshold.
Put the monitor into service
Store nonce allocations before submission. Retain every replacement hash until you know which transaction executed. Alert on a missed settlement deadline even when the RPC endpoint remains responsive.
For the underlying concepts, see what a nonce is and what a mempool is. To check endpoint routing and transaction-pool access for your deployment, contact the Dwellir team.
