An Ethereum account's outgoing transactions use sequential nonces. A transaction with the next expected nonce can be processed; a later one generally waits until earlier positions are resolved. This nonce has a different role from the proof-of-work nonce that miners vary while searching for a block hash. Both relate to uniqueness, but one sequences account instructions and the other is part of a mining search.

Consider an account whose next transaction nonce is 12. If a low-fee transaction occupies 12 while a later transaction uses 13, raising only the fee on 13 will not make the missing sequence position disappear. Wallet replacement workflows normally submit a different transaction using 12 with fees sufficient for the relevant node's replacement policy. Only one conflicting transaction can occupy that sequence position in a particular accepted history; a replacement is not a guaranteed cancellation.

Two applications submitting transactions from the same account must coordinate nonces or they may collide. Pending transaction counts also depend on what the queried node has seen, so a single RPC response is not a complete global inventory. After a reorganization, inclusion may change before finality. When investigating a stuck transaction, compare its nonce, account history, pending transactions, and network rather than repeatedly submitting unrelated transactions and assuming the wallet balance explains the problem.