A user opens their MetaMask wallet extension on Chrome, approves what appears to be a routine token swap, and sees the transaction stuck in pending status for hours or even days. The interface shows no error message, the funds appear to have left the account, but the transaction remains unconfirmed on the blockchain. This scenario is one of the most common sources of frustration with self-custody wallets, and it typically has concrete technical causes that can be addressed without losing the assets.

The metamask wallet extension is a powerful tool for managing Ethereum and multichain assets across EVM networks, Bitcoin, Solana, and numerous decentralized applications. But its power comes with responsibility: the wallet displays what you authorize, but it cannot prevent poorly configured transactions, insufficient gas estimation, or network congestion from causing delays or failed settlements. Understanding why transactions stick and learning the adjustment methods available in the extension can turn a frustrating situation into a manageable one.

How gas estimation becomes the hidden reason for pending transactions

Every transaction on an EVM network requires gas, a unit of computational work priced in wei (fractions of ETH). The gas estimation process happens when you authorize a transaction: MetaMask calculates how much computational fuel the transaction will consume and multiplies that by the current network fee rate. If the estimate is too low, the transaction will sit in the mempool—the waiting area where miners or validators look for profitable transactions to include in blocks. Network nodes will eventually discard it if it remains unpicked for too long.

The wallet’s gas estimation is usually conservative enough to work, but “usually” is not a guarantee. During periods of network congestion, the fee rates can spike faster than the wallet’s algorithm predicts. A transaction that appeared correctly priced when approved may become unprofitable to include within minutes. Additionally, some decentralized applications or custom contract interactions may consume more gas than a standard transfer, yet the dApp interface may request an estimate that does not account for actual complexity. The result is a transaction that broadcasts to the network but never makes it into a block.

Users often interpret a pending transaction as a sign that something is broken or that their assets are lost. In reality, the transaction is reversible because it has not been confirmed. The funds remain in the sending account, held in a temporary state until either the transaction is picked up and executed or it is discarded by the network after a timeout period. Understanding this distinction is the first step toward fixing the problem rather than repeating it.

Why MetaMask wallet extension pending transactions require active intervention

Self-custody wallets like MetaMask do not have a central authority that can cancel or rush a transaction on your behalf. Centralized exchanges can do so because they control all account keys; a self-custody wallet explicitly puts that control in your hands. The trade-off is that you must also manage the consequences of your own transaction configuration choices. A pending transaction remains pending until the network processes it, or until you take deliberate action to replace it.

The most practical action is to speed up the transaction by resubmitting it with a higher gas price. In MetaMask, this is called “speeding up,” and it works by creating a new transaction with the same destination and amount but a higher gas fee. Because gas fees are sorted by price in the mempool, raising the fee makes your transaction more attractive to miners and validators. The original pending transaction will be replaced by the new one; the network does not execute both.

A second option is to cancel the transaction entirely. This is done by sending a zero-value transaction to your own address with the same nonce—a unique identifier that prevents the same transaction from being executed twice. MetaMask streamlines this by offering a “Cancel” button in the activity tab for pending transactions. Canceling is useful if you realize you approved an incorrect amount or destination, or if you want to clear a backlog of pending transactions before starting fresh.

Both options require the user to spend additional gas. You cannot speed up or cancel a transaction for free; you are paying the network again to update its queue. This is often frustrating, but it is the intended mechanism: if you could fix pending transactions for free, that would create an incentive for users to submit low-fee transactions immediately and adjust later without cost, which would bloat the mempool with deliberate placeholders.

Step-by-step: speeding up a stuck transaction in MetaMask

Open your MetaMask wallet extension and navigate to the Activity tab. Locate the transaction with the “Pending” status and click on it. The detail view will show the sender, recipient, amount, and gas information. At the bottom of the detail window, you will see options including “Speed Up” and “Cancel.” Click “Speed Up.”

MetaMask will open a new transaction submission window showing the same destination and amount but with a higher gas price already pre-filled. The new fee is calculated based on the current network conditions and is typically between 10 and 20 percent higher than the original, depending on how much time has passed and how congested the network remains. You can accept the suggested fee or adjust it manually using the “Edit” button to access the Gas Price input field.

If you choose to edit, you have three preset options: “Low,” “Standard,” and “Fast.” The “Standard” option is usually safe and balances cost with reasonable confirmation probability. “Low” may still result in a pending transaction if network congestion persists. “Fast” costs more but increases the likelihood of inclusion in the next block or within a few blocks. For high-value transactions or time-sensitive situations, “Fast” is justified; for ordinary token transfers or approvals, “Standard” usually works.

Once you have selected or configured the gas fee, click “Confirm” to approve the speed-up transaction. MetaMask will request your password or biometric confirmation, depending on your security settings. After confirmation, the new transaction broadcasts to the network. The original pending transaction will be replaced—only one will execute, even though two with the same nonce are sent to the network.

Understanding nonce and why wallet state matters for pending transactions

A nonce is a number assigned to each transaction from a given address, incremented by one for every confirmed transaction. The blockchain uses nonce to ensure transactions execute in order and to prevent replay attacks. If you have sent five transactions and all have been confirmed, the next transaction will have nonce 6. If you submit a transaction with nonce 7 before nonce 6 is confirmed, nonce 7 will remain pending until 6 clears.

This is why a single stuck transaction in a batch can block all subsequent ones. If you approve several transactions in rapid succession and the first one stalls with low gas, the entire chain freezes. Speeding up or canceling that first transaction clears the blockage. This is also why MetaMask sometimes shows multiple pending transactions with a status message indicating that one is blocking the others.

The nonce is managed by MetaMask automatically in most cases, but you can view it by expanding the “Advanced” options during transaction submission or by clicking into a pending transaction’s details. If you are working with a metamask wallet extension and have somehow gotten into a state where nonces are out of order—which is rare but possible through direct contract interaction or manual editing—you may need to resolve them by submitting transactions in nonce order or by consulting advanced recovery procedures.

Network-specific gas considerations across MetaMask’s multichain support

MetaMask supports Ethereum, Polygon, Arbitrum, Base, Linea, BNB Chain, and other EVM networks, each with different fee mechanisms and congestion patterns. Ethereum’s base layer typically has the highest absolute fees because it has the most transaction volume and the highest demand. Layer 2 solutions like Arbitrum and Base use rollup technology to batch transactions off-chain, resulting in dramatically lower per-transaction fees. Polygon uses a separate consensus mechanism with different fee dynamics than Ethereum.

Gas estimation varies by network not just in absolute price but in how quickly fees change. Ethereum can see massive fee spikes in minutes during high-demand periods such as NFT drops or protocol upgrades. Layer 2 networks are generally more stable. A transaction that sits for an hour on Arbitrum may clear because base layer fees remain constant; the same transaction on Ethereum might fall further behind as fees rise.

The implication for users is that the right gas strategy is network-dependent. On Ethereum, during congestion, erring toward higher fees reduces the risk of an indefinitely stuck transaction. On Layer 2 networks, you can often afford to submit at the default “Standard” rate because fees are low enough that even a modest bump will get you included. MetaMask’s gas estimation already accounts for these differences, but understanding the pattern helps you make better decisions about when to accept the default and when to manually adjust.

Why custom network configuration affects pending transaction outcomes

One advanced MetaMask feature is the ability to add custom networks or manually configure RPC endpoints. This is powerful for accessing emerging networks or improving reliability, but it also introduces a source of pending transactions that many users do not initially recognize: if your custom RPC endpoint is slow, offline, or out of sync with the actual network state, MetaMask may submit a transaction that the network nodes see as invalid or duplicate.

For example, if your custom endpoint is lagging behind the current block height, MetaMask might calculate gas estimation based on stale data and suggest a fee that was adequate minutes ago but is no longer competitive. Or the endpoint might confirm transaction submission when in fact the transaction failed to propagate to other nodes. The result looks like a pending transaction from your wallet’s perspective, but the wider network may have already discarded it.

The solution is to use reliable, well-maintained RPC providers or the default public endpoints provided by MetaMask. If you must use a custom RPC, verify that it is not lagging, and check its status page for known issues. During troubleshooting of a stuck transaction, switching temporarily to a different RPC and attempting to speed up can sometimes clarify whether the problem is your configuration or genuine network congestion.

Hardware wallets and pending transactions: when MetaMask is not the bottleneck

MetaMask supports hardware wallet devices such as Ledger and Trezor. When you use a hardware wallet with the MetaMask extension, the wallet interface remains the same, but the actual transaction signing happens on the device. This adds security because your private keys never touch the computer, but it also adds a layer to the troubleshooting process.

A pending transaction from a hardware wallet can be stuck for the same reasons—low gas, congestion, network issues—but you cannot speed it up or cancel it without access to the hardware device itself. If your Ledger or Trezor is not connected, MetaMask’s “Speed Up” button will not be available. This is a security feature, not a bug: it prevents software from submitting transactions without your physical device confirming the action.

To speed up a transaction from a hardware wallet, reconnect the device, unlock it, open the browser, and use MetaMask’s speed-up function as normal. The device will prompt you to confirm the higher-fee transaction on its screen. This ensures that you cannot be tricked into speeding up a transaction you did not initiate, but it also means you must have the device available whenever you need to adjust fees.

Preventing future pending transactions through better submission practices

The most effective approach is to avoid creating stuck transactions in the first place. First, always review the gas estimation before confirming a transaction. MetaMask shows the estimated total fee in USD or your local currency; if the number seems unusually high relative to the transaction amount, investigate by expanding the gas settings. For small-value transfers, high absolute fees mean you should wait for network congestion to ease.

Second, use appropriate gas tier presets. “Low” is appropriate only during genuinely quiet periods on the network or for time-insensitive transactions you can afford to wait on for hours or days. “Standard” works for most daily transactions and balances cost with reasonable confirmation speed. “Fast” is justified for time-sensitive actions, high-value transfers, or when you are competing with other users for block space.

Third, be cautious with decentralized applications that request you to approve transactions without showing gas estimates clearly. Some dApps have poor UX and do not display the estimated fee before you click “Approve.” Read the MetaMask confirmation window carefully every time rather than assuming the dApp’s interface has already done the work for you.

Fourth, check network status before submitting high-value or time-sensitive transactions. Websites like Etherscan’s gas tracker or Gasnow show real-time fee averages and historical patterns, giving you visibility into whether fees are spiking. If fees have just spiked and your transaction is not urgent, wait an hour and try again.