Problem

When using eth_getTransactionCount on Base, you may see:

• Nonces jumping backwards (e.g., 1 → 2 → 3 → 2 → 2 → 5)

• "Nonce too low" or "known transaction" errors

• Transactions failing or getting stuck

This typically happens when sending multiple transactions quickly from the same address.

Why This Happens

Base's Flashblocks feature adds pending transactions to a cache when calculating nonces. This cache state can vary between nodes, causing eth_getTransactionCount with "pending" to return inconsistent values.

Solutions

Option 1: Disable Flashblocks (Easiest Fix)

If you're using Flashblocks, disable it.

This resolves the nonce inconsistency immediately. Your transactions will still process normally through regular Base blocks - you'll just lose sub-second pre-confirmations.

This fixes the issue for most users.

Option 2: Manage Nonces Client-Side (For Advanced Users)

If you need Flashblocks or high-volume transaction sending, manage nonces in your application:

1. Get starting nonce once: web3.eth.getTransactionCount(address, "latest")

2. Store it locally and increment for each transaction sent

3. Persist to database to survive restarts

4. Only re-query the network if you hit errors

Key Points:

• Always use "latest", never "pending"

• Use locks/atomic operations if sending from multiple processes

Option 3: Query with "latest" Parameter

As a fallback, always query with "latest" instead of "pending" and add retry logic for failures. This is less reliable but may work for simple, low-volume applications.

Which Solution Should I Use?

Technical Background

Base uses a centralised sequencer without a public mempool. When you query with "pending", Base calculates the pending nonce as: latest confirmed nonce + pending transactions in Flashblocks cache.

Since the Flashblocks cache isn't perfectly synchronised across all Base nodes, different requests can return different pending nonce values. This is a known limitation of Base's architecture.

Need Help? Contact Quicknode Support for further assistance.