Monero Consensus Status

The open source code for this web app is available here. If website is unstable, run it on your own computer.


This web app displays a visualization of recent orphaned blocks and alternative chains of the Monero blockchain.

Occasional orphaned blocks are normal. They occur naturally when two miners mine different valid blocks almost simultaneously. A high rate of orphaned blocks can indicate a problem in network-wide connection latency or even malicious behavior by one or more entities with a large hashpower share.

If a malicious entity with a high share of network hashpower attempted a selfish mining strategy to raise its share of block rewards, the rate of orphaned blocks could increase. The malicious entity would cause the blocks of other pools to become orphaned. This evidence would appear in the visualization below.

A malicious entity with 50 percent or more of total network hashpower could attempt deep chain re-organizations by mining an alternative chain. Alternative chain are like orphaned blocks, but are more than one block in length. Alternative chains should appear in the visualization below.

This web app is new and untested.

Click to toggle dark mode:
Note: Total displayed chain length will not exceed 150.


(%) block(s) orphaned in last 720 blocks (about 24 hours).
Last checked for new block: UTC


Below is a line chart of the percentage of blocks mined by each mining pool. Over long intervals, the percentage of blocks mined by each mining pool can help assess certain risks in the Monero ecosystem. A malicious mining pool that acquires a majority of mining hashpower for a period of time can cause problems for ordinary users and other miners, depending on its choices:

Double-spend attack


Arguably the most harmful behavior of a majority-hashpower miner, often known simply as a "51% attack", is a double-spend attack. Satoshi Nakamoto, the creator of bitcoin, described it in section 11 of his 2008 bitcoin white paper:
We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain. Even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air or taking money that never belonged to the attacker. Nodes are not going to accept an invalid transaction as payment, and honest nodes will never accept a block containing them. An attacker can only try to change one of his own transactions to take back money he recently spent.

To execute the double-spend attack, a miner would have to send Monero coins to a victim, such as a merchant or centralized exchange. The victim would wait a certain number of block confirmations, depending on the victim's preference, and then send an irretrievable item to the miner, such as a physical good shipped in the mail or coins of another type of cryptocurrency.

Meanwhile, the miner would be mining an alternative chain in secret that contains a transaction that contradicts the "payment" to the victim. Once the malicious miner's chain was long enough and enough blocks on the honest public chain are confirmed, the miner would broadcast the secret chain, which causes a "blockchain reorganization" and reverses the payment to the victim.

Such an event would be observable to everyone running a Monero node. The "Orphaned blocks" visualization on the previous page would show a long alternative chain of many blocks being orphaned by the network. Also, one or more transactions present in the alternative chain would not be present in the main chain, and vice versa. The majority hashpower miner cannot reveal private information about Monero transactions nor force honest Monero nodes to accept blocks that do not comply with the requirements of the consensus of Monero's blockchain protocol.

Selfish mining all blocks


A miner with majority hashpower could decide to reject all blocks of other miners and instead only build on top of the malicious miner's own blocks. This behavior would deprive all other miners of block reward revenue. There would be little direct disruption to ordinary users in this situation.

Mining empty blocks


If a majority-hashpower miner mines all blocks, it can choose to include zero transactions in all blocks. That would stop all new transactions from being confirmed on the blockchain. This behavior would cause a major disruption to all ordinary users until the miner is unwilling or unable to mine all empty blocks.

Mining only certain transactions


Instead of mining blocks with zero transactions, a miner could include only certain transactions in blocks. Monero transactions are mostly indistinguishable from one another, so it is not clear on what basis a miner would reject/accept transactions. However, the miner could demand a higher fee per transaction, at least.

Chart


The below chart aggregates the percentage of blocks each mining pool has mined in 6, 12, or 24 hour intervals. Mining blocks is a random process, but just as large sample sizes can provide reliable statistical estimates, large aggregation intervals can give a picture of actual hashpower of each mining pool. The Monero protocol aims to confirm a block about every two minutes on average. Therefore, about 180, 360, and 720 blocks should be produced in each 6, 12, and 24 hour interval, respectively, in normal circumstances.

The time indicated on the horizontal axis is the time of the end of the measured interval, e.g. when the aggregation interval is set to 6 hours, the value at 18:00 UTC is the aggregate value between 12:00 UTC and 18:00 UTC. The data starts at August 8, 2025 at 12:00 UTC because almost all mining pools' APIs had been added to the pool data collection tool by that time. Any known pools that are not in the top 5 pools are included in the "other known pools" category.

Glide your mouse over the chart's lines to view exact numbers.
Click to toggle dark mode:
Created by Rucknium at the Monero Research Lab
Pool mining data collected by monero-blocks, developed by DataHoarder.