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. And this isn't a workload that comes and goes. It runs continuously. When the Bitcoin network finds a new block, the pool also needs to react quickly so miners can move to current work. Stratum V2 is relevant here because its protocol design covers mining communication, job distribution, share submission, and security. Its Job Declaration Protocol also gives miners or mining farms a way to declare custom work to a pool. That makes Stratum proxy architecture just as important as raw computing capacity. What We Have Actually Had to Solve at Nomium The following are the problems that have mattered most in our own pool operations. 1. Sustaining the Write Load and Scaling Automatically At Nomium, we operate a pool that commits more than 5,000 database writes per second. None of those writes can simply disappear. Every share represents work a miner has done and, ultimately, money owed to that miner. The system also has to scale automatically as hashrate grows. I can't rely on someone noticing that capacity is getting tight and manually adding resources before the pool starts falling behind. If we get that wrong, miners can end up being underpaid for work they actually completed. That changes the way you have to think about the database. These aren't disposable analytics events that you can afford to lose. Share data feeds directly into the money owed to miners. The architecture therefore needs to handle sustained write volume while keeping the records intact. Automatic scaling matters for the same reason: mining hashrate isn't constant, and today's capacity can't depend on an operator reacting quickly enough to tomorrow's growth. 2. Multi-Region Infrastructure on a Single Rewards Database Each region runs independently with its own infrastructure, but reward calculation ultimately runs against one shared database. That creates a difficult architectural tension. The regional infrastructure needs enough independence to keep operating, while the financial side still has to agree on one source of truth. When you're dealing with money, ambiguity isn't something you can casually reconcile later. This is one of the reasons a mining pool can't be designed exactly like a conventional geographically distributed web application. A user-facing application can sometimes tolerate delayed synchronization. A rewards system has a much harder requirement: the accounting has to be right. 3. Zero-Downtime Deployment A pool can't simply be taken offline every time we release something. At Nomium, we use graceful shutdowns, rolling updates, and canary releases. The difficult part is that Stratum connections are long-lived. They're not like ordinary web requests that finish and disappear. Every miner also has a backup pool configured. If a connection drops during a deployment, that hashrate can move to the backup pool quietly, and there's no guarantee it will come back. So deployment becomes an operational problem as much as a software problem. You have to account for existing sessions, drain connections properly, handle miner failover, and understand that a miner moving to its backup pool may not automatically return. Zero downtime isn't just about keeping a load balancer green. It's about changing the system without quietly losing hashrate. 4. A Targeted DDoS Attack We've also had to deal with a targeted DDoS attack. This wasn't just background internet noise. The hosting provider's DDoS protection didn't stop it, so we had to build our own solution. Stratum runs over open TCP ports with persistent connections, which means you can't simply put the traffic behind a WAF or CDN and call it a day. At the same time, aggressive filtering isn't a great option because legitimate miners and attackers can look very similar on the wire. That's one of the less obvious differences between a mining pool and a typical web application. With a web application, you can often use HTTP request-level signals through a WAF or CDN to identify unwanted traffic. Stratum doesn't give you the same luxury. The service depends on persistent TCP connections, and legitimate mining traffic can look a lot like malicious connection activity. Protecting the pool therefore means understanding how connections actually behave and building defenses that can distinguish attacks without blocking the miners the pool is supposed to serve. 5. Reward Accuracy This is the part I take most seriously: multiple payout schemes, idempotent reward calculation across restarts, and a complete audit trail. Miners count every satoshi, and they will come back with questions when the numbers don't look right. In a normal web product, a discrepancy might be treated as a bug. In a mining pool, it affects the trust that the entire hashrate operation is built on. A pool can recover from a temporary network problem. It can replace a server. It can survive an attack. What it can't casually recover from is losing confidence in its accounting. Reward calculation therefore needs to be deterministic, repeatable, and auditable. If a process restarts, it shouldn't calculate the same reward twice. If a miner challenges a payout, the operator needs enough history to show exactly how that number was produced. At Nomium, we don't treat reward accuracy as a feature sitting alongside the mining infrastructure. It's part of the foundation of the pool. Design for Failure Instead of Assuming Uptime Large distributed systems eventually fail. Servers go down. Networks fail. Databases become unavailable. Software updates introduce bugs. The goal isn't to build a system where nothing ever fails. That's unrealistic. The goal is to make individual failures containable. A connection server should be replaceable. A database component should be recoverable. A reporting service should be able to fail without stopping mining. A payout service should be isolated from the systems responsible for accepting and recording shares. For a mining pool, that principle has a direct financial consequence: one component failing should not turn into lost shares or incorrect rewards. Security Is Part of the Pool Architecture A large mining pool is an attractive target because the infrastructure represents both significant computing activity and real financial value. Wallet infrastructure shouldn't be unnecessarily exposed to the same systems handling large numbers of miner connections. Access to funds needs to be restricted, monitored, and separated from ordinary pool infrastructure. The communication protocol matters too. Stratum V2 includes security mechanisms designed to protect communication between mining participants, including authenticated encryption. But protocol security is only one layer. The DDoS experience at Nomium reinforced something important for us: network security, connection handling, traffic filtering, deployment, and financial systems can't be treated as completely separate checkboxes. They are all part of the same security problem. Stratum V2 Is More Than a Protocol Upgrade Stratum V2 deserves attention because it's more than a cosmetic replacement for Stratum V1. The protocol defines how mining work is communicated and how shares are submitted, while its broader design addresses efficiency, security, and how responsibilities are distributed between miners and pools. Its Job Declaration Protocol is particularly interesting when you look at who controls mining work. Miners or mining farms can declare custom work to a pool, changing the traditional relationship in which the pool has more direct control over the work being distributed. For operators, that means the protocol choice can affect much more than network efficiency. It can influence the architecture of the pool and how responsibilities are divided across the mining ecosystem. The Brutal Truth About 1 EH/s It's easy to look at 1 EH/s as just another hashrate milestone. In practice, it tests almost every part of a pool. At Nomium, the hardest problems haven't been solved by simply throwing more servers at the system. They've involved sustained database writes, automatic scaling, multi-region infrastructure, a shared rewards database, deployments without losing hashrate, protection against a targeted DDoS attack, and reward calculations that have to stand up to scrutiny down to the satoshi. And these problems are connected. A miner doesn't care how elegant the underlying architecture is. They care about three things: whether they can stay connected, whether their work is being accepted, and whether they're being paid correctly. That's the real measure of a mining pool. At 1 EH/s, adding hardware is only part of the job. How the pool is built becomes just as important as how much computing power is behind it.