I'm calling eth_getTransactionCount via JSON RPC, and taking that value and trying to use it as nonce for a RawTransaction to send ETH. I'm running this against a ganache server.

This happens in a loop (I'm doing load testing). All of these transactions have the same source address, but different destination.

Under no load, this works fine. Under moderate load, it seems like ganache is somehow getting backlogged, resulting in errors like the following:

"the tx doesn't have the correct nonce. account has nonce of: 4222 tx has nonce of: 4191"

But I got that 4191 from eth_getTransactionCount! I've tried using "latest" and "pending" for the block parameter, but I'm still getting a number that is lagging behind the proper nonce for some reason.

Any idea what might be causing this, or how to work around it?

My current workaround is to look for that error message and extract the nonce from it, but that feels... hacky.

  • Hi! Welcome to Ethereum Stackexchange! Do you have the source code to test? I'll avoid calling eth_getTransactionCount in a tight loop. Just call once outside and keep track yourself of the last nonce used, every eth_getTransactionCount involves a JSON-RPC call that can be avoided. Also it could be that ganache is a test tool it was never mean to be as performant as a full client like geth, parity or besu.
    – Ismael
    Nov 21, 2021 at 5:00

1 Answer 1


This happens because eth_getTransactionCount returns the nonce of mined transactions but not the pending ones. So in your case, under heavy load, there will be some transactions that are still pending but not counted by calling eth_getTransactionCount.

I've been looking for a solution for this problem but I haven't found an official one. However, you can have a look at the solutions proposed here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.