Design a Crypto Mining Pool

Problem statement

Design a mining pool server that aggregates hashing power from a large population of independent miners, distributes block templates with a per-worker share difficulty, validates partial proofs of work (shares) at line rate, converts accepted shares into proportional reward credit, and pays miners when the pool finds confirmed blocks. The system must survive malicious miners, orphan blocks, node reorganizations, and denial-of-service traffic while never losing an accepted share that a miner was credited for.

A solo miner with one ASIC finds a Bitcoin block roughly once per several decades at 2025 difficulty; the variance is economically unbearable. A pool converts that lottery into a salary: miners submit shares—proofs of work against a deliberately weakened target—and the pool pays the expected value of block rewards smoothed over thousands of shares. The pool therefore owns three coupled problems at once: a real-time job distribution problem (every new block or mempool change must reach hundreds of thousands of TCP connections within a second), a high-throughput validation and accounting problem (tens of thousands of share submissions per second, each a PoW check plus dedup plus credit), and a financial ledger problem (payouts must be correct across orphans, reorgs, and fee changes).

Why this question is distinctive

Most backend designs optimize CRUD latency. A pool optimizes three different currencies: stale-share percentage (seconds of broadcast latency), share-loss rate (durability of accounting), and payout correctness (financial invariants). The miner-facing protocol is not HTTP: it is Stratum, a stateful JSON-RPC-over-TCP protocol where the server pushes mining.notify jobs and the client pushes mining.submit shares, with per-connection extra-nonce space and per-worker variable difficulty. Getting the stateful connection tier, the stateless validation tier, and the durable accounting tier to disagree safely is the core of the answer.

Public operating baseline versus design assumptions

Public trackers such as mempool.space and Hashrate Index reported Bitcoin network hashrate in the several-hundred-exahash range during 2024-2026, with the top three pools (Foundry USA, AntPool, F2Pool) collectively composing a majority of observed blocks; Foundry alone has been observed above 30% of blocks in multiple windows. Block subsidy is 3.125 BTC after the April 2024 halving, plus fees. These are cited public signals. For capacity planning this answer explicitly assumes a pool holding 18% of a 900 EH/s network (about 162 EH/s, about 26 blocks/day), 250,000 concurrently connected workers, and a variable-difficulty target of one share per five seconds per worker. Every uncited number below is a stated assumption, budget, or target.