Stratum V2

What Is Stratum V2?

Stratum V2 (SV2) is an open-source Bitcoin mining communication protocol designed to replace the original Stratum protocol (V1), which has been the standard for pooled mining since 2012. Where V1 uses unencrypted, JSON-based messages, V2 introduces encrypted binary framing, authenticated connections, and a mechanism for miners to build their own block templates rather than accepting whatever the pool operator provides.

The protocol was initially specified in November 2019 by Jan Capek, Pavel Moravec (co-founders of Braiins, the company behind the original Slush Pool), and Matt Corallo. It draws on ideas from Corallo's earlier BetterHash proposal (2018) and addresses long-standing concerns about how pooled mining concentrates power over transaction selection in the hands of a few operators.

The full specification is maintained independently at the stratum-mining/sv2-spec GitHub repository and comprises 11 documents covering protocol security, message types, and each sub-protocol in detail.

How It Works

Stratum V2 organizes communication into three sub-protocols, each handling a distinct part of the mining workflow. In the simplest configuration, only the Mining Protocol is required. The other two unlock transaction selection by miners.

Mining Protocol

The Mining Protocol is the direct successor to V1. It distributes work to mining devices and collects proof-of-work results. Messages use a compact binary format with 6-byte headers containing the extension type, message type, and payload length. This replaces V1's verbose JSON encoding, reducing bandwidth by approximately 60% for pools and 70% for miners.

Block-switching latency drops from roughly 325 milliseconds under V1 to about 1.4 milliseconds under V2: a 229x improvement. Faster job delivery means miners spend less time working on stale templates, reducing wasted hashrate and improving fee capture per block.

Job Declaration Protocol

The Job Declaration Protocol is V2's most consequential addition. It allows a miner (or mining farm) to run their own Bitcoin node, construct a custom block template from mempool transactions, and declare that template to the pool. The pool validates that the coinbase transaction is correct (so payouts are handled properly) but cannot reject a valid template based on which transactions it includes.

This reverses a centralization dynamic that has persisted since pooled mining became dominant. Under V1, the pool operator alone decides which transactions appear in every block the pool's miners work on. Under V2 with Job Declaration, each miner can independently include or exclude transactions, restoring the censorship-resistant properties of solo mining while retaining the payout smoothing benefits of a pool.

Template Distribution Protocol

The Template Distribution Protocol connects Job Declarators and pools to Template Providers (typically Bitcoin Core nodes). It replaces the older getblocktemplate RPC (BIP 22 and BIP 23) with a push-based API that delivers template updates at more appropriate times: for example, immediately when a high-fee transaction arrives in the mempool, rather than waiting for the next polling interval.

Protocol Architecture

The protocol defines five operational roles that can be composed in different configurations:

• Mining Devices: ASICs or other hardware performing proof-of-work
• Pool Services: coordinate work distribution and payout calculations
• Mining Proxies: aggregate connections from many devices, reducing the connection load on pools
• Job Declarators: client and server components that bridge Template Providers and pools
• Template Providers: generate block templates, typically a Bitcoin Core node running on the miner's own infrastructure

A small solo miner can run a minimal setup with just a Mining Device and Pool Service. A large farm can deploy proxies and Job Declarators to aggregate thousands of devices while constructing its own templates from a local Bitcoin Core node.

Security Improvements

V1's plaintext JSON traffic is vulnerable to several attacks that V2 eliminates through mandatory encryption.

Encrypted Connections

Every V2 connection is encrypted using the Noise Protocol Framework with the handshake pattern: Noise_NX_Secp256k1+EllSwift_ChaChaPoly_SHA256. The AEAD cipher (IETF ChaCha20-Poly1305) provides both confidentiality and integrity, with a 16-byte MAC on every message.

Authentication uses a lightweight certificate scheme: servers present certificates containing their static public key, validity timestamps, and a 64-byte Schnorr signature (BIP 340) from the pool authority. No x509 certificates or certificate authorities are needed.

Hashrate Hijacking Prevention

Under V1, anyone controlling a network path between a miner and pool (an ISP, a BGP hijacker, or a compromised router) can silently redirect shares to a different pool. Because V1 traffic is unencrypted, the attacker simply rewrites the destination. V2's AEAD encryption makes this impossible: an attacker cannot decrypt traffic, modify shares in transit, or impersonate a pool without possessing its private key.

Miner Privacy

V1's plaintext traffic lets adversaries estimate a miner's performance by observing share submission patterns. V2 encryption prevents this passive surveillance, protecting operational details from competitors and potential attackers.

Why It Matters

The core issue Stratum V2 addresses is mining pool centralization of block construction. Under V1, a handful of large pools collectively control over 90% of hashrate, and each pool operator unilaterally decides which transactions appear in the blocks their miners produce. This creates a narrow chokepoint: pressuring just a few pool operators could effectively censor transactions across most of the network.

V2's Job Declaration Protocol distributes this power across thousands of individual miners, each running their own node and selecting their own transactions. Even if a pool operator wanted to exclude certain transactions, miners using Job Declaration would continue including them. This matters for preserving Bitcoin's censorship resistance as the network matures and regulatory pressure on large pools increases.

For a deeper analysis of how block template construction affects mining centralization, see the research article on Stratum V2 and mining decentralization and the broader examination of block template centralization risks.

Adoption Status

The Stratum Reference Implementation (SRI), written in Rust, reached its v1.0.0 release in March 2024. The SRI working group was established in October 2022 by Braiins and Spiral (a subsidiary of Block, Inc.) and is supported by BitMEX, Foundry, Galaxy Digital, the Human Rights Foundation, and OpenSats.

Adoption milestones as of mid-2026 include:

• Braiins Pool has supported V2 since approximately 2020, including full Job Declaration
• DEMAND Pool (DMND) launched in March 2025 as the first V2-native pool
• In June 2026, DEMAND Pool mined block 955,318 using a miner-constructed template via Job Declaration: the first documented instance of independent block template construction in a production pooled mining environment
• In May 2026, seven major pools representing approximately 75% of global hashrate joined the Stratum V2 Working Group, including Foundry, Antpool, F2Pool, SpiderPool, MARA Pool, Block Inc., and DMND

The SRI includes a Translation Proxy (tProxy) that bridges V1 mining devices to V2 pools, allowing existing hardware to benefit from V2's encryption and efficiency without firmware updates. This backward compatibility has been a key driver of adoption, since the global fleet of ASICs cannot be upgraded overnight.

Use Cases

• Transaction selection sovereignty: miners running the Job Declaration Protocol can include transactions that a pool operator might otherwise filter, preserving network-level censorship resistance
• Bandwidth-constrained environments: the binary protocol's 60-70% bandwidth reduction benefits miners in regions with limited connectivity
• Hashrate security: encrypted connections prevent ISPs and network-level attackers from hijacking hashrate or eavesdropping on mining operations
• Large-scale farm optimization: Mining Proxies aggregate thousands of devices behind a single V2 connection, reducing pool-side connection overhead while the Job Declaration Protocol lets the entire farm use a single self-constructed template
• Regulatory compliance: miners in jurisdictions with specific transaction requirements can ensure their own templates comply without depending on a pool operator in a different jurisdiction

Risks and Considerations

Adoption Lag for Job Declaration

Most current V2 deployments use only the Mining Protocol, gaining encryption and performance benefits while the pool still constructs block templates. The Job Declaration Protocol requires miners to run their own Bitcoin node and manage template construction, which adds operational complexity. Until Job Declaration sees wider adoption, the decentralization benefits of V2 remain partially unrealized.

Pool Incentive Alignment

Pool operators may have economic or regulatory reasons to prefer controlling transaction selection. While V2 allows miners to declare their own templates, pools can in theory refuse to participate in Job Declaration or add friction to its use. The protocol design mitigates this by making coinbase validation the only check a pool can perform, but market dynamics and competitive pressure will ultimately determine how widely Job Declaration is supported.

Transition Complexity

Migrating from V1 to V2 involves firmware updates (or Translation Proxy deployment), pool-side infrastructure changes, and testing. The SRI's Translation Proxy helps bridge the gap, but full V2 adoption across the mining ecosystem will take time. During the transition period, some miners may run mixed V1/V2 configurations.

Specification Maturity

While the SRI reached v1.0.0 in 2024 and the specification is actively maintained, Stratum V2 is not formalized as a Bitcoin Improvement Proposal (BIP). The specification lives in its own repository and evolves through community consensus rather than the BIP process. Related BIPs include BIP 310 (Stratum V1 extensions) and BIP 340 (Schnorr signatures, used in V2's certificate scheme).

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.