| |
mempool.space merely provides data about the Bitcoin network. It cannot help you with retrieving funds, wallet issues, etc.
For any such requests, you need to get in touch with the entity that helped make the transaction (wallet software, exchange company, etc).
Get higher API limits with Mempool Enterprise®
Below is a reference for the {{ network.val === '' ? 'Bitcoin' : network.val.charAt(0).toUpperCase() + network.val.slice(1) }}
Note that we enforce rate limits. If you exceed these limits, you will get an HTTP 429 error. If you repeatedly exceed the limits, you may be banned from accessing the service altogether. Consider an enterprise sponsorship if you need higher API limits.
{{ item.httpRequestMethod }} {{ baseNetworkUrl }}/api{{ item.urlString }}
{{ item.httpRequestMethod }} {{ baseNetworkUrl }}/api{{ item.urlString }}
{{ '{' }} action: 'want', data: ['blocks', ...] {{ '}' }} to express what you want pushed. Available: blocks, mempool-blocks, live-2h-chart, and stats.{{ '{' }} 'track-address': '3PbJ...bF9B' {{ '}' }} to receive all new transactions containing that address as input or output. Returns an array of transactions. address-transactions for new mempool transactions, and block-transactions for new block confirmed transactions.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.
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.
A blockchain is a distributed ledger that records the transactions for a cryptocurrency network. Miners amend the blockchain ledger by mining new blocks.
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.
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.
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.
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.
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).
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.
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.
See real-time fee estimates on the main dashboard.
Here is an overview of Mempool's feerate suggestions:
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.
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.
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.
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.
When a new block is found, mining pools send miners a block template with no transactions so they can begin doing useful work as soon as possible. The pool will then send a block template full of transactions right afterward, and the miners will usually have it in under a second.
Miners sometimes get lucky and find the empty block in the interim period before having the full template however this is rarely the reason for an empty block as it's such a small amount of time.
The usual cause is that some mining hardware will continue to work on old work for up to 60 seconds despite having newer work. This is also why when comparing "Actual Blocks" with "Expected Blocks" on mempool.space you will often observe slightly lower fees in the blocks found than what's theoretically possible.
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.
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.
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:
AddedA transaction is highlighted blue if it is not present in the expected block, present in the actual block, and also either:
Added transactions do not negatively affect block health.
Recently broadcastedA 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.
RemovedA 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.
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:
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.
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:
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.
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.
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.
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.
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: