Stake pools that have stopped minting, ranked by how unlikely it is that their silence is just bad luck
Every pool below has minted at least one block in its lifetime but has gone silent since the date shown. The odds give the probability that the silence is down to chance; they are not proof that a pool is broken.
Scope. Pools that have minted at least one block, are not retired, and have produced nothing for 92 days or more. No stake floor.
Pools in the "Possible" band (where the odds are around 1 in 1) are moved to a collapsed section at the bottom, because the maths correctly says silence is unsurprising for a pool that small.
The maths. A pool's expected blocks in an epoch is its share of total active stake times 21,600 (432,000 slots times the 0.05 active-slot coefficient), reduced by the decentralisation parameter for the early epochs when federated core nodes still produced part of the chain. We sum that across the complete epochs of the silent period, using the pool's actual stake in each epoch, to get lambda, the blocks it should have made. The epoch in progress is excluded, so lambda is if anything slightly conservative. Under a Poisson model the chance of zero blocks is e to the minus lambda, shown as "1 in N". "1 in N" is the chance of this silence if the pool were healthy, not the chance the pool is broken.
Why the odds are capped. We do not display anything beyond 1 in 10^15; larger values read as "worse than 1 in 10^15". The Poisson model assumes a constant block rate and independent epochs, and beyond that point those assumptions dominate the arithmetic, so a bigger number would imply more confidence than the method supports. The true lambda stays in the column tooltip so the working is still visible.
The label under each odds figure describes the chance that the silence is just luck. Almost zero: 1 in 1,000,000 or worse. Highly unlikely: between 1 in 10,000 and 1 in 1,000,000. Unlikely: between 1 in 100 and 1 in 10,000. Possible: better than 1 in 100.
Stake over the silent period, not just today. Expected blocks is computed from the stake the pool held in each silent epoch, not from its current stake. The two figures can differ sharply: a pool that has since lost its delegators is still judged on the stake it held while silent. To make this explicit the table shows two stake columns, "Stake now" (today's active stake) and "Avg stake, silent" (the average stake it held across the silent epochs, which is the basis for expected blocks). If expected blocks looks large next to a small current stake, it is because the pool was much larger while it was going dark.
Lifetime blocks is the total number of blocks the pool has ever minted. It is context, not part of the probability: a pool that produced thousands of blocks and then stopped reads very differently from one that only ever made a handful.
Prior silences counts earlier periods when this pool stopped minting for longer than chance explains, using the same maths as the headline odds: for each gap between consecutive blocks we compute the blocks the pool should have made from its stake at the time, and count the gap if the probability of that silence by chance is 1 in 10,000 or worse. Because the calculation uses the pool's own stake it scales with size, so a large pool qualifies after a short gap and a small one only after a long one. The count excludes the current silent period, which is already the headline figure. It shows that a pool went dark before, not why: an expired key, a failed host, a migration and an abandoned pool all look the same from outside.
The risk bar, shown under the odds figure, is a log-scale visual encoding of lambda, weighted by stake, not by raw days. A large pool silent 95 days reads redder than a tiny pool silent a year, because its expected blocks are far higher.
Observed rotations are context, not evidence of a fault. The dates come from block headers: each is the first block minted on a new operational certificate, meaning one where either the key or the counter has changed. Two limits on reading them. First, a rotation only becomes visible when a block is minted on it, so for a silent pool the date can never be more recent than the last block. Second, some rotations cannot be seen at all. An operator who regenerates the same KES key from a stored seed and leaves the counter alone produces a certificate identical, in every field the chain records, to the one before it. What we show is therefore a lower bound on how often a pool has rotated, not a count, and we do not treat a long gap as a problem.
Days since last rotation. How many days have passed since the last rotation we can see, shaded from green to red as the figure grows. On the silent list a large figure mostly reflects how long the pool has been dark rather than a late rotation, since the date cannot be more recent than the last block. The colour is a magnitude cue only; it does not imply the operator is behind on rotating.
Rotation pattern reports whether the intervals between visible rotations are regular or irregular, with the typical interval. Descriptive context about what the chain recorded, nothing more.
Where we show no figure. For some pools the record itself proves we cannot see the full picture, and we prefer a label to a number we know is wrong. "Rotations not visible" means the same certificate appears on blocks more than 93 days apart; a KES key cannot outlive about 93 days, so the pool has rotated more often than the chain shows, and its date, days since and pattern are all withheld. "Alternating certificates" means the pool's blocks flip between certificates rather than moving from one to the next, which is common in failover setups where the block producer moves between machines and usually reflects careful operation rather than a fault; we keep the date but withhold the pattern, since the intervals no longer describe a rotation history.
This pool has minted no blocks since a given date, and given its stake the probability of that by chance is about 1 in N.
We cannot claim the KES key has expired for a silent pool. The operational certificate is only visible in block headers, and a silent pool produces none, so its current rotation state cannot be observed at all. Possible causes are an expired KES key, a failed or offline node, misconfigured relays, or an abandoned pool. We never assert which.
| Loading... |