Overview

When you submit a blockchain transaction, it doesn't get confirmed immediately. Instead, it first enters a waiting area called the mempool (memory pool), where it waits to be picked up by miners or validators and included in a block. In Fireblocks, transactions in this state display a status of "Confirming."

This article explains what the mempool is, why transactions can get stuck, and how to resolve them.

What is the mempool?

The mempool is a temporary staging area maintained by each blockchain node where unconfirmed transactions wait to be processed. When you broadcast a transaction:

The transaction is sent to one or more blockchain nodes
Nodes validate the transaction and add it to their local mempool
The transaction is propagated across the network to other nodes
Miners/validators select transactions from the mempool to include in the next block
Once included in a block, miners/validators confirm the transaction and remove it from the mempool

There is no single, universal mempool. Each node maintains its own mempool, and they communicate with each other to share pending transactions. This means a transaction may exist in some nodes' mempools but not others.

What about blockchains that don't use a mempool?

Let's use Solana as an example. Solana doesn't use a traditional mempool. Its architecture (based on Proof of History and a leader-based block production model) processes transactions much more immediately. Validators receive transactions and process them in rapid sequence, so there's no persistent holding queue in the same sense. Transactions that can't be processed quickly are simply dropped rather than queued.

Without a mempool, the network is more of a "process it now or discard it" model. Mempools enable fee markets and ordering flexibility, but add latency. Mempool-less designs can achieve higher throughput and lower latency, but at the cost of reliability. If the network is busy, your transaction may need to be resubmitted rather than simply waiting its turn.

This distinction matters quite a bit for how Fireblocks transaction statuses and substatuses behave. For example, Bitcoin transactions can linger in a "pending" state for a long time, while Solana failures tend to be faster but more abrupt.

What does the "Confirming" status mean in Fireblocks?

When a transaction shows the "Confirming" status in Fireblocks, it means:

The transaction has been successfully signed and broadcast to the blockchain network
The transaction is waiting to reach the required number of confirmations defined in your confirmation policy

The transaction status changes to "Completed" once the number of blockchain confirmations meets your configured Deposit Control & Confirmation Policy threshold.

A transaction in the "Confirming" status may have 0 confirmations (still in the mempool) or may already have some confirmations but not yet enough to meet your policy threshold. You can check the current confirmation count via the Console or API. For more details, see Primary transaction statuses.

Why can't I find my transaction on a block explorer?

It's common for a transaction in the "Confirming" status not to appear on block explorers such as Etherscan or Mempool. This is expected behavior because:

Block explorers connect to specific nodes, and your transaction may not have propagated to those particular nodes yet
Each node has its own mempool, so a transaction in one node's mempool might not be in another's
Low-fee transactions may be deprioritized and not widely propagated across the network

If your transaction doesn't appear on an explorer but shows "Confirming" in Fireblocks, it simply means the explorer's nodes haven't received the transaction yet. This does not mean the transaction failed or was lost.

Why do transactions get stuck?

The most common reason for a stuck transaction is insufficient transaction fees:

Miners and validators prioritize transactions with higher fees
During network congestion, competition for block space increases
Transactions with lower fees get pushed to the back of the queue

Other contributing factors:

Network congestion: High transaction volume means more competition for limited block space
Nonce gaps (EVM networks): Transactions must be processed sequentially by nonce. If an earlier transaction is stuck, all subsequent transactions from that address will also be stuck
Mempool expiry (Bitcoin): Transactions that remain unconfirmed for too long may be dropped from the mempool (default is 14 days). After being dropped, the UTXOs are freed up and can be used again
No expiry (EVM networks): On Ethereum and other EVM-compatible networks, transactions do not expire. A stuck transaction will remain pending indefinitely until it is either confirmed or replaced

How to resolve stuck transactions

Since the transaction has already been broadcast to the blockchain, you cannot simply cancel it from Fireblocks. The only ways to accelerate or drop a stuck transaction are through blockchain-native mechanisms.

For EVM Networks (Ethereum, Polygon, etc.): Replace-By-Fee (RBF)

RBF allows you to replace a stuck transaction with a new one that has a higher gas fee:

The new transaction must use the same nonce as the original stuck transaction
The new transaction must have a higher gas price than the original
Once the replacement transaction is confirmed, the original transaction becomes invalid and gets dropped by the blockchain since the nonce was already used

When you perform an RBF transaction through Fireblocks (Boost or Drop), Fireblocks automatically handles the status updates and tracking of both the original and replacement transactions.

Use cases

Boost: Resubmit the same transaction with higher fees to speed up confirmation.
Drop: Send a 0-value transaction to your own address with the same nonce and higher fees, effectively canceling the original transaction.

You can perform both of these operations via the Fireblocks API or the Console.

For Bitcoin (and Other UTXO-Based Networks): Child-Pays-For-Parent (CPFP)

CPFP works by creating a new "child" transaction that spends the output of the stuck "parent" transaction:

The child transaction uses the unconfirmed output from the parent transaction
The child transaction includes a fee high enough to make mining both transactions profitable
Miners must confirm the parent transaction first before they can claim the child transaction's fees, incentivizing them to process both together

Bitcoin also supports RBF if the original transaction was flagged as replaceable (opt-in RBF).

For instructions on CPFP transactions, see CPFP (Child Pays For Parent).