mempool.spaceMempool.space and self-hosted Mempool: data sources
Mempool.space provides a hosted Bitcoin explorer and API. Running the open-source Mempool software with your own Bitcoin node changes the source of the pending-transaction view and gives you control over that node’s mempool settings.
Last updated:
Where does the hosted pending view come from?
The project’s FAQ describes two node roles in the hosted service. Small Nodes have a 300 MB mempool memory limit and supply the rejection threshold displayed under the Purging label during congestion. Big Nodes have much larger memory limits, allowing the service to retain transactions with low fee rates that smaller nodes may reject when their memory is full.
The large-node view can therefore include a transaction that is absent from a smaller local mempool. Its coverage consists of transactions that the service has received; a larger allocation does not establish a complete record of every pending Bitcoin transaction.
Changing a local memory limit
A larger mempool allocation can let your node retain more pending transactions when its existing memory budget is the constraint. Memory usage includes indexes, pointers, and other overhead. It exceeds the combined size of the pending transaction data, so the two figures measure different things.
Each Bitcoin node maintains its own mempool. Changing a local memory budget does not make its contents identical to those of Mempool.space. Projected blocks depend on the transactions visible to an instance and their dependencies, while miners select transactions from their own views. Increasing the allocation cannot reserve space in a mined block or guarantee a confirmation time.
API access depends on the deployment
The hosted REST API applies rate limits. Exceeding them produces HTTP 429 responses, and repeated excess can lead to an access ban. The documentation points to enterprise sponsorship for higher hosted limits.
A self-hosted API’s capacity depends on its server and backend. The operator controls the access rules configured for that deployment.
Endpoint scope also matters. The project’s API reference varies its endpoint listings by selected network and backend, and some entries are specific to its hosted instance. Installing Mempool alone does not establish that every endpoint in the hosted reference is available on that installation.
Ways to run a separate instance
The project documents one-click installation on supported full-node distributions, including Umbrel, RaspiBlitz, and StartOS. Docker, manual backend and frontend installation, and production deployment guidance are additional routes intended for people with server-management experience.
The installation route and the data source are separate choices. The configured Bitcoin node and backend determine which data the instance can present.
Choosing a data source
- If you need your own node’s pending view, confirm that the instance uses that node and the intended Bitcoin network.
- If missing transactions with low fee rates coincide with local memory pressure, review the node’s mempool allocation and rejection threshold before changing the budget.
- If an application needs sustained API access, check the hosted service’s limits or the capacity and required endpoints of the self-hosted deployment.