Monero Hashrate Watch: Network Growth and P2Pool's Share

Monero's difficulty-derived network hashrate was 6.951 GH/s in the November 13 snapshot. P2Pool main, mini and nano together estimated 543.778 MH/s, or 7.824% of that network reading. Compared with our November 10 baseline, the network estimate rose 3.81% and P2Pool's combined estimate rose 1.38%. P2Pool's estimated share still fell because the network reading grew faster.

That is growth between two observations, not proof of a steady trend or an increase in the number of miners. A separate comparison with a block about 24 hours earlier shows a small decline in the network estimate. Different comparison dates tell different parts of the story.

Current readings and the earlier baseline

We retrieved the public main observer, mini observer and nano observer responses at 19:37:58 UTC on November 13, 2026, within one second of each other. All three identified Monero block 3,805,715 with difficulty 834,067,944,965. XMRChain's record for that block independently matched its hash and difficulty. Its recorded block time was 19:29:59 UTC.

The earlier column comes from the saved public API responses behind our November 10 Monero Signal baseline, collected at 01:47:21 UTC. We recalculated both columns from the raw difficulty fields using the same formulas.

Measurement	November 10 baseline	November 13 snapshot
Monero network estimate	6.695 GH/s	6.951 GH/s
P2Pool main	497.762 MH/s	505.801 MH/s
Main estimated network share	7.435%	7.277%
P2Pool mini	33.324 MH/s	32.840 MH/s
Mini estimated network share	0.498%	0.472%
P2Pool nano	5.314 MH/s	5.137 MH/s
Nano estimated network share	0.079%	0.074%
Combined P2Pool	536.400 MH/s	543.778 MH/s
Combined estimated network share	8.012%	7.824%

One MH/s means one million hashes per second. One GH/s means one billion. The combined percentage equals the sum of the three P2Pool estimates divided by the network estimate, multiplied by 100. The denominator already includes P2Pool mining.

All three observer endpoints belong to one service. Their agreement provides a consistency check within that service. Their latest sidechain timestamps were 19:37:43, 19:37:28 and 19:37:52 UTC, respectively, about 16, 31 and 7 seconds before receipt. The November 10 sidechain timestamps ranged from 01:43:56 to 01:47:04 UTC. Timestamp freshness alone cannot establish whether an observer has caught up with the chain. The current network reference was about eight minutes older than receipt, and a later explorer response already reported a higher chain height.

The 24-hour, seven-day and thirty-day comparisons

For the network, historical block records let us compare the same calculation: each block's difficulty divided by Monero's 120-second target. We selected blocks close to the current reference block's time on the earlier dates. Each point estimate reflects the difficulty at its reference block. None averages the intervening day, week or month.

Comparison	Earlier block time, UTC	Earlier estimate	Change to 6.951 GH/s
About 24 hours	November 12, 19:28:27	7.007 GH/s	-0.81%
About seven days	November 6, 19:29:04	6.383 GH/s	+8.89%
About thirty days	October 14, 19:29:20	5.916 GH/s	+17.48%

The underlying difficulties are 840,894,440,758 at block 3,804,978, 765,955,298,076 at block 3,800,634 and 709,946,087,128 at block 3,784,066. Their timestamps are 92, 55 and 39 seconds earlier than the exact comparison targets. Block timestamps can be irregular, so these are near-time samples rather than a claim that each is the uniquely closest block.

For separate daily context, XMRList's network charts reported 6.89 GH/s for November 12, the latest complete UTC day. Its page says it averages block difficulty and divides by 120 seconds. The saved page's update time was November 13 at 19:30:10 UTC. That daily average uses a different window from our reference-block estimate. We do not turn their difference into a daily growth rate.

P2Pool comparison	24-hour change	Seven-day change	Thirty-day change
Main	Unavailable	Unavailable	Unavailable
Mini	Unavailable	Unavailable	Unavailable
Nano	Unavailable	Unavailable	Unavailable
Combined estimated network share	Unavailable	Unavailable	Unavailable

We verified the November 10 baseline, but did not find matching historical sidechain observations for those three intervals. Substituting a roughly three-day-old reading into a 24-hour column would mislabel the evidence. The network history above comes from archived block records, while the P2Pool history remains sparse.

What difficulty and smoothing mean

Miners repeatedly try hashes until one meets the network's target. Difficulty expresses the expected amount of work required to find a qualifying block. Dividing difficulty by the target block interval gives an estimate of the hash rate that would produce that interval on average. Nobody measures every miner's processor directly.

Monero adjusts difficulty using earlier blocks. The Monero v0.18.5.4 parameters specify a 720-block window, a 15-block lag and timestamp trimming. At the two-minute target, 720 blocks correspond to roughly a day. Those rules make the difficulty calculation differ from a simple measurement of the last 24 clock hours.

P2Pool has three separate share chains. We divide main and mini difficulty by 10 seconds, and nano difficulty by 30 seconds. The P2Pool v4.18.1 code uses a 2,160-block chain history, includes eligible uncle blocks and trims timestamp extremes for difficulty. The nominal history spans about six hours for main and mini, and eighteen hours for nano. Actual elapsed spans vary with block timing, and trimming changes the span used in the calculation.

Smoothing reduces the influence of individual lucky or unlucky discoveries, but also delays how an estimate reflects new mining power. Combining these P2Pool estimates with Monero's differently smoothed estimate gives an approximate network share. It does not give a common-window measured share.

P2Pool miners cooperate through a share chain while contributing work to Monero.

A payout window determines which recent shares qualify when the pool finds a Monero block. In this snapshot, main's reported payout window was 313 sidechain blocks, while mini and nano reported 2,160. Those values must not replace the difficulty history described above. The official P2Pool documentation explains its PPLNS payment model.

Mining luck is the randomness of finding blocks. A pool can keep hashing at the same speed yet find blocks close together or wait much longer than expected. A long wait for a reward does not establish an outage. A change in an estimate does not identify an attack or show that miners moved between pools.

Possible explanations, ranked by the evidence

1. Measurement effects: high confidence in the mechanism, unknown contribution to this change. The source code confirms different histories and smoothing rules. Random block timing can move estimates without a matching change in physical computing power. These snapshots cannot tell us how much of the change comes from randomness and how much comes from miners joining or leaving.

2. Price and profitability: plausible mechanism, low confidence as an explanation here. Kraken's XMR/USD hourly candles closed at $531.13 for the hour ending November 13 at 19:00 UTC, down 1.48% over 24 hours and 14.67% over seven days. The daily candles give a 0.62% thirty-day gain at 00:00 UTC, nineteen hours earlier. We exclude unfinished candles as instructed by Kraken's documentation.

A higher XMR price can raise revenue for the same coin reward, while higher difficulty reduces expected XMR earned per hash. Electricity, hardware costs, fees and any merge-mining revenue also matter. These exchange prices do not measure miners' profit or identify their decisions. In this comparison, the seven-day price and network estimates moved in opposite directions. Their windows also differ. The available data does not establish causation.

3. Software and hardware: documented changes, low confidence in a connection to this period. The latest release records checked on November 13 were Monero v0.18.5.4, published October 17, P2Pool v4.18.1, September 22, and XMRig v6.26.0, March 28. XMRig's notes include Zen 5 VAES-512 support and RandomX optimizations. Release availability alone does not establish adoption, a new network rule or a measured network-wide speedup. No verified hardware deployment totals explain this snapshot.

4. Pool concentration and outages: contribution unknown. P2Pool's estimated share is not a count of independent miners or a full measure of decentralization. It does not show who controls the remaining hash power. The public pool comparison is useful context, but pool-reported estimates and shares of discovered blocks can have different windows and incomplete attribution. An outage explanation remains unsupported by a dated incident record tied to these observations. The fresh sidechain timestamps establish recent observed activity, not uninterrupted service across the comparison period.

5. Botnets, rented hash power or deliberate disruption: no verified attribution for this change. Huntress's October 2026 AhsayCBS investigation documented attackers deploying XMRig on compromised systems, with exploitation observed from October 7. That is evidence of malicious mining, but the report supplies no network-wide hash contribution that explains these November readings.

Research on Qubic's 2025 campaign, revised August 1, 2026, combined node measurements and pool observations to study disruptive mining. Its findings concern that earlier campaign. We obtained no verified rental-volume series or dated rental event linking rented hash power to this change. Public totals alone cannot distinguish rented equipment, botnets and ordinary miners.

The next observation

The cause of the changes remains unknown. Future comparisons need repeated, timestamped P2Pool readings using the same calculation, alongside the network difficulty record. For newer readings, see the network page. This article preserves the November 13 observation rather than silently substituting live values.