Imagine a backend service sending transactions from the same Ethereum wallet. The first transaction is still pending when the application creates another one. Because the application has not updated its nonce correctly, both transactions are assigned the same nonce.
Now what happens?
Can both transactions execute? Does one replace the other? Why might the second transaction return a nonce too low or replacement transaction underpriced error?
These situations are common when applications submit multiple EVM transactions concurrently. Understanding how nonce management works is therefore important for developers building wallets, trading systems, DeFi applications, payment platforms, and blockchain automation services.
What Is a Nonce in an EVM Transaction?
A nonce is a sequence number associated with an account. For transactions sent from the same Ethereum or EVM-compatible account, the nonce determines their transaction order.
For example, a wallet might have transactions like this:
Nonce 10 → Transaction A
Nonce 11 → Transaction B
Nonce 12 → Transaction C
The transaction with nonce 10 needs to be processed before the transaction with nonce 11, and so on.
The nonce is not a global blockchain counter. It belongs to the individual sender account. This means two different wallets can have the same nonce without creating a conflict.
The problem occurs when two transactions from the same wallet use the same nonce.
How Can Two Transactions Get the Same Nonce?
A nonce conflict can happen when multiple transactions are generated almost simultaneously.
Consider an application that reads the wallet's current transaction count:
Current nonce = 15
The application creates Transaction A:
Transaction A → Nonce 15
Before Transaction A is confirmed, another process asks for the wallet's nonce. If the application does not account for the pending transaction, it may create:
Transaction B → Nonce 15
Now both transactions are competing for the same nonce.
This can happen in several ways:
- Multiple backend workers send transactions from the same wallet.
- Several API requests trigger blockchain transactions at nearly the same time.
- The application tracks only confirmed transactions.
- Nonce state is stored locally but is not synchronized between workers.
- An RPC node provides a view of the account state that does not include a transaction already being managed elsewhere.
For applications sending transactions concurrently, nonce assignment needs to be treated as a coordinated process rather than something every worker calculates independently.
What Happens When Both Transactions Enter the Mempool?
When a transaction is submitted, it is propagated to nodes and may remain pending before being included in a block.
If two transactions from the same account use nonce 15, they cannot both represent separate sequential positions in the account's transaction sequence.
For example:
Transaction A
Sender: 0xABC...
Nonce: 15Transaction B
Sender: 0xABC...
Nonce: 15
The transactions are effectively competing for the same nonce position.
EVM clients have transaction-pool rules for handling this situation. Depending on the client and transaction conditions, a second transaction may be rejected, or it may be considered as a replacement candidate for the first transaction.
This is where transaction fees become important.
A replacement transaction generally needs to satisfy the node's replacement rules, which commonly require a sufficient fee increase over the transaction already occupying that nonce in the local transaction pool.
That is why submitting another transaction with the same nonce does not automatically mean the first one will be replaced.
Can Both Transactions Be Confirmed?
No. Two transactions from the same account cannot both be included in the canonical chain using the same nonce.
Suppose the following transactions exist:
Transaction A → Nonce 15 → Send 1 ETH
Transaction B → Nonce 15 → Call Smart Contract
If Transaction A is included in the canonical chain, nonce 15 has been consumed by that account.
Transaction B cannot subsequently execute as another transaction with nonce 15.
The result can therefore look like:
Transaction A → Nonce 15 → Confirmed
Transaction B → Nonce 15 → Not executable as a second canonical transaction
This sequencing mechanism is important because it prevents multiple conflicting transactions from the same account from occupying the same transaction position.
The Replacement Transaction Scenario
There is an important distinction between an accidental duplicate nonce and an intentional replacement.
Suppose a user sends a transaction with nonce 15, but it remains pending:
Nonce: 15
Fee: Lower
Status: Pending
The user may submit another transaction using the same nonce with a higher fee:
Nonce: 15
Fee: Higher
Status: Pending
The purpose is to give the replacement transaction a better chance of being accepted by nodes and included in a block.
Wallet applications may expose this behavior through features such as speed up or transaction replacement.
A replacement does not mean both transactions will execute. The nonce still represents one transaction position.
If the replacement is accepted and eventually included in the canonical chain, the original transaction cannot later execute using that same nonce.
This is why developers should think of nonce replacement as a competition for one transaction slot rather than two independent transactions.
What Developers See When Nonce Management Goes Wrong
Nonce conflicts often become visible through RPC or wallet errors.
nonce too low
This generally indicates that the submitted nonce is already below the account's expected transaction sequence. For example, another transaction may already have consumed that nonce.
replacement transaction underpriced
This can occur when an application submits a transaction with the same nonce as an existing pending transaction but does not increase the fee enough to satisfy the node's replacement requirements.
already known
A node may return this when the transaction being submitted is already known to its transaction pool.
There can also be less obvious symptoms.
A transaction may remain pending because a later transaction depends on an earlier nonce. For example:
Nonce 20 → Pending
Nonce 21 → Waiting
Nonce 22 → Waiting
Even though transactions 21 and 22 have already been created, the account's transaction sequence cannot simply skip nonce 20.
This is one reason nonce problems can appear as broader transaction-processing failures in production systems.
How Applications Prevent Nonce Conflicts
For a simple wallet sending occasional transactions, nonce management may appear straightforward. It becomes much more important when several application processes can send transactions from the same account.
Track Pending Transactions
Applications should account for transactions that have already been submitted but have not yet been confirmed.
Looking only at the latest confirmed transaction can cause multiple workers to select the same next nonce.
Use a Nonce Manager
A dedicated nonce manager can assign each outgoing transaction a unique sequence:
Transaction Request
↓
Nonce Manager
↓
Nonce 25 assigned
↓
Transaction signed
↓
RPC submission
The next request receives nonce 26, even if transaction 25 is still pending
Serialize Transaction Creation
A transaction queue can prevent several workers from assigning the same nonce simultaneously.
For example:
Transaction Requests
↓
Transaction Queue
↓
Nonce Assignment
↓
Transaction Signing
↓
RPC Node
↓
Blockchain
This becomes especially useful for exchanges, automated trading systems, payment services, and other applications that generate transactions at high frequency.
Handle Replacements Carefully
If a transaction needs to be replaced, the application needs to preserve the same nonce while applying the appropriate replacement fee rules.
It should also track which transaction is currently considered active for that nonce.
A Simple Real-World Example
Consider a wallet whose next available nonce is 42.
Two requests arrive almost simultaneously:
Request A → Nonce 42 → Transfer tokens
Request B → Nonce 42 → Call a smart contract
Both transactions cannot independently execute.
If Request A is accepted into the transaction pool and Request B does not meet the replacement requirements, Request B may be rejected.
If Request B is submitted as a valid replacement with the required fee increase, it may replace Request A in the relevant transaction pool.
Eventually, only one transaction can consume nonce 42 on the canonical chain.
After that, the next transaction from the wallet needs the following nonce:
Nonce 42 → One transaction
Nonce 43 → Next transaction
Nonce 44 → Next transaction
The key point is that the nonce is tied to the account's transaction sequence, not to the individual application request.
Why Nonce Management Matters in Production
Nonce conflicts become more significant as blockchain applications scale.
A crypto exchange may have multiple services interacting with the same operational wallet. A trading bot may generate several transactions within seconds. A DeFi application may trigger automated contract interactions based on market conditions.
If all these processes independently determine the next nonce, collisions can occur.
A production transaction system therefore needs to treat nonce assignment as part of its infrastructure.
A typical architecture might include:
Application Services
↓
Transaction Queue
↓
Nonce Manager
↓
Signer
↓
RPC Provider
↓
Blockchain Network
This approach separates transaction generation from nonce assignment and gives the application a controlled way to track pending, confirmed, failed, and replacement transactions.
Conclusion
A nonce is more than a number attached to an EVM transaction. It determines where that transaction fits into the sequence of transactions sent by a particular account.
When two transactions from the same wallet use the same nonce, they compete for the same transaction position. Both cannot execute with that nonce on the canonical chain. Depending on the transaction-pool rules and fee configuration, one may replace the other while pending, or the second transaction may be rejected.
For developers, the bigger lesson is that nonce management needs to account for pending transactions, concurrent requests, transaction replacement, and transaction ordering.
As blockchain applications move toward higher transaction volumes and more automated workflows, reliable nonce management becomes an important part of the transaction infrastructure itself.
Top comments (0)