Stratum Protocol

What Is the Stratum Protocol?

The Stratum protocol is the communication standard used between Bitcoin mining hardware and mining pools. When a miner connects to a pool, Stratum defines how the pool distributes work, how the miner submits proof of completed hashing (shares), and how both sides coordinate to produce valid Bitcoin blocks.

Created by Marek "Slush" Palatinus (founder of Slush Pool, the first Bitcoin mining pool) in 2012, Stratum V1 replaced the earlier getwork protocol that could not scale with exponentially growing hashrate. Stratum V1 introduced persistent TCP connections and server-pushed work assignments, becoming the universal mining protocol for over a decade. However, it was never formalized as a BIP and carried significant limitations around security and centralization.

Stratum V2, specified in 2019 by Jan Čapek, Pavel Moravec (Braiins co-founders), and Matt Corallo, addresses these limitations with encryption, bandwidth optimization, and the ability for miners to select their own transactions. As of May 2026, pools representing approximately 75% of global hashrate have joined the Stratum V2 Working Group, signaling the industry's shift toward the new standard.

How Stratum V1 Works

Stratum V1 uses JSON-RPC messages over a persistent TCP connection. Unlike the older getwork HTTP polling approach, the pool pushes new work to miners as soon as a new block is found or transactions change. The protocol involves a simple handshake followed by continuous work distribution:

1. The miner opens a TCP connection and sends mining.subscribe to initiate the session
2. The pool responds with a unique ExtraNonce1 value and the ExtraNonce2 size for that connection
3. The miner authenticates with mining.authorize using a worker name and password
4. The pool sends mining.notify messages containing job data: the previous block hash, coinbase transaction parts, Merkle branches, block version, difficulty target (nBits), and timestamp
5. The miner hashes candidate blocks by iterating through nonce values and ExtraNonce2 combinations
6. When the miner finds a hash below the share difficulty, it submits the result via mining.submit

Example V1 Messages

A typical Stratum V1 session begins with subscription and authorization, followed by continuous work notifications:

// Miner subscribes to the pool
{"id": 1, "method": "mining.subscribe", "params": ["miner/1.0"]}

// Pool responds with ExtraNonce1 and ExtraNonce2 size
{"id": 1, "result": [["mining.notify", "ae6"], "08000002", 4]}

// Miner authenticates
{"id": 2, "method": "mining.authorize", "params": ["worker1", "pass"]}

// Pool pushes work
{"method": "mining.notify", "params": [
  "job_id", "prev_hash", "coinbase1", "coinbase2",
  ["merkle_branch_1", "merkle_branch_2"],
  "00000002", "1c2ac4af", "504e86b9", false
]}

// Miner submits a valid share
{"id": 3, "method": "mining.submit", "params": [
  "worker1", "job_id", "00000001", "504e86ed", "b2957c02"
]}

Limitations of V1

Despite its decade-long dominance, Stratum V1 has critical weaknesses:

• No encryption: all communication is plaintext JSON, making connections vulnerable to man-in-the-middle attacks and hashrate hijacking, where an attacker intercepts the connection and redirects mining rewards to their own address
• Pool-controlled block templates: miners receive pre-built work from the pool and have no ability to choose which transactions go into the blocks they mine, concentrating transaction selection power in a few large pool operators
• Bandwidth inefficiency: JSON text encoding wastes bandwidth compared to binary formats, particularly significant for mining farms with thousands of devices
• No formal specification: V1 was never documented as an official standard, leading to inconsistencies across implementations

How Stratum V2 Works

Stratum V2 is a complete redesign built around three sub-protocols, each handling a distinct aspect of the mining workflow. Together, they address every major limitation of V1 while introducing new capabilities for decentralized block construction.

Mining Protocol

The Mining Protocol is the direct successor to Stratum V1 and handles the core work distribution and share submission flow. It uses a compact binary message format with a 6-byte header (extension type, message type, and message length) instead of JSON text. This binary encoding reduces bandwidth usage by approximately 50-70% compared to V1.

The protocol supports channel multiplexing: multiple logical mining channels over a single TCP connection. This allows a mining proxy to aggregate hundreds of ASIC miners behind a single upstream connection to the pool, reducing connection overhead significantly.

Job Declaration Protocol

This is the most significant addition in V2. The Job Declaration Protocol enables miners to construct their own block templates, selecting transactions from their local mempool rather than accepting whatever the pool dictates. A miner runs their own Bitcoin node, builds a candidate block, and declares it to the pool for validation.

A single job declaration can be reused across an entire mining farm (hundreds of thousands of devices), keeping computational overhead low. The protocol is separated from share submissions, allowing distinct rate-limiting and validation requirements for each.

Template Distribution Protocol

The Template Distribution Protocol replaces Bitcoin Core's getblocktemplate RPC with a more efficient push-based mechanism. It handles communication between Job Declarators and Template Providers (typically a local Bitcoin Core node), ensuring miners receive new block template data as quickly as possible when new transactions arrive or a block is found.

Encryption and Security

All remote Stratum V2 connections use mandatory encryption based on the Noise Protocol Framework: the same cryptographic foundation used by WireGuard and the Lightning Network. The implementation uses the Noise_NX handshake pattern with Elliptic Curve Diffie-Hellman key exchange on secp256k1, authenticated using Schnorr signatures per BIP-340.

Post-handshake, all traffic is encrypted with ChaCha20-Poly1305 (IETF variant) as the default AEAD cipher, with AES-256-GCM as an alternative. This eliminates hashrate hijacking entirely and prevents ISPs or network attackers from observing or tampering with mining traffic.

Why Stratum V2 Matters for Decentralization

Under Stratum V1, a handful of large pool operators control which transactions get included in Bitcoin blocks. When a single pool commands over 30% of global hashrate, that operator effectively decides transaction ordering for roughly a third of all blocks. This creates a centralization pressure point: a pool could theoretically censor transactions, be compelled to do so by regulators, or be compromised by an attacker.

Stratum V2's Job Declaration Protocol shifts this power back to individual miners. Each miner (or mining farm) can run their own Bitcoin node, select transactions from their own mempool, and construct blocks according to their own policies. The pool's role becomes validating shares and distributing rewards rather than dictating block content.

This architectural change is particularly relevant as Bitcoin's block subsidy continues to decline through successive halvings. As difficulty adjustments and fee market dynamics make transaction selection increasingly important for miner revenue, controlling which transactions to include becomes a more consequential decision. Stratum V2 ensures that decision remains distributed across thousands of independent operators rather than concentrated in a few pools.

Adoption and Migration

The transition from Stratum V1 to V2 is underway but gradual. Key milestones include:

• Braiins Pool operates with full Stratum V2 support, including the Job Declaration Protocol, making it the pioneer production deployment
• DEMAND (DMND), launched in 2025, is the first mining pool built entirely on the Stratum Reference Implementation (SRI) codebase
• In May 2026, seven major pools (Foundry, AntPool, F2Pool, SpiderPool, MARA Foundation, Block Inc., and DMND) joined the Stratum V2 Working Group, representing approximately 75% of global hashrate
• Auradine shipped the first ASIC miner with native Stratum V2 support via their FluxOS firmware

The Stratum Reference Implementation

The Stratum Reference Implementation (SRI) is an open-source, Rust-based implementation of the full Stratum V2 protocol suite. SRI 1.0.0 was released in March 2024, and development is funded by OpenSats, the Human Rights Foundation, and Spiral (Block). The project provides:

• An SV2 Pool and Mining Proxy for pool operators adopting V2
• A Translation Proxy that accepts V1 connections from existing ASIC firmware and speaks V2 upstream: this allows miners to benefit from V2 encryption without upgrading their device firmware
• Job Declarator Client and Server components for miners who want to select their own transactions

The Translation Proxy is particularly important for the transition period. Miners can run it on modest hardware (even a Raspberry Pi) and immediately gain encrypted communication with V2-compatible pools, using their existing mining equipment with stock V1 firmware. For more context on the economics of mining infrastructure, see the Bitcoin mining economics overview.

Use Cases

• Large-scale mining operations use Stratum V2's binary protocol and channel multiplexing to reduce bandwidth consumption across farms with thousands of devices
• Miners in regions with restrictive network policies benefit from encrypted connections that prevent ISPs from identifying, throttling, or intercepting mining traffic
• Mining operations concerned about regulatory pressure on transaction censorship can run their own Bitcoin nodes and use the Job Declaration Protocol to maintain independent transaction selection
• Home miners and smaller operations use the SRI Translation Proxy to add encryption to existing V1-only ASIC hardware without firmware modifications

Risks and Considerations

Migration Complexity

Transitioning from V1 to V2 requires coordination across pools, firmware vendors, and mining operators. While the Translation Proxy eases the path for individual miners, full V2 adoption (including Job Declaration) requires miners to run their own Bitcoin nodes and manage template construction: a significant operational addition for smaller operations.

Job Declaration Adoption

Even among miners using Stratum V2 connections, actual use of the Job Declaration Protocol (miner-chosen transactions) remains limited. Many miners prefer the simplicity of pool-assigned templates, and the infrastructure required to run a full node and construct competitive templates adds overhead. As of mid-2026, job declaration usage is estimated below 10% of V2-connected hashrate.

Firmware Fragmentation

Native V2 support in ASIC firmware is still uncommon. Most mining devices ship with V1-only firmware, requiring either third-party firmware (like Braiins OS+) or a Translation Proxy. Until major manufacturers include V2 support in stock firmware, the Translation Proxy remains a necessary bridge for most miners.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.