Stratum V1 vs Stratum V2: Migration Guide, Firmware Support & Pool Compatibility (2026)

Stratum V2 replaces V1’s plaintext JSON-RPC with an encrypted binary protocol that reduces bandwidth by roughly 70 %, prevents pool-to-miner man-in-the-middle attacks, and — most importantly — lets miners select their own transactions instead of delegating that decision entirely to the pool.

Stratum V1 has carried Bitcoin mining traffic since 2012. It works, it is universally supported, and every major pool, every stock firmware ASIC, and every open-source mining client speaks it fluently. But it was designed when pools were small and the threat model was simpler. Stratum V2 (co-authored and released by Braiins, building on earlier work by Matt Corallo and Pavel Moravec) fixes three structural problems that V1 cannot solve without a protocol replacement: inefficient plaintext framing, zero encryption, and centralised transaction selection.

This guide covers the technical delta between the two protocols, which firmware actually ships native V2 support today, which pools accept V2 connections, and the realistic migration paths available right now — including the SRI translation proxy approach that lets any V1 miner benefit from parts of V2 without a firmware change.

What Stratum V1 gets right — and where it falls short

V1’s design is elegant in its simplicity. A miner opens a TCP connection, sends mining.configure (optional, for BIP 310 version-rolling negotiation), mining.subscribe, and mining.authorize, then receives mining.notify work units as JSON lines. The pool controls every detail of the block template: which transactions to include, in what order, and what appears in the coinbase. The miner’s only degree of freedom is the nonce and, if the pool grants BIP 310, certain version bits.

Three shortcomings become material at scale:

No encryption. V1 runs over plain TCP. Anyone on the path between miner and pool can see worker credentials, observe share submissions, and — in a targeted attack — inject fake work or redirect hashrate. TLS wrappers exist but are not part of the standard and have uneven deployment.
Verbose framing. Every message is a JSON object terminated by a newline. Field names like "mining.notify" and "mining.set_difficulty" repeat on every message. For a large farm, this overhead is measurable; for a home miner it is invisible, but it caps the protocol’s scalability ceiling.
Pool-controlled transaction selection. The pool decides what goes into every block. This is fine for fee optimisation. It becomes a centralisation risk when any single pool controls enough hashrate that its transaction-inclusion policy determines which transactions get confirmed — and it makes censorship trivial to execute silently.

What Stratum V2 adds: the four pillars

1. Binary framing — roughly 70 % bandwidth reduction

Every V2 message uses a compact 6-byte header: a 2-byte extension type, a 1-byte message type, and a 3-byte payload length. All integers are little-endian binary, not ASCII. Field names are absent — message type determines structure. Benchmarks cited in the Stratum V2 specification put the bandwidth saving at approximately 70 % compared to equivalent V1 traffic. For a home miner with one or two machines the practical impact is negligible; for a hashcenter operating hundreds of ASICs on a metered uplink, the saving compounds across every job update and share submission.

Formula note: the saving is structural, not configurable — it follows from replacing variable-length ASCII JSON with fixed-schema binary frames. No implementation tuning is required to realise it.

2. Mandatory Noise Protocol encryption

V2 mandates Noise_NX_secp256k1_ChaChaPoly_SHA256 encryption on every connection. The handshake proceeds in two acts:

The miner sends a 64-byte ElligatorSwift-encoded ephemeral public key.
The pool responds with its own ephemeral key, its static public key (encrypted), and a Schnorr signature over a SIGNATURE_NOISE_MESSAGE (version, valid_from, not_valid_after, static pubkey) — verified against the Pool Authority Public Key embedded in the connection URL.

After the handshake, both parties use ChaCha20-Poly1305 AEAD with per-message nonce counters. The scheme provides forward secrecy (ephemeral keys are discarded after the session) and server authentication (the pool’s identity is cryptographically bound to its URL, preventing silent rerouting to a malicious pool). Worker credentials sent in OpenStandardMiningChannel are therefore encrypted in transit — a meaningful improvement over plaintext V1 mining.authorize.

3. Job Declaration Protocol — miner-selected transactions

This is Stratum V2’s most consequential feature for Bitcoin decentralisation. Under V1 (and under V2 without the Job Declaration Protocol), the pool composes the block template. Under V2 with JDP, the miner:

Connects to a Template Provider (a local Bitcoin full node) via the Template Distribution sub-protocol.
Allocates a mining job token from the pool’s Job Declaration Server.
Builds its own coinbase transaction (including required pool payout outputs) and selects its own mempool transactions.
Declares the job to the JD Server (DeclareMiningJob), which validates and countersigns it.
Mines the self-composed template; if a block is found, submits it via PushSolution.

The result: the pool cannot censor or reorder transactions in a miner’s blocks, because the miner never gives the pool its transaction list — only merkle branches sufficient for share validation. This is structurally different from DATUM (OCEAN’s protocol), which achieves the same decentralisation goal via a different architecture. See DATUM protocol for a comparison.

4. Channel multiplexing

V2 introduces three channel types on a single TCP connection:

Standard channels — for end-mining ASICs; the pool delivers a complete merkle root, no coinbase construction required.
Extended channels — for proxies that serve multiple downstream miners; the proxy receives coinbase components and merkle branches and constructs work locally.
Group channels — shared SetNewPrevHash and job messages across many standard channels, reducing per-miner overhead at a proxy.

This separation of concerns lets a single SV2 connection efficiently serve a multi-hundred-ASIC farm behind a local proxy without per-miner round-trips to the pool.

Technical comparison: V1 vs V2 at a glance

Dimension	Stratum V1	Stratum V2
Framing	JSON-RPC over TCP, newline-delimited	Binary, 6-byte header + typed payload
Bandwidth (approx.)	Baseline	~70 % reduction (per SV2 specification)
Encryption	None (TLS optional, non-standard)	Mandatory Noise_NX (ChaCha20-Poly1305)
Forward secrecy	No	Yes (ephemeral session keys)
Server authentication	No	Yes (Pool Authority Key in URL)
Worker credential protection	Plaintext on wire	Encrypted inside Noise session
Transaction selection	Pool only	Pool (default) or miner (via JDP)
Version rolling negotiation	BIP 310 (`mining.configure`), mask 0x1FFFE000	`version_rolling_allowed` flag in `NewExtendedMiningJob`
Difficulty representation	Scalar (pdiff number)	256-bit target (U256)
Job + prev_hash delivery	Combined in `mining.notify`	Split: `NewMiningJob` (future) + `SetNewPrevHash` (activates)
Requires Bitcoin full node	No	No (standard/extended); Yes (JDP with Template Provider)
Backward compatibility	Ubiquitous	Via SRI translation proxy (V1 miner → V2 pool)
Specification status	De facto (Bitcoin Wiki + BIP 310)	Formal spec at stratumprotocol.org; SRI 1.0.0 released

Firmware support table

As of June 2026, BraiinsOS+ is the only third-party ASIC firmware with native, production Stratum V2 support — a fact confirmed across multiple independent sources including the Braiins documentation and the Bitcoin Mining Hack Bible used as D-Central’s technical reference. This leadership reflects Braiins’s foundational role in co-authoring the V2 specification; we credit them unreservedly for that contribution to the ecosystem.

See the firmware comparison page and the open firmware feature dataset for full protocol and feature breakdowns. For total cost of ownership including dev fees, see the firmware TCO calculator.

Firmware	Stratum V1	Stratum V2 (native)	Dev Fee	Notes
Stock (Bitmain / MicroBT)	Yes	No	0 %	V1 with BIP 310 version rolling on most models
BraiinsOS+	Yes	Yes — native	2–2.5 %	Co-authored the V2 spec; the reference implementation; also ships V1↔V2 translation proxy internally
VNish	Yes	No	2–2.8 %	V1 only as of June 2026
LuxOS	Yes	No	2.8 %	V1 only as of June 2026; known for 110 V / watt-anchored mining
DCENT_OS	Yes	Planned (per beta image)	0 % default (configurable)	Closed beta, GPL-3.0; V2 path is in beta codebase and targets Stratum V2 + DATUM; public beta summer 2026 — do not rely on this for production

Note on dev fees: BraiinsOS+ charges 2–2.5 % (range, not a flat figure); VNish charges 2–2.8 % depending on model and feature set. Always verify current rates at the vendor’s documentation before deployment — dev fee ranges can change between firmware releases.

Pool support table

Pool adoption of Stratum V2 has accelerated in 2025–2026, but full production support remains limited. The table below reflects publicly available information as of June 2026; verify directly with each pool before configuring miners, as this landscape is actively changing.

Pool	V2 Status	JDP (miner tx selection)	Notes
Braiins Pool	Full production V2	Yes	Co-authored the spec; longest-running V2 production endpoint; the reference against which SRI and other implementations are validated
DMND (Demand)	Full production V2	Yes	Launched 2025 as a V2-native pool; miner-selected templates by default
OCEAN	DATUM protocol (not V2)	Yes (via DATUM Gateway + local node)	DATUM achieves miner transaction selection via a different architecture — a local Bitcoin full node + DATUM Gateway speaks V1 to your ASICs. See DATUM protocol guide.
Foundry USA	Testing / working group	Not yet	Joined Stratum V2 Working Group May 2026; production rollout timeline not confirmed
Antpool	Working group	Not yet	Joined Stratum V2 Working Group May 2026
F2Pool	Working group	Not yet	Joined Stratum V2 Working Group May 2026
ViaBTC	V1 only	No	No public V2 announcement as of June 2026
SRI community pool	V2 test endpoint	Testing	Operated by the Stratum Reference Implementation project for ecosystem testing; not for production mining

For a full analysis of pool fees, payout schemes, and decentralisation profiles, see the mining pool comparison.

Migration paths: how to get to V2 from where you are today

Path A — Native V2 firmware (BraiinsOS+ on compatible Antminers)

If you are running BraiinsOS+ on a supported Antminer S19 / S19 Pro / S19j Pro / S19 XP / S21 series, native V2 is already available. Enable it in the pool configuration by switching the connection URL to the pool’s V2 endpoint (e.g., Braiins Pool’s stratum2+tcp:// URL). No additional hardware or software is required. The firmware handles the Noise handshake, channel negotiation, and — if you connect to a JDP-capable pool — the Job Declaration flow.

This is the lowest-friction path to full V2 including encryption and (optionally) miner transaction selection. The trade-off is BraiinsOS+’s 2–2.5 % dev fee.

Path B — SRI translation proxy (any V1 firmware, V2 upstream)

The Stratum Reference Implementation (SRI) project ships an open-source translation proxy that accepts V1 connections from miners on one side and speaks V2 to a pool on the other. You run the proxy on a machine on your local network (a Raspberry Pi, a router, or any always-on device); your ASICs point at the proxy as if it were a pool.

What you gain: encrypted transport to the pool, pool authentication, and reduced bandwidth on the proxy-to-pool leg. What you do not gain: miner-selected transactions (the proxy handles template construction, not the ASIC firmware). This path works with any firmware — stock, VNish, LuxOS, or BraiinsOS+ — and does not require firmware changes.

SRI 1.0.0 is the current stable release. See stratumprotocol.org for deployment documentation.

Path C — DATUM Gateway (miner transaction selection without V2)

OCEAN’s DATUM protocol achieves the same decentralisation goal as V2’s Job Declaration Protocol via a fundamentally different architecture: a local Bitcoin full node generates the block template, a local DATUM Gateway serves V1-format work to your ASICs, and the Gateway communicates with OCEAN’s servers for share accounting. Your ASICs continue speaking Stratum V1 — no firmware change required.

DATUM is not Stratum V2. It does not use V2’s binary framing or Noise encryption on the miner-facing connection. What it does do — give miners full transaction selection — is the most decentralisation-impactful feature of the V2 ecosystem. See the full DATUM protocol guide for setup requirements (you need a synced Bitcoin full node) and operational considerations.

Why this matters for Bitcoin decentralisation

The centralisation risk in Bitcoin mining is not primarily about who owns the hardware. It is about who controls transaction selection. When a small number of pools compose the overwhelming majority of blocks, their mempool policies — and the pressure they face from regulators, payment processors, or large depositors — determine what gets confirmed. A pool can silently omit transactions from a specific address without any miner on its hashrate noticing.

Stratum V2’s Job Declaration Protocol, and DATUM on the OCEAN side, break this link. A miner running its own full node selects its own transactions. The pool sees only the merkle branches needed to validate the share — not the transaction list. It cannot selectively exclude transactions it cannot see. More miners exercising this capability means no single pool controls the block content of a meaningful fraction of the chain.

The current adoption numbers are modest. As of June 2026, the majority of network hashrate still runs V1 with pool-controlled templates. The V2 working group’s addition of Foundry, Antpool, and F2Pool in May 2026 signals that the largest pools are preparing infrastructure — but “preparing” is not “deployed.” Progress is real; it is not yet transformative.

For solo miners and home hashcenter operators, the actionable takeaway is: if you are already running BraiinsOS+ on a compatible machine, switching to a V2 pool connection costs nothing and adds encryption. If you want miner transaction selection today without changing firmware, DATUM via OCEAN is operational and documented. Both paths are incremental steps toward a mining ecosystem that is harder to coerce.

Frequently asked questions

Can I use Stratum V2 with my existing ASIC firmware today?

It depends on your firmware. BraiinsOS+ on compatible Antminer models supports native Stratum V2 — enable it by pointing the pool URL to a V2 endpoint. All other major firmwares (stock, VNish, LuxOS) speak V1 only as of June 2026. However, any V1 firmware can reach a V2 pool via the SRI translation proxy without any firmware change — you install the proxy on a local machine, and your ASICs connect to it as if it were a pool. You gain encrypted transport; you do not gain miner transaction selection via this path.

Does switching to Stratum V2 improve my hashrate or efficiency?

Not directly. V2’s 70 % bandwidth reduction matters at scale but does not move the needle on per-machine efficiency. What V2 changes is security and — with the Job Declaration Protocol — decentralisation. The efficiency of your ASIC chips is determined by the firmware’s autotuner and the power profile you select, not by which version of the pool protocol you use. If you want per-chip tuning or power targeting, those are firmware-level features: see the firmware comparison.

What is the Job Declaration Protocol and why does it matter?

The Job Declaration Protocol (JDP) is the sub-protocol within Stratum V2 that lets a miner compose its own block template — selecting which transactions from its local mempool to include — rather than accepting the pool’s template. The miner submits a declaration to the pool’s Job Declaration Server; the pool validates that required payout outputs are present and signs off, but never sees the full transaction list. If a block is found, the miner’s node broadcasts it directly. The practical result: the pool cannot censor or reorder that miner’s transactions without the miner’s knowledge. This requires a synced Bitcoin full node running locally alongside the miner.

What is the difference between Stratum V2 Job Declaration and DATUM (OCEAN)?

Both achieve miner-controlled transaction selection, but they are architecturally different. V2 JDP is specified at the protocol level and implemented inside V2-capable firmware (currently BraiinsOS+ and the SRI proxy); DATUM is OCEAN’s own protocol, which uses a local DATUM Gateway to mediate between your V1-speaking ASICs and a Bitcoin full node. With DATUM your ASICs speak ordinary V1 to the gateway; DATUM handles the template construction and communicates with OCEAN using libsodium-encrypted custom frames — not V2 binary frames. The decentralisation outcome is similar; the implementation path is different. See the DATUM guide for a full breakdown.

Which pools actually support Stratum V2 in production today (June 2026)?

Braiins Pool and DMND (Demand) run full production V2 including the Job Declaration Protocol. OCEAN runs DATUM — a distinct protocol with equivalent decentralisation properties but not V2. Foundry USA, Antpool, and F2Pool joined the Stratum V2 Working Group in May 2026 and are preparing V2 infrastructure, but production endpoints are not yet confirmed as of this writing. Verify current status directly with each pool before configuring your machines; this landscape is changing fast.

Does BraiinsOS+ charge a dev fee for its Stratum V2 support?

Yes. BraiinsOS+ charges a 2–2.5 % dev fee (a range, not a flat figure — verify the current rate for your model in the Braiins documentation). This fee applies regardless of whether you connect via V1 or V2. We credit Braiins for their foundational contribution in co-authoring and implementing the V2 specification. The SRI translation proxy approach, by contrast, is open-source and carries no protocol-level dev fee — you connect your existing firmware to the proxy and the proxy speaks V2 upstream. DCENT_OS targets 0 % dev fee by default (configurable); it is currently in closed beta only.

Related products, repair, and setup paths

Last reviewed June 15, 2026.