What is a mempool?

A mempool (short for “memory pool”) is the queue of pending and unconfirmed transactions for a cryptocurrency network node. There is no one global mempool: every node on the network maintains its own mempool, so different nodes may hold different transactions in their mempools.

What is a mempool explorer?

A mempool explorer is a tool that enables you to view real-time and historical information about a node’s mempool, visualize its transactions, and search and view those transactions.

The mempool.space website invented the concept of visualizing a Bitcoin node’s mempool as projected blocks. These blocks are the inspiration for our half-filled block logo.

Projected blocks are on the left of the dotted white line, and confirmed blocks are on the right.

What is a blockchain? BASICS

A blockchain is a distributed ledger that records the transactions for a cryptocurrency network. Miners amend the blockchain ledger by mining new blocks.

What is a block explorer? BASICS
A block explorer is a tool that enables you to explore real-time and historical information about the blockchain of a cryptocurrency. This includes data related to blocks, transactions, addresses, and more.

What is mining? BASICS
Mining is the process by which unconfirmed transactions in a mempool are confirmed into a block on a blockchain. Miners select unconfirmed transactions from their mempools and arrange them into a block such that they solve a particular math problem.

The first miner on the network to find a suitable block earns all the transaction fees from the transactions in that block. As a result, miners tend to prioritize transactions with higher transaction fees.

What are mining pools? BASICS
Mining pools are groups of miners that combine their computational power in order to increase the probability of finding new blocks.
What are virtual bytes (vB) and weight units (WU)? BASICS
Virtual bytes (vB) and weight units (WU) are used to measure the size of transactions and blocks on the Bitcoin network.

A Bitcoin transaction’s size in the blockchain is not determined how much bitcoin it transfers—instead, a transaction’s size is determined by technical factors such as how many inputs and outputs it has, how many signatures it has, and the format it uses (legacy, SegWit, etc). Since space in the Bitcoin blockchain is limited, bigger transactions pay more in mining fees than smaller transactions.

Block sizes are limited to 4,000,000 WU (or 1,000,000 vB since 1 vB = 4 WU).

Transaction sizes and block sizes used to be measured in plain bytes, but virtual bytes and weight units were devised to maintain backward compatibility after the SegWit upgrade in 2017. See this post for more details.

What is sat/vB? BASICS
The priority of a pending Bitcoin transaction is determined by its feerate. Feerates are measured in sat/vB.

Using a higher sat/vB feerate for a Bitcoin transaction will generally result in quicker confirmation than using a lower feerate. But feerates change all the time, so it’s important to check suggested feerates right before making a transaction to avoid it from getting stuck.

There are feerate estimates on the top of the main dashboard you can use as a guide. See this FAQ for more on picking the right feerate.

Why isn’t my transaction confirming? HELP
If it’s been a while and your transaction hasn’t confirmed, your transaction is probably using a lower feerate relative to other transactions currently in the mempool. Depending on how you made your transaction, there may be ways to accelerate the process.

There’s no need to panic—a Bitcoin transaction will always either confirm completely (or not at all) at some point. As long as you have your transaction’s ID, you can always see where your funds are.

This site only provides data about the Bitcoin network. To get help with a transaction, get in touch with the entity that helped make the transaction (wallet software, exchange company, etc).

How can I get my transaction confirmed more quickly? HELP
To get your transaction confirmed quicker, you will need to increase its effective feerate.

If your transaction was created with RBF enabled, your stuck transaction can simply be replaced with a new one that has a higher fee. Otherwise, if you control any of the stuck transaction’s outputs, you can use CPFP to increase your stuck transaction’s effective feerate.

If you are not sure how to do RBF or CPFP, work with the tool you used to make the transaction (wallet software, exchange company, etc).

Another option to get your transaction confirmed more quickly is Mempool Accelerator™. This service is still in development, but you can sign up for the waitlist to be notified when it’s ready.

How can I prevent a transaction from getting stuck in the future? HELP
You must use an adequate transaction fee commensurate with how quickly you need the transaction to be confirmed. See Mempool’s fee estimates on the front page.

Also consider using RBF (if your wallet supports it) so that you can bump the feerate on your transaction if it does end up getting stuck.

How can I look up a transaction? HOW-TO
Search for the transaction ID in the search box at the top-right of this website.
How can I look up an address? HOW-TO
Search for the address in the search box at the top-right of this website.
How can I look up a block? HOW-TO
Search for the block number (or block hash) in the search box at the top-right of this website.
How can I look up fee estimates? HOW-TO
See real-time fee estimates on the main dashboard.

Here is an overview of Mempool’s feerate suggestions:

High Priority. This figure is the median feerate of transactions in the first mempool block. Consider using this feerate if you want confirmation as soon as possible.
Medium Priority. This figure is the average of the median feerate of the first mempool block and the median feerate of the second mempool block.
Low Priority. This figure is the average of the Medium Priority feerate and the median feerate of the third mempool block. Consider using this feerate if you want confirmation soon but don’t need it particularly quickly.
No Priority. This figure is either 2x the minimum feerate, or the Low Priority feerate (whichever is lower). Consider using this feerate if you are in no rush and don’t mind if confirmation takes a while.
In all cases, the suggested feerate is adjusted lower if any of the mempool blocks involved in the calculation are not full (example: if there is only 1 mempool block that’s less than half-full, Mempool will suggest a feerate of 1 sat/vB—not the median feerate of transactions in the block).

Mempool blocks use feerates, transaction sizes, and other metrics to forecast which transactions will be in future blocks. Actual blocks will turn out to be different: miners have their own views of the mempool, their own algorithms for determining which transactions to include in a block, etc.

Ultimately, the Bitcoin network is not perfectly predictable, so fee estimation cannot be perfectly precise.

Use Mempool’s feerate suggestions as a guide, and understand that they do not guarantee transaction confirmation in any period of time.

How can I explore historical trends? HOW-TO
See the graphs page for aggregate trends over time: mempool size over time and incoming transaction velocity over time.
What does it mean for the mempool to be “full”? ADVANCED
When a Bitcoin transaction is made, it is stored in a Bitcoin node’s mempool before it is confirmed into a block. When the rate of incoming transactions exceeds the rate transactions are confirmed, the mempool grows in size.

By default, Bitcoin Core allocates 300MB of memory for its mempool, so when a node’s mempool grows big enough to use all 300MB of allocated memory, we say it’s “full”.

Once a node’s mempool is using all of its allocated memory, it will start rejecting new transactions below a certain feerate threshold—so when this is the case, be extra sure to set a feerate that (at a minimum) exceeds that threshold. The current threshold feerate (and memory usage) are displayed right on Mempool’s front page.

How big is the mempool used by mempool.space? ADVANCED
mempool.space uses multiple Bitcoin nodes to obtain data: some with the default 300MB mempool memory limit (call these Small Nodes) and others with a much larger mempool memory limit (call these Big Nodes).

Many nodes on the Bitcoin network are configured to run with the default 300MB mempool memory setting. When all 300MB of memory are used up, such nodes will reject transactions below a certain threshold feerate. Running Small Nodes allows mempool.space to tell you what this threshold feerate is—this is the “Purging” feerate that shows on the front page when mempools are full, which you can use to be reasonably sure that your transaction will be widely propagated.

Big Node mempools are so big that they don’t need to reject (or purge) transactions. Such nodes allow for mempool.space to provide you with information on any pending transaction it has received—no matter how congested the mempool is, and no matter how low-feerate or low-priority the transaction is.

What is memory usage? ADVANCED
Memory usage on the front page refers to the real-time amount of system memory used by a Bitcoin node’s mempool. This memory usage number is always higher than the total size of all pending transactions in the mempool due to indexes, pointers, and other overhead used by Bitcoin Core for storage and processing.

mempool.space shows the memory usage of a Bitcoin node that has a very high mempool memory limit. As a result, when mempools fill up, you may notice memory usage on mempool.space go beyond 300MB. This is not a mistake—this memory usage figure is high because it’s for a Bitcoin node that isn’t rejecting (or evicting) transactions. Consider it to be another data point to give you an idea of how congested the mempool is relative to the default memory limit of 300MB.

A Bitcoin node running the default 300MB mempool memory limit, like most Raspberry Pi nodes, will never go past 300MB of memory usage.

Why are there empty blocks? ADVANCED
When a new block is found, mining pools often send miners new block templates prior to fully validating the new block, often before they’ve even received the new block. During this time, it is not possible to select transactions for the next block as a pool isn’t sure which transactions conflict with transactions already mined.

While empty blocks do not add additional transactions to the blockchain, they do contribute to the overall security of transactions already in the chain.

Why don’t block timestamps always increase? ADVANCED
Block validation rules do not strictly require that a block’s timestamp be more recent than the timestamp of the block preceding it. Without a central authority, it’s impossible to know what the exact correct time is. Instead, the Bitcoin protocol requires that a block’s timestamp meet certain requirements. One of those requirements is that a block’s timestamp cannot be older than the median timestamp of the 12 blocks that came before it. See more details here.

As a result, timestamps are only accurate to within an hour or so, which sometimes results in blocks with timestamps that appear out of order.

Why doesn’t the fee range shown for a block match the feerates of transactions within the block? ADVANCED
Mempool aims to show you the effective feerate range for blocks—how much would you actually need to pay to get a transaction included in a block.

A transaction’s effective feerate is not always the same as the feerate explicitly set for it. For example, if you see a 1 s/vb transaction in a block with a displayed feerate range of 5 s/vb to 72 s/vb, chances are that 1 s/vb transaction had a high-feerate child transaction that boosted its effective feerate to 5 s/vb or higher (this is how CPFP fee-bumping works). In such a case, it would be misleading to use 1 s/vb as the lower bound of the block’s feerate range since it actually required more than 1 s/vb to confirm that transaction in that block.

You can find a transaction’s feerate on its transaction details page. If the transaction has any CPFP relationships, the page will also show the transaction’s effective feerate along with links to descendent and/or ancestor transactions.

How do block audits work? ADVANCED
A block audit visually compares Mempool’s expected block to the actual block for a particular block height.

How is the expected block determined? Mempool monitors its view of the mempool and runs a re-implementation of Bitcoin Core’s transaction selection algorithm to determine the transactions it expects to see in upcoming blocks (source code here). Since there is a continual flow of new transactions, this algorithm runs every 2 seconds, and as a result, you will see the transactions projected to be in upcoming blocks change in near real-time.

At the moment a new block is mined, Mempool saves a snapshot of its projected block template for the next block. We call this snapshot the expected block for the block height in question, and it serves as the basis for the block audit.

When details for an expected block and actual block are available, we can compare them. The purpose of block audits is to deduce when miners intentionally include or exclude transactions from blocks they mine. Since this information cannot be precisely known, Mempool uses a handful of heuristics to accomplish this.

Block audits highlight transactions in different colors to convey these heuristics:

■ADDED
A transaction is highlighted blue if it is not present in the expected block, present in the actual block, and also either:

far out of the expected feerate range, meaning the miner may have intentionally prioritized the transaction
not in the mempool at all, meaning the miner may have accepted the transaction out-of-band
Added transactions do not negatively affect block health.

■RECENTLY BROADCASTED
A transaction is highlighted dark pink if it is present in the expected block, not present in the actual block, and was first seen by Mempool’s Bitcoin node within 3 minutes of the block being mined.

Due to network latency and other factors, it can take time for a miner’s Bitcoin nodes to receive a transaction, so we do not assume a miner has intentionally excluded such a transaction from a block.

Recently-broadcasted transactions do not negatively affect block health.

■MARGINAL FEE
A transaction is darkened if it is in the low end of the expected feerate range and missing in either the expected block or the actual block.

Such a transaction may have been displaced by an added transaction, or it may have been displaced by another transaction from the mempool that was also at the low end of the expected feerate range for the block. In either case, the deviation is not considered notable.

Marginal fee transactions do not negatively affect block health.

■REMOVED
A transaction is highlighted bright pink if it is present in the expected block, not present in the actual block, and qualifies as neither recently-broadcasted nor marginal-fee. In other words, it has been in the mempool long enough to be widely propagated and has a feerate that is well within the range expected for the block. There is a chance such a transaction may have been intentionally excluded from the block.

Removed transactions do negatively affect block health.

See how results of the block audit are used to devise the block health score below.

Because of this feature’s resource usage and availability requirements, it is only supported on official mempool.space instances.

What is block health? ADVANCED
Block health is a measure of how many transactions appear to be intentionally excluded from a block—a block without any transactions that appear intentionally excluded will have 100% health, while a block with 1 or more transactions that appear intentionally excluded will have sub-100% health.

How is it calculated? Let sexpected be the set of all transactions in Mempool’s expected block and let sactual be the set of all transactions in the actual block. Then let n be the number of all transactions in both sexpected and sactual.

Furthermore, let r be the number of transactions Mempool deduces were intentionally excluded from sactual.

Block health is calculated as n / ( n + r ).

The number of transactions appearing in both sexpected and sactual is used (instead of a block’s full transaction count) in order to minimize chances that block health is inadvertently impacted by transactions that were most likely not intentionally excluded:

recently-broadcast transactions, since the miner may simply not have received them
certain low-feerate transactions, since the miner may have opted to replace them with more profitable out-of-band transactions
As a result, block health is not intended to be a measure of how closely an expected block resembles an actual block. The actual block can be vastly different from the expected block, but if no transactions appear to be intentionally excluded, it will have a high health rating (extreme example).

See more context in our FAQ on block audits.

Because of this feature’s resource usage and availability requirements, it is only supported on official mempool.space instances.

How do Mempool Goggles™ work? ADVANCED
Mempool Goggles™ are a set of filters that can be applied to the mempool block visualizations to highlight different types of transactions.

There are currently 25 different Mempool Goggles™ filters, grouped into six categories:

Features
RBF ENABLEDThe transaction opts-in to BIP-125 replaceability.RBF DISABLEDThe transaction does not opt-in to BIP-125 replaceability.VERSION 1The default version for most transactions.VERSION 2Required for transactions which use OP_CHECKSEQUENCEVERIFY relative timelocks.
Address Types
P2PKPay-to-public-key. A legacy output format most commonly found in old coinbase transactions.BARE MULTISIGA legacy form of multisig, most commonly used for data embedding schemes (see also “Fake pubkey”).P2PKHPay-to-public-key-hash. A legacy address type that locks outputs to a public key.P2SHPay-to-script-hash. A legacy address type that locks outputs to a redeem script.P2WPKHPay-to-witness-public-key-hash. The SegWit version of P2PKH.P2WSHPay-to-witness-script-hash. The SegWit version of P2SH.TAPROOTAddresses using the SegWit V1 format added in the Taproot upgrade.
Behavior
PAID FOR BY CHILDThe transaction’s effective fee rate has been increased by a higher rate CPFP child.PAYS FOR PARENTThe transaction bumps the effective fee rate of a lower rate CPFP ancestor.REPLACEMENTThe transaction replaced a prior version via RBF.
Data
Different methods of embedding arbitrary data in a Bitcoin transaction.
OP_RETURNFAKE PUBKEYData may be embedded in an invalid public key in a P2PK or Bare multisig output. This is a heuristic filter and can be prone to false positives and false negatives.INSCRIPTIONData is embedded in the witness script of a taproot input.
Heuristics
These filters match common types of transactions according to subjective criteria.
COINJOINA type of collaborative privacy-improving transaction.CONSOLIDATIONThe transaction condenses many inputs into a few outputs.BATCH PAYMENTThe transaction sends coins from a few inputs to many outputs.
Sighash Flags
Different ways of signing inputs to Bitcoin transactions. Note that selecting multiple sighash filters will highlight transactions in which each sighash flag is used, but not necessarily in the same input.
SIGHASH_ALLSIGHASH_NONESIGHASH_SINGLESIGHASH_DEFAULTSIGHASH_ANYONECANPAY
What are sigops? ADVANCED
A “sigop” is a way of accounting for the cost of “signature operations” in Bitcoin script, like OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY

These signature operations incur different costs depending on whether they are single or multi-sig operations, and on where they appear in a Bitcoin transaction.

By consensus, each Bitcoin block is permitted to include a maximum of 80,000 sigops.

What is adjusted vsize? ADVANCED
Bitcoin blocks have two independent consensus-enforced resource constraints – a 4MWU weight limit, and the 80,000 sigop limit.

Most transactions use more of the weight limit than the sigop limit. However, some transactions use a disproportionate number of sigops compared to their weight.

To account for this, Bitcoin Core calculates and uses an “adjusted vsize” equal 5 times the number of sigops, or the unadjusted vsize, whichever is larger.

Then, during block template construction, Bitcoin Core selects transactions in descending order of fee rate measured in satoshis per adjusted vsize

On mempool.space, effective fee rates for unconfirmed transactions are also measured in terms of satoshis per adjusted vsize, after accounting for CPFP relationships and other dependencies.

Why do the projected block fee ranges overlap? ADVANCED
The projected mempool blocks represent what we expect the next blocks would look like if they were mined right now, and so each projected block follows all of the same rules and constraints as real mined blocks.

Those constraints can sometimes cause transactions with lower fee rates to be included “ahead” of transactions with higher rates.

For example, if one projected block has a very small amount of space left, it might be able to fit one more tiny low fee rate transaction, while larger higher fee rate transactions have to wait for the following block.

A similar effect can occur when there are a large number of transactions with very many sigops. In that scenario, each projected block can only include up to 80,000 sigops worth of transactions, after which the remaining space can only be filled by potentially much lower fee transactions with zero sigops.

In extreme cases this can produce several projected blocks in a row with overlapping fee ranges, as a result of each projected block containing both high-feerate high-sigop transactions and lower feerate zero-sigop transactions.

Who runs this website? SELF-HOSTING
The official mempool.space website is operated by The Mempool Open Source Project. See more information on our About page. There are also many unofficial instances of this website operated by individual members of the Bitcoin community.
How can I host my own instance on a Raspberry Pi? SELF-HOSTING
We support one-click installation on a number of Raspberry Pi full-node distros including Umbrel, RaspiBlitz, MyNode, RoninDojo, and StartOS.
How can I host a Mempool instance on my own server? SELF-HOSTING
You can manually install Mempool on your own server, but this requires advanced sysadmin skills since you will be manually configuring everything. You could also use our Docker images.

In any case, we only provide support for manual deployments to enterprise sponsors.

For casual users, we strongly suggest installing Mempool using one of the 1-click install methods.

Can I install Mempool using Docker? SELF-HOSTING
Yes, we publish Docker images (or you can build your own). Check out the documentation for details.
Why do I get an error for certain address lookups on my Mempool instance? SELF-HOSTING
If you’re getting errors when doing address lookups, it’s probably because of your Electrum server backend.

Mempool uses an Electrum server to do address lookups. There are several implementations of the Electrum server protocol, and Mempool can use any of them, but the implementation you use affects performance:

romanz/electrs. This is a common choice for its low resource requirements, and most full-node distros use it. But while this implementation works great for basic queries, it will struggle with heavier ones (e.g. looking up addresses with many transactions)—especially when running on low-power hardware like a Raspberry Pi.
Fulcrum. Fulcrum requires more resources than romanz/electrs but it can still run on a Raspberry Pi, and it handles heavy queries much more efficiently. If you’re having issues with romanz/electrs, Fulcrum is worth a try.
mempool/electrs. If you have stronger hardware, you could consider running mempool/electrs, the backend that powers mempool.space. It’s a fork of Blockstream’s Esplora, which is in turn a fork of romanz/electrs, intended for maximum performance and larger-scale deployments.