Here’s a risk that won’t trend. It has no drama, no chart with an arrow on it, nothing for anyone to shout about. It’s just a slow, structural problem sitting under most proof-of-work networks, and it gets ignored precisely because it’s dull. I want to talk about mining-pool centralisation — what it is, why it matters, why nobody bothers with it, and why I deliberately built our stack’s pool the way I did.
This is opinion, and it’s mine. There’s no money talk in it — see the software & demo notice. It’s an engineering and governance argument about how networks fail quietly.
01 · What pool centralisation actually is
A mining pool is just a co-operative: lots of individual miners point their machines at one coordinator, which assembles the block template, hands out work, and shares the proceeds. Perfectly sensible — pooling smooths out the randomness of solo mining so small participants get steady, predictable results.
The problem isn’t pooling. The problem is concentration. When a handful of pools end up coordinating the majority of a network’s hashrate, the network’s security quietly stops being “thousands of independent miners” and becomes “a few pool operators, and everyone who trusts them.” Individual miners may number in their thousands, but if they’ve all plugged into three or four coordinators, the decision-making lives in three or four places. As a rough illustration of the shape of the problem, it’s not unusual for the top few pools on a large network to between them coordinate well over half of all hashrate.
That’s the whole risk in one sentence: the work is distributed, but the control is not.
02 · Why concentrated control is dangerous
A pool operator doesn’t own the miners’ hardware. But they decide what those miners work on — which transactions go in the block, in what order, and on top of which chain tip. Concentrate enough of that decision-making and several unpleasant capabilities appear:
- 51% and reorg capability. If pools that together command a majority of hashrate ever coordinated — by choice, by collusion, or by coercion — they could rewrite recent history: double-spend, orphan honest blocks, censor at will. It doesn’t require malice from the miners; it requires control over what they’re pointed at.
- Transaction censorship. A dominant coordinator can simply decline to include certain transactions. Individually that’s an inconvenience; at majority scale it’s the power to decide who gets to use the network.
- Single points of failure and coercion. A pool is a company, in a jurisdiction, with employees and servers and a legal address. That makes it something to pressure, subpoena, hack, or shut down. The more of the network that depends on a few such points, the more fragile the whole thing is — and the easier it is to lean on.
None of this needs a villain. It just needs concentration plus a bad day.
03 · Why it’s the “boring” risk
So why does almost nobody talk about it? Because it doesn’t move a price, so it doesn’t make a headline. There’s no candle to point at, no event to react to, no number to screenshot. It’s a structural property of a network that sits there unchanged for months — and our collective attention span in this field is calibrated to drama, not to slow structural rot.
It’s the smoke detector with a flat battery. Nobody thinks about it, nothing bad is visibly happening, and then one day it matters enormously and everyone asks how we let it get this concentrated. The boring risks are the dangerous ones exactly because they’re boring — they accumulate while we’re all looking at something louder.
04 · What actually helps
The encouraging part is that this is a solvable problem, and the fixes are mostly about giving control back to the individual miner rather than the coordinator:
- Stratum v2. The most important one. Among its changes is letting individual miners choose their own transaction sets rather than blindly working whatever the pool hands them. That’s a structural answer to censorship: even a large pool can’t dictate block contents if its miners are picking transactions themselves.
- Solo and SOLO-style options. Letting people mine directly against their own node, or in arrangements that don’t hand block-template control to a central coordinator, keeps decision-making distributed even when payouts aren’t.
- More independent pools. A long tail of smaller, independently-operated pools is healthier than a short head of giants — it raises the number of parties you’d have to compromise to threaten the network.
- Transparency and audit logs. A pool that publishes what it’s doing — its share of hashrate, its block-template policy, an auditable record — can be checked. One that operates as a black box can only be trusted, and “trust me” is not a security model.
05 · Why I built our pool to be transparent and re-skinnable
This is where my own hands are dirty, so I’ll be straight about it. The stack we build includes a mining pool, and I had a choice about what kind of pool to make it. I deliberately did not build “another opaque mega-pool.”
I built it to be re-skinnable and transparent instead. When someone licenses the stack, they stand up their own independent pool under their own brand — which, in the small way one project can, adds to the long tail of independent operators rather than the short head of giants. And the pool is built to be inspectable: its stats are exposed, its behaviour is observable, and there’s nothing about it that only works if you take the operator’s word for it. On our own demo the live pool figures are published openly precisely so they can be checked rather than trusted.
I’m under no illusion that one re-skinnable pool fixes a network-wide structural problem. It doesn’t. But I’d rather the thing I ship be part of the decentralising tail than the centralising head, and I’d rather it be transparent by construction than opaque by default. If you’re going to build infrastructure, build the kind you’d be comfortable seeing widely copied.
That’s the boring risk, and that’s my boring, deliberate answer to it. It won’t trend. I think it matters anyway.