Why Your Ethereum Transaction Stalls: The Hidden Role of Incorrect Nonce

Background

When using Ethereum JSON‑RPC interfaces such as eth_sendTransaction or eth_sendRawTransaction, developers sometimes see a transaction hash returned but the transaction never gets confirmed, even though a dev‑mode geth node is mining normally.

Problem Tracking

Typical symptoms include:

Calling the RPC methods returns a hash, yet the transaction’s blockNumber is null when queried with eth_getTransaction.

The transaction appears in txpool.content under the queued section and never moves to pending.

Executing the same transaction directly from the console often confirms instantly, indicating the issue is specific to the RPC call.

The root cause is an incorrect nonce supplied with the transaction.

Nonce Usage Guidelines

Each account’s transactions must include a sequential nonce starting at 0. The geth client processes transactions in strict nonce order, so the following rules apply:

If the nonce is too low, the transaction is rejected outright.

If the nonce is too high, the transaction stays in the queue, producing the “stuck” behavior described above.

Sending a transaction with a large nonce while filling in the missing intermediate nonces will still allow execution once the missing transactions are submitted.

Stopping the geth client clears the transaction queue, causing queued transactions to be dropped.

Conclusion

Check the nonce of any transaction that appears stuck after an RPC call. Ensure it matches the expected sequential value for the sending account, or fill in any missing nonces to allow the transaction to be processed.