Avoid Underpriced Replacement Errors by Managing Nonce in Hot Ethereum Accounts

Hot Accounts

A hot account refers to an Ethereum address that is used intensively, such as a centralized exchange’s withdrawal address, which sends many transactions within a short period.

Replacement Transaction Underpriced Exception

If a hot or regular account encounters the error replacement transaction underpriced when sending a transaction, the nonce handling should be examined.

The error typically occurs when a transaction with a certain nonce is already pending in the node (e.g., due to low gas price, network congestion, or an excessively high nonce). When a new transaction is sent with the same nonce, if its gas price is higher it will replace the pending one; if lower, the node rejects it with the underpriced error.

Your Ethereum client already has a pending transaction.

The new transaction uses the same nonce as the pending one.

The new transaction’s gas price is too low to overwrite the pending transaction.

Generally, the gas price of the replacement transaction must exceed the original by at least 10%.

Solutions

Client‑Managed Nonce (Dependent Wallet)

If the private key of the hot account resides in the Ethereum client, simply omit the nonce when sending a transaction; the client will automatically assign the correct nonce order.

Drawbacks: 1) Security concerns because the private key is stored without hot‑cold separation. 2) When you need to replace a transaction, you must first query the pending transaction to obtain its nonce.

Self‑Managed Nonce

This approach suits hot‑cold account models where transactions are signed offline (e.g., using sendRawTransaction) and the nonce is already embedded in the signed payload.

Implementation steps:

Maintain a monotonically increasing nonce sequence in your business system.

After a transaction is sent, increment the stored nonce.

Limitations:

The address must be internal, and all outgoing transactions must use the centrally managed nonce; otherwise, external transactions can cause nonce collisions.

If a sent transaction fails and its nonce remains unused, that nonce must be reused before subsequent nonces become valid.

Conclusion

Nonce handling contains many pitfalls; developers should monitor pending transactions, adjust gas prices appropriately, and choose a nonce management strategy that fits their architecture to avoid large‑scale accounting or fund inconsistencies.