Article & News

A user initiates a token swap on Ethereum through Phantom Wallet, receives a confirmation, but the transaction never lands on-chain. Hours pass. The wallet shows a pending status; the blockchain shows nothing. The user tries again, and now there are two stuck transactions. This scenario occurs often enough that it deserves a precise explanation. The culprit is almost never Phantom itself. It is a fundamental aspect of how blockchains sequence transactions, and how wallet applications communicate that sequencing to users.

Nonce errors represent one of the most common reasons transactions fail or hang indefinitely across Ethereum, Polygon, Base, and other EVM-compatible networks that Phantom supports. A nonce is a sequential number attached to each transaction from a given address, enforcing an order. If a transaction with nonce 5 is broadcast before nonce 4 arrives, the entire sequence stalls until nonce 4 is confirmed. Understanding what happened, why it happened, and how to recover requires looking past the wallet interface and into the blockchain’s actual rules.

How nonces enforce transaction order on EVM networks

Every account on Ethereum, Polygon, Base, and similar networks maintains a transaction counter called a nonce. It begins at zero and increments by one with each confirmed transaction. Before a transaction is accepted into a block, the network validates that its nonce matches the next expected number for that address. A transaction with nonce 10 will wait indefinitely if nonce 9 has not yet been confirmed, no matter how much gas fee is attached.

This design prevents double-spending and enforces causality. If you send 10 tokens to address A with nonce 5, then send those same tokens to address B with nonce 6, the network will reject the second transaction if the first one fails or is not confirmed. Without nonce enforcement, a single transaction confirmation might race against its replacement, and both could theoretically land, producing an inconsistent state.

The problem arises when a wallet, a network condition, or user behavior breaks the assumption that transactions will be broadcast and confirmed in strict order. A user might approve a transaction with nonce 10 while nonce 9 is still pending. Network congestion, a dropped connection, or a browser crash before the transaction is fully broadcast can result in nonce 9 never reaching the blockchain while nonce 10 sits waiting. Phantom calculates the current nonce based on the number of confirmed transactions and any pending transactions it is tracking locally. If that calculation diverges from the actual on-chain nonce, a stuck transaction is the result.

Why Phantom transactions get stuck during high network activity

During periods of network congestion—when a popular NFT drop, a token launch, or volatile market conditions drive up gas prices—transaction mempool behavior changes. Validators prioritize transactions by fee, not just by nonce. A transaction that seemed cheap moments ago may find itself at the back of the queue while newer, higher-fee transactions race ahead.

A scenario: a user initiates a token swap during moderate gas prices, setting a fee of 30 gwei. That transaction enters the mempool with nonce 15. Seconds later, the market moves, and the user decides to increase the swap size or wait for better rates. They approve a second swap with the same wallet, but Phantom has not yet received confirmation that nonce 15 landed on-chain. The new transaction gets nonce 16. If nonce 15 is underpriced and stalls while mempool congestion worsens, nonce 16 cannot confirm either. Both transactions are now stuck, and the user may wrongly assume Phantom is at fault.

The blockchain wallet abstraction makes this invisible to the user. Phantom shows “pending,” but the distinction between “underpriced,” “waiting for earlier transaction,” and “lost” is not displayed. A user who encounters this situation might download phantom extension again, reinstall, or restore from a backup, none of which changes the blockchain state. The stuck transactions remain stuck until the lowest nonce in the sequence is either confirmed or replaced with a higher fee.

Identifying nonce problems before they create cascading failures

The first diagnostic is to check the actual account nonce on-chain using a block explorer such as Etherscan for Ethereum, Polygonscan for Polygon, or the appropriate explorer for your network. Search for your wallet address, and look at the latest confirmed transaction. Note its nonce number. Then check Phantom’s transaction history and pending queue. Do the nonces match in sequence, or is there a gap?

A gap indicates a stuck or dropped transaction. If your last confirmed transaction has nonce 20, but Phantom shows a pending transaction with nonce 22, then nonce 21 is missing from the blockchain. That missing transaction is blocking nonce 22 and everything after it. The block explorer will not list nonce 21 under your address because it was never confirmed, but it may still be in the network mempool, being relayed by nodes.

For Solana, Bitcoin, and Sui, this problem does not occur in the same way because those networks do not use nonces. Solana uses recent block hashes to prevent replay attacks, while Bitcoin relies on UTXOs (unspent transaction outputs) and explicit input selection. Sui uses a different transaction ordering model. Phantom’s support for these networks means that transaction sequencing failures have different causes: insufficient balance, incorrect UTXO selection, or network propagation delays rather than nonce conflicts.

Polygon and Base, being EVM-compatible, use nonces identically to Ethereum. A stuck Polygon transaction with a missing nonce in the sequence should be treated exactly like an Ethereum nonce problem. The recovery process is the same: identify the missing nonce, and replace or cancel the stuck transaction.

Recovery: canceling, replacing, and resending stuck transactions

Once a nonce gap is identified, there are three practical approaches. The first is to cancel the stuck transaction by replacing it with a zero-value transaction (a transaction that sends nothing to yourself) at the same nonce but with a much higher gas fee. The network will confirm this replacement because it has a higher priority, and the missing nonce will be cleared from the sequence.

The second approach is to increase the gas fee of the original pending transaction, a process called “bumping” the fee. Some block explorers and wallet interfaces allow direct fee increases; others require re-creating the transaction with the higher fee. The key is that the nonce must remain the same. Phantom does not always expose a direct fee-bump option in its interface, so users often resort to custom transaction tools or alternative wallets that connect to the same blockchain network.

The third approach is to wait. If the stuck transaction was broadcast to the mempool, validators are still relaying it. A sudden drop in network congestion could allow it to confirm, albeit slowly. However, if several hours have passed and the transaction remains pending while other newer transactions confirm, it is almost certainly underpriced or permanently stuck. Waiting beyond a few hours typically wastes opportunity cost without improving outcomes.

A critical warning: never approve the same transaction twice while the first is still pending in hopes that one will go through. If both confirmations land on-chain, both will execute, potentially draining accounts twice or authorizing twice the intended swap. The correct sequence is to wait for confirmation, check the block explorer, identify the gap, then replace the stuck transaction at the same nonce with a higher fee or a cancel transaction.

Why network selection and gas fee configuration matter more than most users realize

Phantom allows users to choose gas fees in multiple ways: slow, standard, fast, and custom. The distinction between these categories is critical during periods of volatility. A “fast” fee at the time you approve a transaction may become “below average” by the time it enters the mempool if network activity spikes. Conversely, a custom fee set conservatively to save money can lock a transaction in place for hours.

The correct approach is to monitor the current recommended gas price just before approving a transaction, set a fee at or slightly above that recommendation, and only then submit. For high-value swaps or during known volatile periods, erring on the side of higher fees avoids the nonce cascade. The cost of a 50 gwei transaction versus a 100 gwei transaction on Ethereum might be $5–10; the cost of a stuck transaction that forces a cancellation and retry is easily 3–4x that amount in fees plus opportunity cost.

Network selection also shapes risk. Solana has no nonce system and processes transactions in parallel, making stuck-transaction scenarios unlikely but creating different failure modes around account state and transaction versioning. Ethereum has higher fees but more predictable ordering. Polygon and Base are cheaper alternatives to Ethereum but inherit the same nonce architecture. Choosing the right network for a given transaction—balancing speed, cost, and reliability—is a decision that belongs upstream of the gas fee slider.

When Phantom’s local state and the blockchain diverge

Phantom, like all wallet applications, maintains a local record of pending transactions. This record helps the interface show you a preview of what will happen and prevents obvious mistakes like approving the same action twice. However, Phantom’s local state is not the blockchain’s source of truth. If your browser closes, the wallet extension is disabled, or the device reboots, the local pending queue can fall out of sync with the network.

A scenario: you approve a transaction, the browser crashes before it fully propagates, and you restart Phantom. The wallet may show the transaction as pending, but the blockchain never received it. Phantom might then increment the nonce counter anyway when you try again, creating a gap. Alternatively, the wallet might reuse the same nonce, and if the original transaction eventually broadcasts, both could theoretically confirm if the contract or UTXO state allows it.

The safest recovery is to force a wallet refresh. Some wallet interfaces call this “clear pending transactions” or “reset nonce.” Phantom does not have an obvious one-click option for this, so users often resort to checking the block explorer directly and then re-importing the wallet if the local state is severely out of sync. A fresh import of the same recovery phrase will reset the pending queue, but it will not change the blockchain nonce, so any actual stuck transactions must still be cleared separately.

Practical steps to avoid nonce problems going forward

The best strategy is prevention. Before approving any transaction, especially a token swap or large transfer, check the current nonce on the block explorer and confirm it matches Phantom’s count. Approve only one transaction at a time and wait for confirmation before initiating another. If you must approve multiple transactions in quick succession, space them out and monitor each one carefully.

Use the standard or fast gas-fee preset rather than the custom option unless you have monitored the network’s real-time recommended price. If you choose custom, set it to at least 1.1x the currently recommended gas fee, and higher if volatility is evident. For large swaps or transfers, consider breaking them into smaller transactions so that a fee miscalculation affects only a portion of your funds.

Enable transaction notifications if your wallet application supports them, and check the block explorer immediately after approving a transaction. Confirm that it appeared with the correct nonce and is moving toward confirmation. If it sits for more than a few minutes with no progress, check the current recommended gas fee. If the fee you paid is now significantly below the recommendation, prepare to bump it or replace it before attempting a second transaction.

Finally, keep your recovery phrase secure and separate from your device. If a nonce problem forces you to reset or reimport the wallet, you need instant, offline access to that phrase. Storing it in a cloud note, a photo album, or an email account defeats the self-custodial model and introduces additional risks that will eventually overwhelm the protection of cryptographic key management.

Bitcoin, Solana, Sui, and why nonce failures do not apply to non-EVM networks

Phantom’s multichain support means users might deploy assets across Ethereum, Bitcoin, Solana, Sui, and other networks simultaneously. Understanding which networks use nonces is crucial. Ethereum, Polygon, Base, and other EVM-compatible chains enforce nonce ordering. Bitcoin, Solana, and Sui do not.

Bitcoin uses UTXOs, which are discrete, spendable outputs from previous transactions. Each UTXO can be spent only once, and spending is explicit: you choose which UTXOs to combine and send. A stuck or failed Bitcoin transaction does not block others because there is no global transaction counter. However, a UTXO accidentally spent twice is impossible; the blockchain will reject the second spend.

Solana uses recent block hashes for replay protection and relies on account state versioning rather than nonces. A Solana transaction failure typically results from an incorrect block hash, an expired transaction, or a contract logic error—not from sequencing. Sui uses a similar model with different mechanics.

The implication is that if you are experiencing cryptocurrency management problems across multiple networks, the symptoms will differ. A stuck Ethereum swap will block subsequent transactions from that address. A stuck Solana transaction will not block others, but it may fail due to a stale block hash and require rebroadcasting with a fresh hash. A stuck Bitcoin transaction uses a UTXO that cannot be re-spent until confirmed or the transaction is dropped from the mempool.