StratumStats
Method 2026-09-04.37
StratumStats measures several independent parts of pool performance and summarizes them in a transparent 0–100 score. The underlying measurements remain visible because no score makes one pool universally best.
The median delay until one configured endpoint sends its first clean previous-block-hash transition, compared with the earliest transition seen for the same Bitcoin block and region. Scout timestamps the first readable byte before waiting for the rest of the message or parsing it, then forwards the block hash, endpoint timestamp, and only the coinbase source needed by displayed payout fields. Lower is better. The dashboard uses the latest 24 hours.
The 95th-percentile delay. Ninety-five percent of measured deliveries were this fast or faster, so P95 exposes occasional stalls that the median may hide.
Observed clean block transitions divided by eligible block measurements for that configured endpoint during the latest 30 days. Every configured endpoint is eligible once a block window is confirmed, even if it is disconnected, because a down server cannot provide mining work. Scheduled measurements enter this calculation only after their complete atomic block sample is received. A regional cohort is excluded when at least 20% of eligible endpoints across at least five pools miss together, because that correlated failure indicates an unhealthy observer rather than independent pool downtime. Neither the misses nor the surviving measurements in that cohort contribute to dashboard metrics or scores; the raw evidence remains stored. The dashboard shows availability directly; estimated mining loss carries the color bar.
First-to-block percentage is the share of eligible block measurements in the latest 24 hours where this endpoint had a zero relative delay: it was the first observed clean block transition in that region’s cohort. Gold bars in the latency graph mark those first-to-block arrivals. This is an observation of template arrival, not proof of who mined or solved the Bitcoin block.
The unavailable share of eligible template deliveries plus median relative delay during available time, using Bitcoin’s 600-second target block interval. This estimates idle and stale-work time; it is not measured payout or revenue loss.
Time to establish the basic network connection to a pool, including local name lookup.
Time to establish an encrypted connection and verify the pool’s certificate, hostname, validity period, and trusted issuer.
mining.subscribeThe Stratum request that starts a mining session.
mining.authorizeThe Stratum request that asks the pool to accept the worker identity.
Each results section repeats one region-wide update time and block height. The update time is the observation time of the selected region’s latest successfully accepted atomic block sample, not a separate timestamp for that pool group. Local collections use the newest displayed pool observation when no regional sample status exists.
The height is decoded from BIP34 data in the latest available coinbase observed from that region. It is not an independent Bitcoin node chain-tip query and may lag until the selected vantage completes another block sample containing a decodable coinbase. All visible height pills flash together when a later height arrives after the page’s initial render.
The 0–100 score weights availability at 40%, estimated mining loss at 25%, P95 block delay at 20%, connection and Stratum setup responsiveness at 10%, and observed fee stability at 5%. Mining loss below 0.1% receives the full component score and is displayed as <0.1%. Availability is graded steeply near 100% because a missed eligible delivery means no clean new-block transition was received.
A score requires recent median and P95 measurements, except that a solo pool whose worker wallet is not found receives a score of 0 immediately. Responsiveness and fee stability are included only when observed; their missing weights are redistributed across the measured components rather than counted as failures. Fee stability requires at least two matched solo-pool fee samples. A newly observed fee increase subtracts up to 15 additional points, tapering evenly to zero over 30 days. An observed fee above 2.5% subtracts 2.5 points per excess percentage point, capped at 10 points; fees through 2.5% receive no level penalty. An invalid TLS certificate subtracts 10 points. Shared-pool fees remain unobservable and do not affect their score.
Each measured input becomes a component score from 0 to 100. Values between the listed points use straight-line interpolation; values beyond either end are clamped to the nearest endpoint.
delay_loss = median_ms ÷ 600,000 × 100
mining_loss = (100 − availability) + (availability ÷ 100 × delay_loss)
All values are percentages. This adds missed eligible endpoint deliveries—including periods when that endpoint was down—to delay loss during available time.
base = (40A + 25L + 20P + 10R + 5F) ÷ W
A is availability, L mining loss, P P95, R responsiveness, and F fee stability after each is converted to a 0–100 component score. W is the sum of included weights: 100 when every component is available, 95 without fee stability, 90 without responsiveness, or 85 without either.
increase_penalty = 15 × (1 − age_days ÷ 30)
high_fee_penalty = min(10, 2.5 × max(0, fee_pct − 2.5))
tls_certificate_penalty = 10 if any certificate error, otherwise 0
The increase penalty applies only to an observed increase less than 30 days old; otherwise it is zero. The high-fee penalty applies only to an observed solo-pool fee above 2.5%.
score = round(clamp(base − increase_penalty − high_fee_penalty − tls_certificate_penalty, 0, 100), 4 decimals)
The API and ranking retain four decimal places to avoid artificial ties. The dashboard badge displays the result as a whole number. Exact score ties rank by lower median block delay, then lower P95, then endpoint name; missing delay measurements come last.
score = 0 for a solo pool when its worker wallet is not found
The worker-wallet rule overrides the weighted calculation because an absent or inconsistent worker payout means the tested solo configuration would not pay the miner. A missing optional component is omitted from both the weighted numerator and W, so missing evidence is not treated as failure.
| Component | Measurement → component score | Calculation detail |
|---|---|---|
| Availability (A) | ≤90%→0 · 95%→20 · 98%→60 · 99%→80 · 99.5%→90 · 100%→100 | Uses eligible deliveries from the latest 30 days. |
| Mining loss (L) | ≤0.1%→100 · 0.25%→90 · 0.5%→75 · 1%→50 · 2.5%→10 · ≥5%→0 | Uses the combined mining-loss equation above. |
| P95 delay (P) | ≤250ms→100 · 500ms→90 · 1,000ms→75 · 2,000ms→50 · 5,000ms→10 · ≥10,000ms→0 | Uses the rolling 24-hour P95. |
| Responsiveness (R) | 0ms→100 · 100ms→95 · 250ms→80 · 500ms→60 · 1,000ms→30 · ≥2,500ms→0 | Average curve score of observed median TCP, TLS, subscribe, and authorize timings. |
| Fee stability (F) | clamp(100 × (1 − changes ÷ (samples − 1)), 0, 100) | Included for solo pools with at least two matched fee samples. |
Block-template delay is compared only for the same previous-block hash observed from the same region. This reduces differences caused by geography and clock timing. Median, P95, history, and Stratum response timings use a rolling 24-hour window. Observations older than 30 days are excluded from availability, counts, and scores.
Only the first clean transition for a hash counts. Later jobs with the same hash are ignored even when their transaction set changes.
For the first accepted notification per endpoint and block, Scout forwards only the split coinbase, subscribed extranonce context, and a SHA-256 hash of its generated worker output script. StratumStats reconstructs the transaction, derives the webpage fields, and discards the forwarded source before storage.
For a solo pool with a matched worker output, the observed effective fee is 100 × (total coinbase value − worker payout) ÷ total coinbase value. Donations or configured payout splits may be included in that percentage.
Shared-pool miner fees cannot be measured from the block coinbase because participant balances and later payouts are handled separately. StratumStats therefore does not display a fee for shared pools.
A non-worker destination is a positive-value coinbase output that did not match the probe worker script. It may be a pool fee, donation, witness commitment, payout split, or another participant; it does not prove ownership.
Free solo pools have a consistently matched worker payout and a latest observed fee of 0%. Paid solo pools have a matched payout and either a nonzero or not-yet-measured fee. Pools whose worker wallet was absent from decoded coinbase payouts are shown separately from pools that still need payout evidence.
PPLNS means Pay Per Last N Shares: rewards are based on work submitted during a recent share window. Other shared pools use different payout methods.
Pool size, popularity, sponsorship, paid placement, subjective reputation, operator-advertised fees, unobservable shared-pool fees, and vantage-wide unhealthy regional cohorts.
Operational details that could identify measurement traffic are intentionally withheld. Published results are aggregated to protect measurement integrity.