What Is Stratum? The Language Miners and Pools Speak

The Problem Before Stratum

Imagine you work at a factory, and every 10 seconds you have to walk over to your boss’s office, knock on the door, and ask: “Hey, got any new work for me?” Most of the time, the answer is “No, same as before.” You just wasted a trip. Now imagine 10,000 workers all doing this simultaneously. That is essentially what Bitcoin mining looked like before the Stratum protocol.

In the early days of Bitcoin mining (2009-2012), miners communicated with pools using a protocol called getwork. It was simple and it worked — at first. But as mining grew from a handful of hobbyists to an industrial-scale operation, getwork’s design became a serious bottleneck.

How getwork Worked (and Why It Was Painful)

The getwork protocol operated over HTTP — the same protocol your web browser uses to load pages. Every time a miner needed new work, it sent an HTTP request to the pool, and the pool responded with a block header to hash. This is called polling: the miner constantly asks the server “anything new?”

Here is what a typical getwork cycle looked like:

1. Miner sends HTTP GET request to pool
2. Pool responds with a 128-byte block header
3. Miner iterates through the 4-byte nonce space (about 4 billion possibilities)
4. If no valid share found, miner asks for new work again
5. Repeat forever

This created several problems:

Bandwidth waste. Every request and response carried full HTTP headers — cookies, content-type, connection info — adding hundreds of bytes of overhead to what should be a tiny exchange. When you have thousands of miners polling every few seconds, that overhead adds up fast.

Nonce space exhaustion. The 4-byte nonce gives you roughly 4.3 billion hashes to try. That sounds like a lot, but even in 2011, GPUs could exhaust this space in under a second. Miners had to request new work multiple times per second, hammering the pool server with HTTP requests.

No server push. This is the biggest problem. When a new block was found on the Bitcoin network, miners needed to stop working immediately (their current work was now stale). But with getwork, the pool had no way to tell the miners. It had to wait for each miner to poll again. Those wasted seconds meant wasted electricity and lost revenue.

Scalability nightmare. HTTP is a heavy protocol. Each request opens a connection, sends headers, receives a response, and closes the connection (or keeps it alive with overhead). Pools were struggling to handle tens of thousands of polling clients.

Note

There was an intermediate protocol called getblocktemplate (GBT) that tried to fix some of these issues. It gave miners more control over block construction, but it still used HTTP polling and never saw wide adoption for pool mining.

Enter Stratum: The Protocol That Fixed Everything

In 2012, Marek Palatinus (known online as “slush”) — the same person who created the world’s first mining pool, Slush Pool (now Braiins Pool) — designed the Stratum protocol. He understood the problems because he was living them daily, running a pool that served thousands of miners.

Stratum’s design philosophy was simple: stop polling, start pushing.

The Key Design Decisions

1. Raw TCP Instead of HTTP

Stratum ditches HTTP entirely and uses a raw TCP connection. Think of HTTP like sending a formal letter through the postal service — there is an envelope, a return address, stamps, and a bunch of ceremonial overhead. TCP is like picking up a phone and keeping the line open. You just talk directly.

The miner connects to the pool once, and that TCP connection stays open for the entire mining session. No repeated handshakes, no HTTP headers, no wasted overhead.

2. JSON-RPC for Messages

While the transport layer is raw TCP, the messages themselves are formatted as JSON-RPC (JavaScript Object Notation - Remote Procedure Call). This is a lightweight standard for encoding method calls and responses. Each message is a single line of JSON text, terminated by a newline character (\n).

Here is what a Stratum message looks like:

{"id": 1, "method": "mining.subscribe", "params": ["my-miner/1.0"]}

Compact, human-readable, and easy to parse. Compare that to the bloated HTTP request that getwork required.

3. Push-Based Architecture

This is the game-changer. Instead of miners asking “got anything new?”, the pool pushes new work to miners whenever it is available. When a new block is found on the network, the pool immediately sends a notification to every connected miner: “Drop what you are doing, here is new work.”

Going back to our factory analogy: Stratum is like your boss calling you on an intercom when there is new work, instead of you walking to their office every 10 seconds to ask.

4. Line-Delimited Protocol

Each JSON message is exactly one line, terminated by \n. This makes parsing trivial — you read bytes from the TCP socket until you hit a newline, and that is one complete message. No need to track content-length headers or deal with chunked encoding.

{"id":1,"method":"mining.subscribe","params":["miner/1.0"]}\n
{"id":2,"method":"mining.authorize","params":["worker1","pass"]}\n

The Stratum Conversation

Here is a simplified view of what happens when a miner connects to a pool using Stratum:

Miner                          Pool
  |                              |
  |--- TCP Connect ------------->|
  |                              |
  |--- mining.subscribe -------->|
  |<-- subscription result ------|
  |                              |
  |--- mining.authorize -------->|
  |<-- authorization result -----|
  |                              |
  |<-- mining.set_difficulty ----|
  |<-- mining.notify (new job) --|
  |                              |
  |    [miner starts hashing]    |
  |                              |
  |--- mining.submit (share) --->|
  |<-- submit result ------------|
  |                              |
  |<-- mining.notify (new job) --|
  |    [cycle continues...]      |

Notice the flow: the miner initiates the connection and authenticates, but after that, the pool drives the conversation. The pool pushes new jobs and difficulty adjustments. The miner only speaks when it finds a valid share to submit.

What Makes Stratum So Efficient

Let us put some numbers on the improvement:

Aspect	getwork	Stratum
Transport	HTTP (heavy headers)	Raw TCP (minimal overhead)
Connection	New request each time	Single persistent connection
Work delivery	Miner polls (pull)	Pool pushes (push)
New block notification	Wait for next poll	Instant push
Nonce space	4 bytes (limited)	Extended via extraNonce
Bandwidth per job	~1 KB+ (HTTP overhead)	~200-300 bytes
Messages	Text over HTTP	Line-delimited JSON over TCP

The extraNonce Solution

Remember the nonce exhaustion problem? Stratum solved this elegantly. Instead of just a 4-byte nonce in the block header, Stratum introduced the concept of extraNonce — additional nonce space embedded in the coinbase transaction.

The pool assigns each miner a unique extraNonce1 value and tells the miner how many bytes of extraNonce2 it can iterate. Combined with the 4-byte header nonce, this gives each miner a vast search space. A miner with a 4-byte extraNonce2 has 4.3 billion times 4.3 billion possibilities before needing new work — far more than any ASIC can exhaust before the next job arrives.

Tip

The extraNonce concept is critical for modern mining. We will explore it in detail in the article on mining.subscribe and mining.authorize.

JSON-RPC: The Language of Stratum

Every Stratum message follows the JSON-RPC 2.0 format (though Stratum technically uses a slightly simplified version). There are three types of messages:

Requests (from either side)

{
  "id": 1,
  "method": "mining.subscribe",
  "params": ["user-agent/version"]
}

• id: A unique number to match responses to requests. The sender picks any integer.
• method: The procedure being called (like a function name).
• params: An array of arguments for that method.

Responses

{
  "id": 1,
  "result": [/* success data */],
  "error": null
}

• id: Matches the request that triggered this response.
• result: The return value if successful (null on error).
• error: Error details if something went wrong (null on success).

Notifications (no response expected)

{
  "id": null,
  "method": "mining.notify",
  "params": [/* job data */]
}

• id: Always null for notifications — the sender does not expect a reply.
• These are fire-and-forget messages, typically from pool to miner.

Caution

Stratum uses id: null for notifications, not id: 0. Some buggy implementations confuse these, which can cause issues. A well-behaved miner should never send a response to a message with id: null.

Why Stratum Became the Standard

By 2013, virtually every mining pool had adopted Stratum. This was not because of some industry committee or formal standardization process. It won for the same reason most good protocols win: it was simple, efficient, and solved real problems.

Several factors cemented its dominance:

1. Open specification. Marek published the protocol specification openly, and anyone could implement it. There was no licensing, no gatekeeping.

2. Easy to implement. Parsing line-delimited JSON over TCP is something any programmer can do in a few hours. Pool software and mining firmware quickly adopted it.

3. Battle-tested at scale. Slush Pool was one of the largest pools, so the protocol was proven under real-world load before others even started adopting it.

4. Compatible with evolving hardware. As miners went from CPUs to GPUs to FPGAs to ASICs, Stratum’s design (especially extraNonce) handled the increasing hash rates gracefully.

5. Low bandwidth. For mining farms in remote locations with limited internet connectivity, Stratum’s efficiency was a significant advantage over getwork.

Stratum’s Limitations

No protocol is perfect, and after more than a decade of service, Stratum V1’s limitations have become apparent:

No encryption. All Stratum V1 traffic is plaintext JSON over TCP. Anyone who can observe the network traffic (ISPs, network administrators, governments) can see exactly what you are mining, your worker names, and your hashrate. This is a privacy and security concern.

Pool controls the block template. In Stratum V1, the pool decides which transactions go into the block. Miners are just hashing whatever the pool gives them. This gives pools outsized influence over transaction selection, which is not great for Bitcoin’s decentralization.

JSON overhead. While much better than HTTP, JSON is still a text format. The same information could be encoded in binary using far fewer bytes. For large mining farms with thousands of ASICs, this overhead is not negligible.

No authentication of the pool. A miner has no cryptographic way to verify it is actually talking to the pool it thinks it is connecting to. Man-in-the-middle attacks can redirect hashrate without the miner or pool knowing.

These problems led to the development of Stratum V2, which we will cover in the final article of this series.

Summary

The Stratum protocol transformed Bitcoin mining communication from an inefficient, poll-based HTTP system into a streamlined, push-based TCP protocol. Created in 2012 by Marek Palatinus, it solved the critical problems of bandwidth waste, nonce space exhaustion, and delayed block notifications that plagued the earlier getwork protocol.

At its core, Stratum is beautifully simple: a persistent TCP connection carrying line-delimited JSON-RPC messages, where the pool pushes work to miners and miners submit shares back. This simplicity is exactly why it has been the industry standard for over a decade.

In the next article, we will walk through the complete connection lifecycle — from the moment a miner opens a TCP socket to the steady-state loop of receiving jobs and submitting shares.