How to read it: Under a fair, memoryless mining process, each pool's probability of winning any given block equals its hash share. That means P(same pool mines block N+1 | same pool just mined block N) = hash share exactly — the 1× baseline. Bars longer than 1× mean a pool converts a first block into a second block far more often than chance allows.

Key Insights:

• Why pools beat 1×: Upon mining block N, a pool already holds the header and can begin hashing block N+1 immediately — while every competitor first downloads, validates, and acknowledges block N (~13 s lag). This head-start inflates consecutive win rates above the pure hash-share baseline.
• Connecting Acts I & II: Act I showed these pools produce more 7+ streaks than statistics allow. This chart closes the loop — the same pools are winning the second block at a systemically elevated rate, not through luck but through latency monopoly.
• Interpreting magnitude: A 1.3× lift on a pool with 20% hash share translates to ~6 extra consecutive blocks every 100 mined — thousands of extra block opportunities per year at scale.

How to read it: This chart breaks down the time duration between consecutive blocks mined by the same pool into specific time buckets (e.g., < 30s, 30s-60s). The < 30s bucket is explicitly highlighted in red/orange.

Key Insights:

• The "Danger Zone": Blocks found within 15 to 30 seconds of the previous block are highly prone to causing network forks. Other mining pools (who often refresh stratum jobs every 30 seconds) may not have received the previous block yet.
• Propagational Advantage: Pools that consistently dominate the < 30s bucket often possess significant network latency monopolies, allowing them to win tight block races and trigger multi-block reorgs.

How to read it: Each bubble is a pool's 30-day average. X = avg transactions per block; Y = avg block size in MB; bubble size = sample weight (blocks mined). Color encodes bytes-per-transaction: 🟢 green = compact (fee-optimizing), 🟡 amber = medium, 🔴 red = inscription-heavy.

Fingerprint insight: Pools mining many small txs at the same block size as larger-tx pools are packing in more fee revenue per byte — a sign of active mempool management. High bytes-per-TX pools are filling blocks with witness-heavy data (Ordinals, Inscriptions).

How to read it: Average witness-data overhead (bytes) per transaction on a log₁₀ scale. BIP 110 proposes a 256 B/tx soft-limit. The arrow (↑/↓) shows whether the pool is above or below that threshold; hover for the pool's peak single-block spike.

Note: marapool's 5,141 B/tx average is driven by a deliberate Ordinals-mining policy — their per-block peak hit 332 kB/tx. All other pools cluster between 280–420 B/tx.