Stratum V2: How a New Mining Protocol Returns Block Construction to Miners

Bitcoin's security model assumes that no single entity controls which transactions make it into blocks. In practice, a handful of mining pool operators build every block template on the network. The miners contributing hashrate have no say in transaction selection: they receive a template, hash it, and submit shares. Stratum V2 is the protocol upgrade designed to change that by letting individual miners propose their own block templates, encrypted over the wire and negotiated directly with the pool.

This article covers why the original Stratum protocol centralizes block construction, how V2's three sub-protocols fix the problem, what adoption looks like as of mid-2026, and why decentralized block construction matters for every layer of the Bitcoin stack.

How Stratum V1 Created a Centralization Bottleneck

The original Stratum protocol (V1), introduced in 2012 by Slush Pool (now Braiins Pool), replaced the earlier getblocktemplate RPC with a lightweight JSON-RPC interface that made pooled mining practical at scale. It worked: V1 became the de facto standard for virtually all pooled mining within a few years. But its design made assumptions that consolidated power in pool operators.

Pool-Controlled Block Templates

Under V1, the pool runs a Bitcoin full node, selects transactions from the mempool, constructs the block template, and distributes it to connected miners. The miner's job is limited to iterating nonces and submitting valid proof-of-work shares. Miners never see the full transaction list and have no mechanism to influence which transactions the pool includes or excludes.

This means a pool operator can unilaterally filter transactions by sender address, exclude transactions below a certain fee threshold, or comply with government blacklists. The miners providing the hashrate that secures the network have zero visibility into these decisions.

Plaintext Communication and Hashrate Hijacking

V1 transmits all data as plaintext JSON over TCP. There is no encryption, no authentication, and no integrity verification. Any network-level attacker positioned between a miner and its pool (an ISP, a state-level adversary, a compromised router) can read every message, modify share submissions, or silently redirect hashrate to a different pool entirely.

Research published by Hashlabs in 2025 confirmed that hashrate hijacking via V1's plaintext protocol is an active attack vector exploited in production environments, with typical losses of up to 2% of a facility's hashrate before detection.

The concentration problem: As of mid-2026, the top four mining pools (Foundry USA, AntPool, F2Pool, and SpiderPool) collectively produce roughly 70% of all Bitcoin blocks. Under Stratum V1, these four operators decide which transactions appear in the majority of Bitcoin's block space.

What Stratum V2 Changes

Stratum V2 is a ground-up redesign of the mining communication protocol, specified and maintained by the Stratum V2 Working Group. The specification comprises ten documents covering protocol security, message types, and sub-protocol definitions, all maintained in the open sv2-spec repository. V1 and V2 are wire-incompatible: the new protocol uses a binary framing format and mandatory encryption, making it impossible for a V1 client to connect to a V2 endpoint without a translation proxy.

The protocol is structured around three sub-protocols, each addressing a distinct part of the mining communication flow.

Mining Protocol

The core sub-protocol handles share submission, difficulty adjustment, and channel management between miners and pools. It replaces V1's JSON-RPC messages with a compact binary format that reduces bandwidth by approximately 70%. Job delivery targets under 2.5 milliseconds, compared to roughly 228 milliseconds under V1. For large-scale mining operations processing thousands of shares per second, this efficiency gain translates directly to reduced stale share rates and higher effective hashrate.

Template Distribution Protocol

The Template Distribution Protocol (TDP) replaces the legacy getblocktemplate RPC with a push-based mechanism for distributing block templates and transaction data from Bitcoin Core to mining infrastructure. Instead of polling a node for new templates, the TDP pushes updates as soon as the mempool changes or a new block arrives. This reduces the latency between a high-fee transaction entering the mempool and the miner working on a template that includes it.

Job Negotiation Protocol

This is the sub-protocol that fundamentally shifts power from pools to miners. Job Negotiation allows a miner running its own full node to construct a block template locally, propose it to the pool, and receive authorization to mine against that template. The pool validates that the proposed template includes a correct coinbase output for reward distribution but does not control which transactions the miner selected.

How Job Negotiation Works

The Job Negotiation flow is what makes Stratum V2 a decentralization protocol rather than merely a performance upgrade. Here is the step-by-step process:

1. The miner runs a Bitcoin full node and maintains its own copy of the mempool. It selects transactions according to its own policies: highest fee, smallest size, or any other criteria the operator chooses.
2. The miner constructs a complete block template locally, including the selected transactions, the block header, and the Merkle tree.
3. The miner submits this template to the pool via the Job Negotiation Protocol.
4. The pool validates the template. It checks that the coinbase transaction allocates the correct share of the block subsidy and fees to the pool's reward address. It does not modify the transaction list.
5. The pool sends back a job identifier authorizing the miner to hash against this template.
6. The miner finds a valid proof-of-work and submits the share. If the share meets the network difficulty target, the pool propagates the block to the Bitcoin peer-to-peer network.

Pool fallback: If a miner does not run a full node or does not participate in Job Negotiation, the pool falls back to providing its own templates. V2 is backwards-compatible in this sense: it works without Job Negotiation, but the decentralization benefits only materialize when miners opt in.

Stratum V1 vs V2: Feature Comparison

Encryption Under the Hood

Stratum V2 uses the Noise Protocol Framework with the specific cipher suite Noise_NX_Secp256k1+EllSwift_ChaChaPoly_SHA256. The choice of cryptographic primitives is deliberate: secp256k1 for key exchange, ChaChaPoly (IETF ChaCha20-Poly1305) for authenticated encryption, and SHA-256 for hashing are all primitives already present in Bitcoin Core. This minimizes the new cryptographic surface area that implementations must audit.

Authentication uses a two-level PKI where pool servers present certificates containing static public keys, signed with 64-byte Schnorr signatures (BIP 340) from the pool's authority key. Every message carries a 16-byte MAC, providing both confidentiality and integrity. A network attacker cannot decrypt V2 traffic, modify shares in transit, or impersonate a pool without possessing the pool's private key.

Adoption: Who Supports Stratum V2 Today

Pools

As of mid-2026, two pools run Stratum V2 in production: Braiins Pool (the protocol's originator, formerly Slush Pool) and DEMAND Pool (DMND), which launched in November 2025 as the first V2-native pool. DMND and GoMining jointly mined the first known Stratum V2 Job Declaration block, demonstrating end-to-end miner-constructed templates on mainnet.

A significant inflection point came in May 2026, when seven major pools representing approximately 75% of global Bitcoin hashrate joined the Stratum V2 Working Group: Foundry USA, AntPool, F2Pool, SpiderPool, MARA Pool, Block Inc., and DMND. While most of these pools are still in testing and integration phases rather than production deployment, the commitment signals that V2 is moving from niche to industry standard.

Firmware and Hardware

BraiinsOS+ remains the most mature option for direct V2 pool connections without intermediaries. Miners running stock Bitmain firmware can still reach V2 pools through the SRI Translation Proxy, which sits between the ASIC and the pool, translating V1 messages into V2 and handling encryption on the miner's behalf.

The Stratum Reference Implementation

The Stratum Reference Implementation (SRI) is the fully open-source, community-maintained implementation of the V2 protocol. Version 1.0.0 shipped as a production-ready milestone in 2024, and the project has seen regular updates through 2026. SRI provides the Translation Proxy (for connecting V1 hardware to V2 pools), a Job Negotiator module, and pool-side components that operators can deploy directly.

The SRI working group projects that by the end of 2026, V2 will be the default protocol for new ASIC firmware shipments, potentially reaching 40% to 60% of network hashrate. Development decisions are made via open consensus through weekly calls, a public Discord, and the GitHub repository.

Ocean Mining and the DATUM Alternative

Ocean Mining pursues the same goal of decentralized block construction through a different mechanism called DATUM (Decentralized Alternative Templates for Universal Mining). Rather than adopting V2's Job Negotiation sub-protocol, DATUM layers decentralized template selection on top of the existing V1 protocol, maintaining compatibility with standard mining firmware without requiring V2 support.

With DATUM, the miner runs a full Bitcoin node alongside a DATUM Gateway, constructs block templates locally from its own mempool, and submits work to Ocean for reward coordination and variance reduction. Ocean validated the approach by mining its first DATUM block on September 30, 2024. The DATUM Gateway is open-source, allowing any pool to adopt the same model.

The V2 and DATUM approaches are philosophically aligned but technically distinct. V2 requires protocol-level changes (new wire format, new firmware or proxy), while DATUM works with existing V1 infrastructure. Both return transaction selection authority to the individual miner.

Why Block Construction Decentralization Matters

Censorship Resistance at the Base Layer

The most direct consequence of pool-controlled block construction is that it creates a chokepoint for censorship. If a government or regulator pressures the operators of the top five pools to exclude certain transactions (sanctioned addresses, privacy-enhancing transactions, specific protocol interactions), they can comply without their miners even knowing.

This is not theoretical. In March 2021, Marathon Digital Holdings announced it would direct hashrate to an "OFAC-compliant" mining pool using DMG's Walletscore surveillance software. Marathon mined its first filtered block (block 682,170) on May 5, 2021, excluding transactions associated with addresses on the U.S. Treasury Department's SDN list. Community backlash was swift: analysis showed the censored block contained fewer transaction fees than standard blocks, and critics argued the experiment undermined Bitcoin's permissionless design. Marathon reversed course within a month, committing to validate transactions identically to all other miners.

Under Stratum V2 with Job Negotiation, this kind of pool-level censorship becomes technically infeasible for participating miners. Each miner constructs its own template from its own mempool. Even if a pool operator wanted to censor transactions, miners using Job Negotiation would continue including those transactions in the templates they propose. The pool cannot reject a valid template simply because it contains transactions the operator dislikes: the protocol only validates coinbase correctness, not transaction-level content.

Protecting Layer 2 Settlement Transactions

Bitcoin's censorship resistance is not just a philosophical principle. It is a functional requirement for every protocol that depends on timely on-chain settlement. Lightning force-close transactions, HTLC timeout claims, Spark unilateral exits, and justice transactions from watchtowers all rely on the assumption that a valid Bitcoin transaction will eventually be mined. If pool operators can selectively delay or exclude these transactions, the security guarantees of Layer 2 protocols degrade.

Stratum V2 strengthens the guarantee that L2 settlement transactions cannot be blocked by pool operators. When thousands of independent miners each construct their own block templates, there is no single point where an adversary can filter specific transaction types. This is particularly relevant for time-sensitive operations like penalty transactions and timelocked exits, where delays of even a few blocks can result in loss of funds.

Hashrate Distribution and Fifty-One Percent Risk

Pool-controlled block construction amplifies the risk associated with 51% attacks. When a single pool controls 30%+ of hashrate and unilaterally decides block content, the effective centralization is worse than the hashrate number suggests. The pool operator has both the hashrate and the template authority. With V2 Job Negotiation, even if a pool coordinates 30% of hashrate, the block templates come from thousands of independent miners with diverse transaction selection policies. The pool retains reward coordination but loses the ability to weaponize hashrate for censorship or selective ordering.

The Gap Between V2 Adoption and Decentralization

An important distinction: most current V2 adoption reflects encryption and performance benefits only. The majority of miners connecting via V2 are not running Job Negotiation. They get encrypted connections and faster job delivery, but the pool still constructs their block templates.

True decentralized block construction requires the miner to run a Bitcoin full node, which adds operational overhead: disk space for the blockchain, bandwidth for block propagation, and compute for mempool management. For large industrial operations, this is trivial. For smaller miners, it is a meaningful barrier. The SRI Translation Proxy lowers the firmware barrier, but the full-node requirement remains the bottleneck for Job Negotiation adoption.

With Bitcoin's network hashrate approaching 1 zettahash per second (nearly 1,000 EH/s as of May 2026), and the seven largest pools recently committing to V2, the protocol is positioned for significant growth. But the honest assessment is that decentralized block construction, as distinct from encrypted mining communication, is still in its early stages.

What Miners Need to Get Started

Miners interested in V2 have two paths depending on their hardware and goals:

1. For encrypted mining without Job Negotiation: install BraiinsOS+, LuxOS, or Vnish firmware and connect to a V2-compatible pool (Braiins Pool or DEMAND). Alternatively, run the SRI Translation Proxy with stock firmware.
2. For full decentralized block construction: run a Bitcoin full node, deploy the SRI Job Negotiator alongside the Translation Proxy, and configure the miner to propose locally constructed templates. This requires more infrastructure but delivers the censorship resistance benefits that define V2's mission.

The Stratum V2 documentation provides deployment guides for both configurations. The SRI repository includes Docker-based setups for testing before committing to production deployment.

Implications for the Broader Bitcoin Stack

Decentralized block construction reinforces the security assumptions that every layer of the Bitcoin stack depends on. When miners independently select transactions, fee market dynamics become more competitive and less susceptible to manipulation. Transaction inclusion is determined by fee rate and mempool policy across thousands of independent operators rather than the preferences of a few pool administrators.

For Layer 2 protocols like Lightning and Spark, this matters operationally. Users holding funds in off-chain constructs need confidence that their exit transactions will be mined promptly. Stratum V2 with widespread Job Negotiation adoption provides that confidence at the protocol level rather than relying on the goodwill of pool operators.

For developers building on Bitcoin's settlement layer, the Spark SDK documentation covers how unilateral exits interact with on-chain fee dynamics. For a deeper analysis of mining economics that contextualizes Stratum V2 adoption, see our Bitcoin mining economics overview.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.