Stratum V2 vs V1 — The Protocol Revolution

Stratum is the protocol that connects miners to pools — and the version most of Bitcoin still runs, Stratum V1, dates to 2012. It transmits credentials in plaintext, lets the pool decide which transactions go into every block, and concentrates control that Bitcoin was designed to spread out. Stratum V2 fixes all three: end-to-end encryption, a compact binary format, and — most importantly — job negotiation, which lets individual miners build their own block templates. In May 2026, seven pools representing roughly 75% of network hashrate backed the standard, the biggest decentralization shift mining has seen in years.

Key takeaways

• V1’s core flaw is centralization: the pool builds every block template, so a handful of operators decide what goes into most Bitcoin blocks.
• V2’s killer feature is job negotiation: miners running their own node choose their own transactions, breaking the pools’ control over block content.
• Encryption matters most for home miners: V1’s plaintext enables silent hashrate hijacking on untrusted networks; V2’s Noise-protocol encryption makes it cryptographically impossible.
• 2026 was the turning point: in May, seven pools (~75% of hashrate, including Foundry and AntPool) joined the Stratum V2 working group — after years as a niche side project.
• For solo mining, the stakes are different: a non-custodial solo pool never controls your funds or your block content, so V2’s benefits are mainly encryption, latency, and future-proofing.

This article covers how Stratum works, what V2 changes, who supports it now, and the road ahead — then closes with an extended appendix on the quantum threat, because in March 2026 Google Quantum AI published research that compressed the expected timeline for when Bitcoin’s signatures might break, and the development community is now drafting post-quantum defenses (BIP-360, BIP-361, Hourglass) in response.

What Stratum actually is

Stratum is a protocol that connects two parties: the mining pool (runs Bitcoin nodes, builds block templates, distributes work, validates shares, pays rewards) and the miner (receives a block header to hash, iterates the nonce, submits results). Every Antminer, Bitaxe, and Whatsminer on the planet speaks Stratum. Without it, pools couldn’t exist — and without pools, most miners couldn’t tolerate the variance of going it alone at scale. The protocol’s job sounds simple: deliver the right work to the right miner, fast enough that nobody wastes hashpower on stale jobs. But the details — message format, encryption, and who controls block content — turn out to matter enormously.

What’s wrong with Stratum V1?

Stratum V1, created by Marek “Slush” Palatinus in 2012, is a simple JSON-RPC protocol over plain TCP: quick to implement, easy to debug. Fourteen years of context have exposed several structural problems.

1. Plaintext communication

V1 sends everything in unencrypted JSON — pool credentials, wallet address, worker name, share submissions — readable by anyone on the network path. More dangerously, plaintext enables hashrate hijacking: an attacker who controls a network segment between you and the pool can silently redirect your shares to their own pool. Braiins has documented suspected cases from miners in China, Kazakhstan, Russia, and Europe — stealing as little as 1-2% of hashrate is enough to dent profitability without being obvious to the victim.

2. Pool-controlled transaction selection

Under V1, the pool builds the block template and the miner just hashes whatever header arrives. The pool decides which transactions go in the block. Since roughly five pools control about 70% of hashpower, a handful of operators effectively decide the contents of most Bitcoin blocks. If a government pressures a pool to censor certain transactions, every miner on that pool unwittingly participates. This has happened in limited form: Marathon mined OFAC-compliant “clean” blocks in 2023 as an experiment, and miners on a filtering pool have no protocol-level way to opt out.

3. JSON overhead and connection sprawl

JSON is human-readable, which is great for debugging and wasteful for bandwidth — field names and quotes add 30-40% overhead versus a binary equivalent. And every ASIC opens its own TCP connection, so a 1,000-rig farm runs 1,000 simultaneous Stratum sessions. Invisible for one Bitaxe; measurable for a large farm.

4. No protocol-level firmware integrity

V1 can’t verify a miner is running known-good firmware. Compromised firmware can submit subtly bad shares that look valid but cost the pool money, and detection requires off-protocol auditing.

How V1 survived anyway: BIP-310

Given four structural flaws, it’s fair to ask how a 2012 protocol still carries most of Bitcoin’s hashrate. The answer is BIP-310, “Stratum protocol extensions” — an Applications-layer, Informational proposal assigned on 10 March 2018 and authored by Braiins’ Pavel Moravec and Jan Čapek, the same two people who would specify Stratum V2 the following year.

The problem BIP-310 solved was that V1 had no way to grow. Send a server a message it doesn’t recognise and many implementations simply close the connection, so there was no safe path to propose a new feature. Worse, the feature miners urgently needed — version rolling — was backwards incompatible by nature: the miner had no field in which to report a modified block version, and the server had no way to tell the miner which bits were safe to touch.

One message to negotiate them all

BIP-310’s answer was a single new message, mining.configure, which the specification says SHOULD be the first message the miner sends once the connection is established — before subscribing, before authorising. The miner advertises what it can do and asks for what it wants; the server replies with what it will actually allow, feature by feature. Each extension gets a namespace, so parameters read as version-rolling.mask, minimum-difficulty.value, and so on, and each one returns true, false, or an error string. The design goal was explicit: make it possible to add features later without adding more messages.

That single mechanism carries four extensions:

How the version mask is actually agreed

The negotiation is more subtle than “ask and receive,” and the detail explains a lot of real-world behaviour. The miner sends a mask of bits it is capable of changing; the server holds its own mask of bits it is willing to allow — some version bits must stay fixed for the block to be valid or for soft-fork signalling. The result is the intersection of the two. A miner may advertise the full 16-bit 1fffe000 range and receive back 18000000 — just two bits. That is a successful negotiation, not a failure.

Alongside the mask, the miner sends version-rolling.min-bit-count: the minimum number of bits it needs to roll efficiently in hardware. If the pool can’t grant that many, the specification is emphatic that the pool SHOULD NOT drop the connection — the miner simply runs in a degraded mode without full hashing power. That instruction is the reason a mismatched machine underperforms quietly instead of failing loudly, which is exactly the kind of behaviour that sends people hunting for a hardware fault that isn’t there.

Two more mechanics worth knowing. The server can change the mask at any point during the session with mining.set_version_mask, and the new mask takes effect immediately rather than at the next job. And once version-rolling is active, mining.submit gains a sixth parameter — version_bits, after worker name, job ID, extranonce2, ntime and nonce. The miner may only set bits the server allowed; anything outside the mask invalidates the share. The server then reconstructs the block version by taking the job’s original value for every bit outside the mask and the miner’s value for every bit inside it.

Which bits are safe to roll in the first place is a separate question, answered by a companion specification — BIP-320, referenced in BIP-310 while still an unnumbered draft. Our AsicBoost deep dive covers the bit-level mechanics and the patent history behind them.

The irony worth noticing: BIP-310 is still formally a Draft, eight years on, and it is what allowed a protocol with no encryption and no extensibility to remain viable for another decade. Stratum V2 makes the whole apparatus unnecessary — version rolling, difficulty handling, extranonce updates and device identification are part of the V2 channel model, negotiated in the handshake with no bolt-on required. The extension mechanism that saved V1 is precisely what V2 no longer needs.

What does Stratum V2 change?

Stratum V2 was designed from scratch to fix every one of these. It was first specified in November 2019 by Braiins co-founders Jan Capek and Pavel Moravec together with Bitcoin Core developer Matt Corallo; the working group was co-founded by Braiins and Spiral in 2022. The Stratum V2 Reference Implementation (SRI) has matured through 2024-2026, and Bitcoin Core v30 added experimental V2 support.

End-to-end encryption (Noise protocol)

Every V2 connection is encrypted using the Noise protocol framework — the same foundation as WireGuard VPN. After an authenticated handshake, all messages are encrypted (ChaCha20-Poly1305 or AES-256-GCM). In practice: network observers can’t see your pool, wallet, or worker; hashrate hijacking becomes cryptographically impossible; and credentials never appear in transit. Pools publish long-term public keys, and miners verify they’re talking to the legitimate pool, not a man-in-the-middle — the same security model as SSH.

Binary protocol (efficient)

V2 replaces JSON with a compact binary format: smaller messages (roughly 30% less bandwidth), faster parsing, less CPU load on both ends. For a large farm that’s real infrastructure savings; for a home miner on a constrained connection, it means jobs arrive faster and stale shares drop.

Job negotiation — the killer feature

This is what makes V2 historically important, not just technically better. Under the job negotiation protocol, miners can run their own Bitcoin full node and construct their own block templates locally — choosing which transactions to include, optimizing for the highest fees, or applying their own policies. The pool no longer dictates block content; it just validates the proof-of-work and pays for valid blocks. The pool’s role shrinks from “decision maker” to “share aggregator and PoW validator,” and the miner regains sovereignty over what their hashpower secures.

Three direct consequences: censorship resistance (a government can pressure a pool, but not the individual miners running their own templates — as long as enough hashrate negotiates its own jobs, censored transactions get included somewhere), fee optimization (miners running their own mempool can capture the highest-fee transactions, especially in busy periods), and pool decentralization (pools become commodity infrastructure, lowering the incentive to consolidate).

The bottom line: Stratum V2’s job negotiation is the most consequential mining-protocol change since SegWit. It decouples the economic function of pools (smoothing variance, paying rewards) from the censorship-sensitive function (deciding block contents) — and hands the second one back to miners.

Adoption status (mid-2026)

For most of V2’s life, adoption was thin — a niche standard backed by a few pools. As of early 2026, only an estimated 15-20% of network hashrate actually connected over V2, mostly for the encryption benefits rather than job negotiation. Then the picture changed sharply.

In May 2026, seven of the largest mining pools — Foundry, AntPool, F2Pool, SpiderPool, MARA Pool, Block Inc, and DMND — joined the Stratum V2 working group, together representing close to 75% of global hashrate. Per Hashrate Index data cited at the time, Foundry alone accounted for about 34%, AntPool ~14%, F2Pool ~11%, and SpiderPool ~10.5%. Crucially, V2 doesn’t reduce hashrate concentration — Foundry still commands the same share — but it changes who decides block content, which is the part the community actually worries about. CoinDesk called it the biggest decentralization move mining had seen in years.

The commitment is a starting line, not a finish. “Joining the working group” means backing the standard and beginning deployment — not that 75% of hashrate runs V2 job negotiation today. Most miners on V2 still accept pool-built templates and use it for encryption and efficiency. But with Foundry and AntPool on board, a protocol that sat at the margins for years suddenly has the reach to become the default.

Hardware and firmware support

This is the part of the V2 story most widely misreported, including in earlier versions of this article. V2 is a firmware capability, and as of August 2026 exactly three firmware families implement it natively.

• Braiins OS+ (26.07 recommended) — the only commercial Antminer firmware with a native V2 client, covering the S9 through the S21 XP. This is what brings the world’s most deployed ASIC family onto V2: one reflash, no new hardware.
• AxeOS 2.14.0+ — native V2 on Bitaxe, shipped June 2026, with hardening in 2.15.0.
• NerdQAxe firmware 1.0.37+ — native V2 across NerdAxe, NerdQAxe+/++ and NerdOCTAxe.
• Auradine FluxOS — among the first to ship native V2 on its Teraflux line.
• Stock Bitmain firmware — V1 only, on every model including the S21 and S23. No Antminer ships with working Stratum V2 out of the box.
• Stock WhatsMiner, VNish, LuxOS, Canaan/Avalon stock — V1 only.

Two corrections worth stating plainly, because both circulate widely and cost people an evening. No Antminer supports V2 in stock firmware — some builds expose a V2-looking setting that never negotiates a real session, which is worse than offering nothing, since the miner looks configured while quietly running V1. And Bitaxe and NerdQAxe do support V2 natively, and have since June 2026 — guides written before then, this one included, said otherwise.

For the step-by-step configuration of any of these — including the authority-key details that decide whether your session is merely encrypted or actually authenticated — see our Stratum V2 solo mining guide.

The Translator Proxy bridge

For older hardware that can’t natively speak V2, the SRI provides a Translator Proxy. Your existing V1 ASIC connects to the proxy on your local network; the proxy speaks V1 to the miner and V2 to the pool, giving you the encryption and bandwidth benefits without a firmware change. Job negotiation still requires native V2, but the proxy covers the encryption layer for any rig.

How much extra profit does V2 actually add?

You’ll see a “V2 increases profit by up to ~7%” figure cited often. It’s an upper bound under ideal conditions, and it breaks down roughly like this:

• ~1-2% from encryption — eliminating the silent hijacking that plagues unencrypted V1 on untrusted networks
• A few percent from transaction selection — running your own mempool to capture the highest-fee transactions, especially during congestion
• ~1-2% from fewer stale shares — V2’s lower latency and binary efficiency mean less rejected work

Most miners will see something in the low single digits in practice — and the encryption slice only materializes if you were actually exposed to hijacking in the first place. Treat the headline number as a ceiling, not a promise.

What this means for SoloFury miners

SoloFury has served Stratum V2 in production since August 2026, across nine regions on five continents. V1 and V2 run on the same port — the pool detects which protocol your miner speaks and answers accordingly — so a mixed fleet points at one address and nothing needs reconfiguring. V2 is available for BTC; BCH, BC2, BCH2 and XEC continue on V1 with full version-rolling, so every modern ASIC keeps its AsicBoost gain whichever chain you point at.

Here’s the key point for solo miners specifically: in solo mining, the pool doesn’t control your funds or sit between you and your reward. You set your stratum username to your own wallet address, the pool assembles a block, you find it, and the network’s coinbase pays you directly. There’s no custody to compromise and no balance to freeze. Solo mining was already structurally aligned with V2’s decentralization goals — which is why, for solo miners, V2’s gains are encryption, latency, and one capability the protocol enables uniquely well: with an extended channel and coinbase decoding, your own miner displays the block’s outputs before you hash them, so you can verify the reward is addressed to you rather than take the pool’s word for it. (For why AsicBoost is free hashrate regardless of protocol version, see our AsicBoost deep dive.)

Appendix: the quantum threat to Bitcoin

In late March 2026, Google Quantum AI — together with Stanford cryptographer Dan Boneh and the Ethereum Foundation’s Justin Drake — published a whitepaper, The Quantum Threat to Elliptic Curve Cryptocurrencies, that reset the conversation. Earlier models assumed millions of qubits would be needed to break Bitcoin’s signatures. Google’s new estimate: fewer than 500,000 physical qubits — roughly 20× below the 2019 figure of ~20 million — could crack a Bitcoin private key in about nine minutes once a transaction exposes the public key. (This appendix is technical background, not investment or security advice. The threat is real but not imminent — see the skeptics below.)

What the threat actually is

Bitcoin leans on two cryptographic primitives. SHA-256 (proof-of-work and Merkle trees) is quantum-resistant for any practical purpose — breaking it is astronomically far off, and your ASICs are unaffected. secp256k1 ECDSA and Schnorr (the digital signatures securing transactions) are the vulnerable part: Shor’s algorithm, on a sufficiently large quantum computer, can derive a private key from an exposed public key.

The nuance most coverage gets wrong: a public key is only exposed when you spend from an address (or use a legacy format that stores it directly). As of March 2026, over a third of all bitcoin — roughly 6.9 million BTC — sit in addresses with public keys already revealed on-chain. About 1.7 million of those are in ancient pay-to-public-key (P2PK) outputs, including roughly a million believed to be Satoshi’s. Coins in modern addresses that have never been reused keep their public key hashed and hidden until you spend.

”Harvest now, decrypt later”

The reason developers say the clock has started, even though no capable quantum computer exists, is that exposed public keys are permanent and public. An adversary can archive them today and crack them whenever the hardware arrives — and a patient attacker might compute keys quietly and bleed funds out months later, so “Q-Day” could be recognized only in hindsight. Every key exposed now is a standing future target.

BIP-360: a quantum-resistant address type

BIP-360 introduces a new output type — described as Pay-to-Quantum-Resistant-Hash (P2QRH) or Pay-to-Merkle-Root, using a new bc1z address prefix. It behaves much like Taproot but replaces the exploitable elliptic-curve element with NIST-approved post-quantum signatures (such as the hash-based SPHINCS+ and lattice-based CRYSTALS-Dilithium). The trade-off is size: post-quantum signatures run from a few kilobytes (Dilithium) to far larger (SPHINCS+), versus roughly 64-72 bytes for ECDSA — so blocks get heavier and capacity tightens during any migration. BIP-360 was merged into Bitcoin’s BIP repository in February 2026, with testnet implementations already running, though it is not yet activated as a soft fork.

BIP-361: the controversial sunset

BIP-361, “Post Quantum Migration and Legacy Signature Sunset,” authored by Casa CTO Jameson Lopp and five co-authors (draft published April 2026), proposes a phased plan to force migration off vulnerable signatures:

• Phase A (roughly three years after a post-quantum address type activates): block sending funds to quantum-vulnerable address types, pushing everyone toward safe formats.
• Phase B (roughly five years after activation): a flag-day soft fork invalidates ECDSA/Schnorr spends entirely. Any UTXO not migrated by then becomes unspendable.
• Phase C (optional, under research): a recovery path letting holders prove ownership via a zero-knowledge proof of their BIP-39 seed — without exposing keys.

Phase B effectively freezes the ~1.7 million ancient BTC whose owners can’t migrate, including Satoshi’s. Critics call freezing coins — even to protect them — a violation of property rights and a dangerous precedent. Supporters argue the alternative is worse: leaving those coins for a future quantum attacker to sweep and dump, crashing confidence and price. Lopp frames it as game theory; the draft is explicitly not positioned for activation, and Bitcoin Core remains cautious. It is the most contested proposal of the set.

Hourglass and the alternatives

An Hourglass-style approach is the gentler cousin: rather than freezing vulnerable coins outright, it would throttle how fast they can be spent, limiting how quickly a quantum thief could drain and dump them without permanently locking honest owners out. Separately, a StarkWare researcher published a scheme to make new transactions quantum-safe today via hash-based proofs, opt-in and without a soft fork. And purpose-built quantum-resistant chains exist (QRL uses hash-based XMSS signatures, for example), though none has meaningful share next to Bitcoin. The prevailing bet is that Bitcoin upgrades in time.

How close is the threat, really?

Not close in hardware terms. Today’s quantum computers run on the order of hundreds of logical qubits; breaking secp256k1 needs thousands of logical (and hundreds of thousands of physical) qubits with error rates nobody has yet achieved at scale. The estimates also assume major engineering feats that may take many years. Voices urging calm are prominent: Blockstream’s Adam Back argued in 2026 that the threat is likely decades away and migration should be gradual, while consultancy McKinsey has floated a 2027-2030 window for potential viability, and a BIP-360 co-author estimates a full migration could itself take around seven years. The honest summary: real, taken seriously, and not a 2026 problem — but one Bitcoin has chosen to start solving early because the migration is slow and the exposed supply is enormous.

What miners should do today

1. Use modern address formats (bech32 bc1q or Taproot bc1p) for all mining payouts; avoid legacy formats where possible.
2. Don’t reuse addresses. Generate a fresh one per payout — modern wallets do this automatically.
3. Hold in hardware wallets that have committed to supporting post-quantum address types once activated.
4. Track BIP-360 / BIP-361 / Hourglass through Bitcoin Core and the proposals’ authors.
5. Don’t panic. SHA-256 proof-of-work is safe; your rigs keep working unchanged regardless of how the signature debate resolves.

Closing thoughts: protocols evolve, miners adapt

Bitcoin’s history is a sequence of upgrades that felt controversial in the moment and inevitable in hindsight. SegWit divided the community, then activated and enabled Lightning. Taproot took years of debate, then unlocked richer scripting. Stratum V2 will similarly take time to fully deploy — and then we’ll wonder how we tolerated unencrypted plaintext mining at all. The post-quantum migration will be longer and more contentious, but the economic incentives align: protect the network’s value, protect users’ coins, and start while there’s still runway. Your mining hardware doesn’t need to change for any of it. Your wallet habits matter more than your hash algorithm: use modern addresses, don’t reuse them, hold in hardware wallets, and stay informed.