<table*ngIf="!mobileViewport"><tr><td><app-svg-imagesname="warning"class="disclaimer-warning"viewBox="0 0 304 304"fill="#ffc107"width="50"height="50"></app-svg-images></td><td><pi18n="faq.big-disclaimer"><b>mempool.space merely provides data about the Bitcoin network.</b> It cannot help you with retrieving funds, wallet issues, etc.</p><p>For any such requests, you need to get in touch with the entity that helped make the transaction (wallet software, exchange company, etc).</p></td></tr></table>
<div*ngIf="mobileViewport"><app-svg-imagesname="warning"class="disclaimer-warning"viewBox="0 0 304 304"fill="#ffc107"width="50"height="50"></app-svg-images><pi18n="faq.big-disclaimer"><b>mempool.space merely provides data about the Bitcoin network.</b> It cannot help you with retrieving funds, wallet issues, etc.</p><p>For any such requests, you need to get in touch with the entity that helped make the transaction (wallet software, exchange company, etc).</p></div>
<pclass="doc-welcome-note">Below is a reference for the {{ network.val === '' ? 'Bitcoin' : network.val.charAt(0).toUpperCase() + network.val.slice(1) }} <ng-containeri18n="api-docs.title">REST API service</ng-container>.</p>
<pclass="doc-welcome-note api-note"*ngIf="officialMempoolInstance">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 <ahref="/enterprise">enterprise sponsorship</a> if you need higher API limits.</p>
<divi18n="api-docs.websocket.websocket">Default push: <code>{{ '{' }} action: 'want', data: ['blocks', ...] {{ '}' }}</code> to express what you want pushed. Available: <code>blocks</code>, <code>mempool-blocks</code>, <code>live-2h-chart</code>, and <code>stats</code>.<br><br>Push transactions related to address: <code>{{ '{' }} 'track-address': '3PbJ...bF9B' {{ '}' }}</code> to receive all new transactions containing that address as input or output. Returns an array of transactions. <code>address-transactions</code> for new mempool transactions, and <code>block-transactions</code> for new block confirmed transactions.</div>
<pclass="note"*ngIf="network.val !== 'signet'">Electrum RPC interface for Bitcoin Signet is <ahref="/signet/docs/api/electrs">publicly available</a>. Electrum RPC interface for all other networks is available to <ahref='/enterprise'>sponsors</a> only—whitelisting is required.</p>
<p>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.</p>
<p>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.</p><p>The mempool.space website invented the concept of visualizing a Bitcoin node's mempool as <b>projected blocks</b>. These blocks are the inspiration for our half-filled block logo.</p><p>Projected blocks are on the left of the dotted white line, and confirmed blocks are on the right.</p>
<divclass="blockchain-wrapper">
<app-blockchain></app-blockchain>
</div>
</ng-template>
<ng-templatetype="what-is-a-blockchain">
<p>A blockchain is a distributed ledger that records the transactions for a cryptocurrency network. Miners amend the blockchain ledger by mining new blocks.</p>
</ng-template>
<ng-templatetype="what-is-a-block-explorer">
<p>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.</p>
<p>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.<p>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.</p>
<p>A Bitcoin transaction's size in the blockchain is <i>not</i> 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.</p>
<p>Block sizes are limited to 4,000,000 WU (or 1,000,000 vB since 1 vB = 4 WU).</p>
<p>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 <ahref="https://programmingbitcoin.com/understanding-segwit-block-size"target="_blank">this post</a> for more details.</p>
<p>The priority of a pending Bitcoin transaction is determined by its feerate. Feerates are measured in sat/vB.</p>
<p>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 <a[routerLink]="['/docs/faq'|relativeUrl]"fragment="why-is-transaction-stuck-in-mempool">avoid it from getting stuck</a>.</p>
<p>There are feerate estimates on the top of <a[routerLink]="['/'|relativeUrl]">the main dashboard</a> you can use as a guide. See <a[routerLink]="['/docs/faq'|relativeUrl]"fragment="looking-up-fee-estimates">this FAQ</a> for more on picking the right feerate.</p>
<p>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 <a[routerLink]="['/docs/faq'|relativeUrl]"fragment="how-to-get-transaction-confirmed-quickly">ways to accelerate the process</a>.</p><p>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.</p><pstyle='font-weight:700'>This site only provides data about the Bitcoin network—it cannot help you get your transaction confirmed quicker.</p>
<p>To get your transaction confirmed quicker, you will need to increase its effective feerate.</p><p>If your transaction was created with RBF enabled, your stuck transaction can simply be replaced with a new one that has a higher fee.</p><p>Otherwise, if you control any of the stuck transaction's outputs, you can use CPFP to increase your stuck transaction's effective feerate.</p><p>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). This website only provides data about the Bitcoin network, so there is nothing it can do to help you get your transaction confirmed quicker.</p>
</ng-template>
<ng-templatetype="how-prevent-stuck-transaction">
<p>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 <a[routerLink]="['/'|relativeUrl]">front page</a>.</p><p>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.</p>
</ng-template>
<ng-templatetype="looking-up-transactions">
Search for the transaction ID in the search box at the top-right of this website.
</ng-template>
<ng-templatetype="looking-up-addresses">
Search for the address in the search box at the top-right of this website.
</ng-template>
<ng-templatetype="looking-up-blocks">
Search for the block number (or block hash) in the search box at the top-right of this website.
</ng-template>
<ng-templatetype="looking-up-fee-estimates">
<p>See real-time fee estimates on <a[routerLink]="['/'|relativeUrl]">the main dashboard</a>.</p><p>Here is an overview of Mempool's feerate suggestions:</p><ul><li><b>High Priority.</b> This figure is the median feerate of transactions in the <a[routerLink]="['/mempool-block/0'|relativeUrl]">first mempool block</a>. Consider using this feerate if you want confirmation as soon as possible.</li><li><b>Medium Priority.</b> This figure is the average of the median feerate of the <a[routerLink]="['/mempool-block/0'|relativeUrl]">first mempool block</a> and the median feerate of the <a[routerLink]="['/mempool-block/1'|relativeUrl]">second mempool block</a>.</li><li><b>Low Priority.</b> This figure is the average of the Medium Priority feerate and the median feerate of the <a[routerLink]="['/mempool-block/2'|relativeUrl]">third mempool block</a>. Consider using this feerate if you want confirmation soon but don't need it particularly quickly.</li><li><b>No Priority.</b> 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.</li></ul><p>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).</p><p>Mempool blocks use feerates, transaction sizes, and other metrics to <b>forecast</b> 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.</p><p>Ultimately, the Bitcoin network is not perfectly predictable, so fee estimation cannot be perfectly precise.</p><p><b>Use Mempool's feerate suggestions as a guide, and understand that they do not guarantee transaction confirmation in any period of time.</b></p>
</ng-template>
<ng-templatetype="looking-up-historical-trends">
See the <a[routerLink]="['/graphs'|relativeUrl]">graphs page</a> for aggregate trends over time: mempool size over time and incoming transaction velocity over time.
<p>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.</p><p>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".</p><p>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.</p>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>When a new block is found, mining pools send miners a block template with no transactions so they can start searching for the next block as soon as possible. They send a block template full of transactions right afterward, but a full block template is a bigger data transfer and takes slightly longer to reach miners.</p><p>In this intervening time, which is usually no more than 1-2 seconds, miners sometimes get lucky and find a new block using the empty block template.</p>
<p>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 <ahref="https://en.bitcoin.it/wiki/Block_timestamp"target="_blank">here</a>.</p><p>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.</p>
<p>Mempool aims to show you the <i>effective feerate</i> range for blocks—how much would you actually need to pay to get a transaction included in a block.</p>
<p>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.</p>
<p>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.</p>
<p>A block audit visually compares Mempool's expected block to the actual block for a particular block height.</p>
<p>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 (<ahref="https://github.com/mempool/mempool/blob/master/backend/src/api/mempool-blocks.ts"target="_blank">source code here</a>). Since there is a continual flow of new transactions, this algorithm runs every 2 seconds, and as a result, you will see the transactions <ahref="/mempool-block/0">projected to be in upcoming blocks</a> change in near real-time.</p>
<p>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 <b>expected block</b> for the block height in question, and it serves as the basis for the block audit.</p>
<p>When details for an expected block and actual block are available, we can compare them. <b>The purpose of block audits is to deduce when miners intentionally include or exclude transactions from blocks they mine.</b> Since this information cannot be precisely known, Mempool uses a handful of heuristics to accomplish this.</p>
<p>Block audits highlight transactions in different colors to convey these heuristics:</p>
<ulclass="no-bull block-audit">
<li><spanclass="block-audit-highlight-color added">■</span><code>Added</code><p>A transaction is highlighted blue if it is not present in the expected block, present in the actual block, and also either:</p>
<ul>
<li>far out of the expected feerate range, meaning the miner may have intentionally prioritized the transaction</li>
<li>not in the mempool at all, meaning the miner may have accepted the transaction out-of-band</li>
</ul>
<p>Added transactions do not negatively affect <a[routerLink]="['/docs/faq'|relativeUrl]"fragment="what-is-block-health">block health</a>.</p></li>
<li><spanclass="block-audit-highlight-color recent">■</span><code>Recently broadcasted</code><p>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.</p><p>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.</p><p>Recently-broadcasted transactions do not negatively affect <a[routerLink]="['/docs/faq'|relativeUrl]"fragment="what-is-block-health">block health</a>.</p></li>
<p>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.</p><p>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.</p>
<p>Marginal fee transactions do not negatively affect <a[routerLink]="['/docs/faq'|relativeUrl]"fragment="what-is-block-health">block health</a>.</p></li>
<li><spanclass="block-audit-highlight-color removed">■</span><code>Removed</code><p>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.<p>Removed transactions do negatively affect <a[routerLink]="['/docs/faq'|relativeUrl]"fragment="what-is-block-health">block health</a>.</p></li>
</ul>
<p>See how results of the block audit are used to devise the block health score <a[routerLink]="['/docs/faq'|relativeUrl]"fragment="what-is-block-health">below</a>.</p>
<p>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.</p>
<p>How is it calculated? Let <spanclass='math'>s<sub>expected</sub></span> be the set of all transactions in Mempool's expected block and let <spanclass='math'>s<sub>actual</sub></span> be the set of all transactions in the actual block. Then let <spanclass='math'>n</span> be the number of all transactions in both <spanclass='math'>s<sub>expected</sub></span> and <spanclass='math'>s<sub>actual</sub></span>.</p>
<p>Furthermore, let <spanclass='math'>r</span> be the number of transactions Mempool deduces were <a[routerLink]="['/docs/faq'|relativeUrl]"fragment="how-do-block-audits-work">intentionally excluded</a> from <spanclass='math'>s<sub>actual</sub></span>.</p>
<p>The number of transactions appearing in both <spanclass='math'>s<sub>expected</sub></span> and <spanclass='math'>s<sub>actual</sub></span> 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:</p>
<p>As a result, block health is <i>not</i> 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 (<a[routerLink]="['/block/0000000000000000000515e202c8ae73c8155fc472422d7593af87aa74f2cf3d']">extreme example</a>).</p>
<p>See more context in our FAQ on <a[routerLink]="['/docs/faq'|relativeUrl]"fragment="how-do-block-audits-work">block audits</a>.</p>
The official mempool.space website is operated by The Mempool Open Source Project. See more information on our <a[routerLink]="['/about']">About page</a>. There are also many unofficial instances of this website operated by individual members of the Bitcoin community.
<p>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 <ahref="https://github.com/mempool/mempool/tree/master/docker"target="_blank">Docker images</a>.</p><p>In any case, we only provide support for manual deployments to <ahref="/enterprise">enterprise sponsors</a>.</p>
<p>For casual users, we strongly suggest installing Mempool using one of the <ahref="https://github.com/mempool/mempool#one-click-installation"target="_blank">1-click install methods</a>.</p>
Yes, we publish Docker images (or you can build your own). Check out <ahref="https://github.com/mempool/mempool/tree/master/docker"target="_blank">the documentation</a> for details.
</ng-template>
<ng-templatetype="address-lookup-issues">
<p>If you're getting errors when doing address lookups, it's probably because of your Electrum server backend.</p><p>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:</p><ol><li><ahref="https://github.com/romanz/electrs"target="_blank">romanz/electrs</a>. 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.</li><li><ahref="https://github.com/cculianu/Fulcrum"target="_blank">Fulcrum</a>. 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.</li><li><ahref="https://github.com/Blockstream/electrs"target="_blank">blockstream/electrs</a>. If you have stronger hardware, consider running Blockstream's electrs implementation. It's the backend mempool.space uses, and is also what powers blockstream.info.</li></ol>
