On EVM chains, every externally owned account (EOA) sends transactions in a strict sequence. That sequence is enforced with a nonce: an integer that starts at 0 and increments by 1 for each confirmed transaction. A validator can include nonce 57 only if nonce 56 has already been included for that same sender.
This is why a “stuck” transaction often blocks everything behind it. A later transaction can be valid and well-funded, but it cannot be included if an earlier nonce from the same address is still pending. Most wallets surface this as a queue in the Activity tab, and the underlying behavior is consistent across EVM networks.
A wallet can also display a transaction nonce directly. For instance, MetaMask offers nonce view in the transaction details.
A transaction becomes “stuck” when it is acceptable to the sender’s wallet but not attractive enough to propagate and be picked up for inclusion.
The common causes are predictable:
– Low fees are the leading cause. Under EIP-1559, a transaction’s effective cost is shaped by the base fee and a priority fee tip, with the sender specifying a maximum fee cap. If base fee rises above what the transaction can tolerate, the transaction can sit in mempools without being mined until conditions change.
EIP-1559 base fee can move quickly. Ethereum’s base fee adjusts block by block, and it can increase by up to 12.5% after a block exceeds the target size, which can turn a “fine” fee setting into an underpriced transaction in a short window.
Nonce blocking is the second most common cause. A user sends transaction N with low fees, then sends transaction N+1 with higher fees. The N+1 transaction cannot be mined until N is mined or replaced.
Dropped propagation is the third. A transaction hash can exist locally in a wallet’s history while the transaction has fallen out of most mempools, or never propagated widely. At that point, the chain has not rejected it, but the network is not reliably carrying it either.
A useful mental model is that mempools are policies, not consensus. A transaction can be valid under consensus rules and still be filtered, delayed, or replaced under client mempool policies.
These terms describe the same primitive: re-submitting a new transaction that uses the same nonce as the stuck one.
Speeding up keeps the intent the same and improves the fee settings so validators and builders prefer the new version. For example, MetaMask’s Speed up flow re-submits a transaction using the same nonce with a higher gas fee, so the network processes the replacement rather than the original.
Canceling typically means submitting a “do nothing” transaction with the same nonce, usually a 0-value transfer from the sender back to the sender. If that cancel transaction is mined first, the original intent is displaced.
Replacing means intentionally changing the destination or data, but still using the same nonce so the new transaction becomes the canonical one for that nonce.
| Goal | Action | What actually happens | Most common failure mode |
|---|---|---|---|
| Confirm the original intent | Speed up | Same nonce, higher fees | Fee bump is too small, replacement rejected |
| Remove the stuck transaction | Cancel | Same nonce, self-send with higher fees | Cancel mined too slowly, original mines first |
| Change intent entirely | Replace | Same nonce, different to/data | Replacement fails policy checks, nonce stays blocked |
Replacing a pending transaction is not “free.” Mempool clients must decide whether to accept a new transaction that collides with an existing nonce.
On modern Ethereum clients, replacement is typically gated by a minimum fee bump rule. A common default is a 10% bump requirement for replacement, applied to fee fields in EIP-1559 style transactions. Replacement behavior is discussed as a 10% bump in both max fee and max priority fee in transaction pool considerations.
Developers frequently run into this rule as “replacement transaction underpriced” errors when they attempt a same-nonce replacement without increasing fees enough. Hardhat’s explanation mirrors the same policy in a practical form: the replacement fee has to be at least 10% higher than the current transaction’s fee parameters to displace it.
In wallet terms, a replacement that is only slightly higher often fails silently. The wallet may show the new transaction as “submitted,” but nodes reject it, leaving the original stuck transaction still blocking the nonce.
The fee bump also has to be sensible relative to base fee dynamics. If the base fee is rising rapidly, a replacement must raise the max fee enough to remain valid across multiple blocks, not just the next one.
Wallet-native tooling is the cleanest option because it reuses the existing transaction’s nonce without requiring manual nonce controls.
Speed up works when the user wants the same transaction to land, just faster. MetaMask’s Speed up re-submits the same nonce with a higher gas fee, which means the user does not “pay twice” unless two versions are mined, which is uncommon when replacement rules work as intended.
Cancel works when the user wants to clear the nonce without executing the original call. The cancel transaction is a new transaction using the same nonce, usually a self-send with 0 ETH value, and it must offer a higher effective fee than the stuck transaction.
MetaMask also makes it easy to locate and confirm the relevant nonce before acting, which prevents replacing the wrong transaction in a busy account.
The workflow that avoids most frustration is simple: identify the lowest pending nonce for the address, then act on that nonce first. If there are multiple pending transactions, replacing a later nonce does not unblock the earlier nonce.
Some wallets and some networks expose a Custom Nonce feature. This is useful when the wallet UI is stuck, or when the user wants a precise replacement rather than a wallet-generated duplicate.
A widely used manual pattern is a self-send replacement.
The transaction must be on the same network and use the same sender address. A mismatch on chain or address is a different nonce space and does not unblock anything.
Manual replacement also requires clarity about EIP-1559 fields. A replacement should increase both max fee and max priority fee rather than only increasing tip, because nodes evaluate replacement policy against what they can derive as “more expensive” under their mempool rules.
Stuck transaction problems repeat, but they are often misdiagnosed.
If the transaction hash is missing from major explorers, the transaction may never have propagated widely. In that case, it can still block a wallet’s local queue if the wallet is tracking it as pending.
A practical check is to view the address’s pending transaction pool context. Ethereum explorers expose pending transaction views that show a transaction’s nonce and “last seen” time, which helps confirm whether the transaction is still circulating.
If the stuck transaction is effectively gone from mempools, the clean fix is usually a replacement with the same nonce and high fees. The replacement propagates, gets mined, and the wallet’s local state converges again.
This usually means the fee bump is too small. A replacement that increases fees by a tiny amount is often rejected by nodes that enforce a minimum bump policy for same-nonce replacements.
The fix is not to spam replacements. The fix is to submit one replacement with a meaningful increase in max fee and priority fee, then wait for inclusion.
Only the lowest pending nonce matters. Replacing nonce 24 does not unblock nonce 23. The correct approach is to start with the lowest pending nonce and move upward.
RPC nodes can disagree on the pending transaction count because “pending” depends on that node’s mempool view. Even high-quality RPC providers can temporarily diverge if one node has not seen the transaction. This is why checking more than one explorer or RPC provider can clarify whether the issue is local or network-wide.
A stuck transaction is frustrating, but it should not create a second security incident.
Third-party “transaction accelerators” and “nonce fix” sites are common phishing surfaces. The safest approach is to use wallet-native Speed up and Cancel, or to submit a replacement directly from a trusted wallet using a custom nonce.
A second safety rule is to avoid blind signing in a rush. Replacing a stuck swap with a different call because the UI is “stuck” can create unintended approvals or a different routing path than expected. Replacement solves ordering. It does not guarantee the replacement action is safe.
Nonce management on EVM is an ordering problem with a fee-policy wrapper. The fix for a stuck transaction is almost always a same-nonce replacement with a meaningful fee bump, chosen according to the intended outcome: speed up to confirm the original action, cancel to clear the nonce, or replace to change the action entirely. Wallet-native flows like MetaMask Speed up and Cancel work because they reuse the same nonce and re-submit with higher fees, while manual custom-nonce replacements are the fallback when a wallet’s UI cannot recover. The decisive edge is understanding mempool replacement rules and base fee dynamics so the replacement is not merely “higher,” but high enough to be accepted and mined.
The post Nonce Management on EVM: How to Speed Up, Cancel, and Replace a Stuck Transaction appeared first on Crypto Adventure.
