MetaMask Transaction Lifecycle: Diagnose Pending, Failed, and Stuck Transactions

What a MetaMask transaction actually is

MetaMask is a self-custodial wallet: it holds your keys locally, constructs a transaction, asks you to sign it, and broadcasts the signed payload to an RPC endpoint. The wallet does not mine, order, or confirm transactions. Everything after broadcast depends on the network's mempool rules, the gas price you committed to, and the RPC provider that accepted the payload.

That separation matters for troubleshooting. A transaction that looks stuck in MetaMask may already be included on-chain, may be sitting in a mempool, may have been rejected by the RPC endpoint before ever reaching the network, or may never have been signed at all. Each case has a different fix, and the wallet UI alone cannot always tell you which one you are in.

This article covers the full lifecycle for EVM networks and gives you a diagnostic procedure that uses the transaction hash, the account nonce, and an independent RPC query as evidence. It does not recommend a specific wallet configuration or provider; for endpoint selection, the RPC Assistant covers concrete network choices.

• Wallet side: key custody, transaction construction, signing, local activity history.
• Network side: mempool admission, gas market, block inclusion, confirmation depth.
• RPC side: broadcast acceptance, state queries, and whether the endpoint is synced and healthy.

Assumptions and prerequisites

The procedure assumes you have the transaction hash (also called the transaction ID) from MetaMask's Activity tab, the account address that sent it, and access to at least one RPC endpoint for the same network. You should also know which network the transaction targeted, because a transaction broadcast on one chain cannot be found on another even if the address is identical.

You do not need the private key to diagnose a transaction. Reading state, checking nonces, and querying receipts are all public operations. Only replacement or cancellation requires signing a new transaction, and that should be done from the wallet that holds the key.

If you are running your own infrastructure, a dedicated node gives you a stable view of mempool and state that does not depend on a shared public endpoint. For most readers, a reliable hosted endpoint is sufficient for diagnosis.

The transaction lifecycle stage by stage

Stage one is construction. MetaMask assembles the transaction fields: from, to, value, data, gas limit, max fee, priority fee, and nonce. The nonce is the account's transaction counter, and it is the single most useful field for diagnosing ordering problems. Every transaction from an account must be included in nonce order, so a gap at nonce N blocks every later transaction from that account on that network.

Stage two is signing. The wallet signs the payload locally with your key. If you reject the confirmation prompt, nothing is broadcast and no nonce is consumed. A signature request that you approve but that never appears in Activity usually indicates a UI or session problem rather than a network problem.

Stage three is broadcast. The signed payload goes to an RPC endpoint, which may accept it into its mempool, reject it for insufficient funds or a nonce conflict, or accept it but fail to propagate it. A transaction hash can exist locally in MetaMask even when no node has accepted the payload.

Stage four is inclusion. A block producer selects the transaction, executes it, and includes it in a block. Execution can succeed or revert; a revert still consumes gas and still counts as included. Stage five is confirmation, where additional blocks bury the transaction and reduce reorg risk. MetaMask's status labels map loosely onto these stages, which is why the explorer is the authoritative source.

Reading nonce and gas as diagnostic evidence

Two numbers explain most stuck transactions. The first is the pending nonce versus the latest nonce. The latest nonce counts transactions already included in a block; the pending nonce counts transactions the node believes are queued or included. If your stuck transaction has nonce N and the latest nonce is below N, the transaction has not been included. If the latest nonce is above N, it was included and you are looking at a stale wallet view.

The second number is the effective gas price relative to the network's current base fee. On EIP-1559 networks, a transaction is only eligible for inclusion when its max fee covers the base fee plus its priority fee. If the base fee rose after you signed, a transaction that was reasonable at signing time can become ineligible and sit in the mempool until the base fee falls or you replace it.

A useful rule: before replacing anything, confirm the transaction is genuinely not included. Query the receipt by hash. A null receipt with a pending nonce at or above your transaction's nonce means it is still in flight; a non-null receipt means it is done, regardless of what the wallet shows.

Diagnostic procedure with curl

The following commands query an RPC endpoint directly. Replace RPC_URL with your endpoint and TX_HASH and ADDRESS with your values. These are standard JSON-RPC methods supported by EVM nodes; the exact behavior of pending queries depends on the node's mempool visibility.

First, check whether the transaction has been mined by requesting its receipt. A result of null means no receipt exists yet. Second, compare the latest and pending nonce for the sender. Third, read the current base fee from the latest block to judge whether your fee is still competitive.

curl -s RPC_URL -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["TX_HASH"]}'

curl -s RPC_URL -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":2,"method":"eth_getTransactionCount","params":["ADDRESS","latest"]}'

curl -s RPC_URL -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":3,"method":"eth_getTransactionCount","params":["ADDRESS","pending"]}'

curl -s RPC_URL -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":4,"method":"eth_getBlockByNumber","params":["latest",false]}'

Interpreting the results table

Record each query result in a small table before drawing conclusions. The table below is a template; fill it with your own observed values rather than assuming typical numbers. Do not treat any single row as conclusive on its own.

If the receipt is null and the pending nonce is at or above your transaction's nonce, the transaction is in flight. If the receipt is null and the pending nonce is below your transaction's nonce, there is a nonce gap and later transactions cannot proceed. If the receipt exists with status 0x0, the transaction was included but reverted, which is an execution problem, not a network problem.

Runnable check with JavaScript

For repeated diagnosis, a short script is more reliable than manual queries. The example below uses a JSON-RPC fetch call and prints the receipt state, both nonces, and the current base fee. It uses placeholders for the endpoint and values, and it does not require a private key.

Run it against two different endpoints if you suspect one provider is lagging. Divergent answers between providers usually indicate a sync or mempool visibility difference rather than a chain-level problem.

const RPC_URL = 'RPC_URL';
const TX_HASH = 'TX_HASH';
const ADDRESS = 'ADDRESS';

async function rpc(method, params) {
  const res = await fetch(RPC_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method, params })
  });
  const json = await res.json();
  if (json.error) throw new Error(json.error.message);
  return json.result;
}

(async () => {
  const receipt = await rpc('eth_getTransactionReceipt', [TX_HASH]);
  const latest = await rpc('eth_getTransactionCount', [ADDRESS, 'latest']);
  const pending = await rpc('eth_getTransactionCount', [ADDRESS, 'pending']);
  const block = await rpc('eth_getBlockByNumber', ['latest', false]);
  console.log({ receipt: receipt ? receipt.status : null, latest, pending, baseFee: block.baseFeePerGas });
})();

Troubleshooting by symptom

Pending for a long time with a null receipt and a pending nonce at your transaction's nonce: the transaction is in a mempool but not being selected. Check whether your max fee covers the current base fee plus priority fee. If it does not, the fix is a replacement transaction with the same nonce and a higher fee, signed from the same wallet.

Pending with a nonce gap: an earlier transaction from the account was dropped or never broadcast. Later transactions cannot be included until the gap is filled. Submit a transaction at the missing nonce, or replace the missing transaction, before expecting the later ones to confirm.

Failed with status 0x0: the transaction was included and reverted. Read the revert reason from the explorer or by replaying the call against the block before inclusion. Common causes are slippage on swaps, insufficient token approval, or a contract-level require that failed. Increasing gas does not fix a revert.

Insufficient funds or a greyed-out confirm button: the account cannot cover value plus gas at the selected fee. This is a balance problem, not a network problem. Reduce the amount or the fee, or add funds to the account.

Transaction visible in MetaMask but absent from the explorer: the payload may never have reached a node. Re-broadcast the raw signed transaction to a healthy endpoint, or reset the wallet's activity view and confirm against the explorer.

Replacement, cancellation, and their tradeoffs

Replacement works by submitting a new transaction with the same nonce and a higher fee. Most networks require a minimum bump, often around ten percent above the original fee, though the exact rule is network-specific. A cancellation is a replacement that sends zero value to your own address, consuming the nonce so the original can never be included.

The tradeoff is that replacement is a race. If the original is included before the replacement propagates, the replacement is rejected as a nonce conflict and the original stands. Always confirm the original receipt is null immediately before broadcasting a replacement, and keep both hashes so you can identify which one wins.

Replacement also costs gas. A cancellation that succeeds still pays the fee for the zero-value transaction. If the original was going to confirm anyway, you have paid twice. For high-value or time-sensitive transactions, this cost is usually acceptable; for low-value transactions, waiting for the base fee to fall is often cheaper.

Limitations of wallet-side diagnosis

MetaMask's Activity tab is a local record, not a chain index. It can show a transaction as pending after it has confirmed, or omit a transaction that was broadcast outside the wallet. Treat the explorer and direct RPC queries as authoritative and the wallet as a convenience layer.

Pending nonce and mempool visibility also vary by endpoint. A node with a small mempool or aggressive pruning may report a pending nonce that differs from what block producers see. When a diagnosis is ambiguous, query a second independent endpoint before acting.

Finally, this procedure covers EVM transaction mechanics. Networks with different fee markets, account models, or confirmation rules need their own diagnostic steps. The general principle still holds: separate wallet state, broadcast state, and inclusion state, and verify each with an independent source.

Next steps for reliable transaction operations

Once you can read nonce, fee, and receipt state directly, the next improvement is infrastructure reliability. A stable endpoint reduces the chance that a broadcast is silently dropped and gives you consistent pending-nonce visibility. Review the network guides for chain-specific behavior, and compare endpoint options before committing to a provider.

For teams running frequent or automated transactions, a dedicated node removes shared-endpoint variability and gives you control over mempool policy. For individual users, a reputable hosted endpoint plus the diagnostic procedure above is usually enough.

Keep a habit of verifying every important transaction on the explorer by hash, not by wallet label. That single practice resolves most confusion around pending, failed, and stuck MetaMask transactions.

• Review chain-specific behavior in the network guides.
• Compare endpoint options for your network before scaling transaction volume.
• Consider a dedicated node if you need consistent mempool and nonce visibility.