1 EH/s Is Not a Server Problem: What It Actually Takes to Scale a Bitcoin Mining Pool

Running a Pool Is Easy Until It Isn't

Running a Bitcoin mining pool is fairly straightforward when you're operating at a small scale. Miners connect to the pool, the pool sends them work, miners submit shares, and those shares are recorded so rewards can be calculated.

The engineering challenge changes once the pool starts getting large.

At 1 exahash per second (EH/s), the problem isn't simply adding more servers. You have to keep a constant stream of miner connections alive, distribute work, receive and validate shares, maintain accurate accounting, monitor the system, and handle payouts. All of that has to keep working as the number of miners and the value represented by every accepted share continue to grow.

That's the problem We've had to solve at Nomium. Getting a big number onto a hashrate dashboard is one thing. Keeping the system reliable while everything around that number keeps growing is another.

The Real Scaling Problem Is Not Hashrate

It's tempting to think about mining-pool scalability in simple terms: add servers, add bandwidth, add capacity.

But a mining pool isn't just a collection of servers. Every miner needs a reliable communication path to the pool. The pool has to distribute valid mining jobs, receive shares, validate them, record the accounting data, and keep balances accurate.