Stratum Mining Protocol (v1)

Stratum v1 is the de facto standard protocol that connects mining hardware to a pool. It is a line-based dialect of JSON-RPC 2.0 carried over a plain TCP connection: each message is a single JSON object terminated by a newline, with the miner acting as client and the pool as server. It replaced the older HTTP getwork polling model with a push-based design that lets a pool feed thousands of machines new work the instant a block changes, and it remains the most widely deployed mining protocol more than a decade after its introduction.

The session lifecycle, message by message

A modern session usually opens with an optional mining.configure, where the miner negotiates protocol extensions — most importantly version rolling, requesting a version-bit mask (typically 1fffe000) it may vary in hardware. The miner then sends mining.subscribe, and the pool's reply carries two critical values: extranonce1, a per-connection prefix, and extranonce2_size, the number of bytes of private search space the miner controls. Next, mining.authorize identifies the worker (credentials are conventionally the payout identity; pools rarely check passwords). From there the pool drives: mining.set_difficulty sets the share threshold, and mining.notify pushes jobs — job ID, previous-block hash, the coinbase transaction split into two halves (the miner splices extranonce1 + extranonce2 between them), the merkle branch list, version, bits, and time, plus a clean_jobs flag that, when true, tells the miner to abandon in-flight work because a new block arrived. When hardware finds a header beating the share target, the miner returns mining.submit with worker name, job ID, extranonce2, ntime, and nonce (plus version bits if rolling is active), and the pool accepts it or rejects it with a reason.

The clever part: coinbase splicing

The protocol's efficiency comes from what it does not send. Rather than shipping complete block templates, the pool sends the coinbase in two halves and a short merkle branch. The miner rebuilds the coinbase around its own extranonce, hashes it, folds it up the branch to a fresh merkle root, and thereby manufactures unlimited distinct headers from one job without further network traffic. Difficulty adjustment is likewise adaptive: vardiff retunes each connection's share difficulty so a machine submits shares at a steady, bandwidth-friendly rate whether it is a Bitaxe or a container of S21s.

Operational realities

Day to day, most Stratum troubleshooting is about session state. A share can be rejected as stale (submitted against a job replaced by a clean_jobs notify), as a duplicate, or as low difficulty — and a rising reject percentage usually indicts the network path or a machine resubmitting old work, not the pool. Extensions negotiated at connect time matter too: mining.extranonce.subscribe lets a pool rotate a connection's extranonce1 without a reconnect, which proxies and farm controllers rely on. When a connection drops, miners reconnect and resubscribe from scratch; anything in flight is simply lost, which is why flaky links quietly tax revenue.

Strengths and structural limits

Stratum v1's simplicity made planet-scale pooled mining practical — any device that can open a TCP socket and parse JSON can mine. But the design shows its age. Traffic is unencrypted and unauthenticated, so a man-in-the-middle can hijack hashrate by rewriting messages in transit. JSON is verbose compared to a binary framing. And most fundamentally, the pool alone constructs the coinbase and selects transactions: the miner hashes whatever template it is handed, concentrating block-construction power in a handful of pool operators. Those limitations are exactly what Stratum V2 was designed to address, with encrypted binary framing and optional miner-built templates. Understanding v1's mechanics is still essential, though — it is the protocol your machines are almost certainly speaking right now, and the baseline against which every successor is measured.