Stratum V2 Deployment Tracker: Which Roles & Pools Actually Do Job Declaration (2026)
“Is Stratum V2 here yet?” is the wrong question, because SV2 is really two layers on very different timelines. The transport — encryption, authentication that stops hashrate hijacking, header-only mining — is live and shipping in real firmware today. Job Declaration — the part that actually decentralizes mining by letting the miner build the block template instead of the pool — is the hard last mile, and it just crossed from theory into on-chain reality. This tracker maps the six SV2 roles and every serious implementation to what genuinely works in mid-2026, and where the gap still is.
Quick answer
Stratum V2 is two different things, and conflating them is the biggest mistake people make about it. SV2-the-transport — encryption, authentication that stops hashrate hijacking, header-only mining, less bandwidth — is LIVE and shipping: BraiinsOS+ and (since June 2026) AxeOS speak it natively, and any SV1 miner can reach an SV2 pool through a translator proxy. SV2 Job Declaration — the part that actually decentralizes mining by letting the MINER build the block template instead of the pool — is the hard last mile, and it crossed from theory to reality on 2026-06-25 when the DMND pool and GoMining mined mainnet block 955,318 from a miner-declared template. But it is still a hand-assembled stack (your own node + Template Provider sidecar + Job Declarator Client) pointed at effectively the one production pool that honors it.
Plain SV2 without Job Declaration is just a better, safer pipe — it does not decentralize anything. The decentralization is Job Declaration, and in mid-2026 it is real but not yet turnkey: one live pool (DMND), an experimental Bitcoin Core template path, and no consumer firmware that does JD by itself. Do not believe any claim that a firmware or pool gives you "miner-built templates" without checking it runs a Job Declarator.
The 6 SV2 roles
| Role | What it does | Builds templates? | Spec |
|---|---|---|---|
| Mining DeviceMiner | The endpoint doing the hashing (ASIC firmware or hashing app). Speaks the Mining Protocol to a pool/server over the encrypted SV2 transport, receiving jobs and submitting shares. | noOnly hashes assigned work; builds no templates. Decentralization comes from whatever feeds it jobs. | stable |
| Pool (Mining Server)Pool | Server-side role running the Mining Protocol: opens channels, distributes work, accounts shares, pays rewards. In a job-declaration deployment it is reduced to share-accounting + payout. | enabling onlyPlain SV2 pooling still means the POOL chooses transactions. Only decentralizes if the pool also runs a Job Declarator Server. | stable |
| Translator Proxy (SV1↔SV2)tProxy | Sits between legacy SV1 mining devices and an SV2 pool, translating SV1 JSON-RPC to the SV2 binary/encrypted protocol so non-native hardware can reach an SV2 endpoint. | noA compatibility shim for the transport. Relevant to decentralization only when paired with a local JDC supplying templates upstream. | stable |
| Job Declarator ClientJDC | Runs on the MINER's side. Takes a candidate template from a local Template Provider, then declares that transaction set to the pool's Job Declarator Server before mining it. | decentralizingThe core decentralization role — how a miner asserts its own transaction selection instead of accepting pool-dictated work. | draft |
| Job Declarator ServerJDS | Pool-side counterpart to the JDC. Validates the miner-declared template (transactions, fees, coinbase), approves it, and coordinates with the Mining Server so the miner's own block goes forward. | decentralizingA pool MUST run a JDS for miner-side template building to be honored. Without a live JDS, Job Declaration is theoretical. | draft |
| Template ProviderTP | Generates candidate block templates (the transaction selection) and streams them to the JDC. Normally a Bitcoin full node — now via Bitcoin Core's experimental IPC Mining interface + an external SV2 sidecar. | decentralizingWhere the actual transaction set is built. Miner-run TP + JDC returns block construction to the miner; a pool-run TP defeats the purpose. | stable |
Implementations — what actually works today
| Implementation | SV2 roles | Version | Maturity | Job Declaration live? |
|---|---|---|---|---|
| Stratum Reference Implementation (SRI) | Pool, JDS, JDC, Translator Proxy, TP sidecar, test Mining Device — ALL roles | Libraries repo ~v1.11.0 (2024, split into stratum-mining/stratum + sv2-apps roles); v1.0.0 milestone Mar 2024 | beta | JD: partial |
| The canonical, most complete SV2 codebase and the substrate DMND is built on. Full JD works in SRI and has now produced real mainnet blocks via DMND — but SRI itself is a reference/beta stack you hand-assemble, not turnkey consumer firmware. | ||||
| Braiins (BraiinsOS+ / Braiins Pool) | Mining Device (native SV2 client), Pool (SV2 transport endpoint) | BraiinsOS+ native SV2 client (2026); Braiins Pool publishes V1 + V2 endpoints | production | JD: no |
| TRANSPORT ONLY. BraiinsOS+ is the only commercial ASIC firmware with a native SV2 client (S9/S19/S21/S21 XP connect without a proxy) — encrypted, authenticated, header-only mining. Braiins' own academy still frames miner-built templates as a FUTURE capability: Job Declaration is NOT a generally available Braiins customer feature. | ||||
| Bitcoin Core — IPC Mining interface (TP path) | Template Provider (via generic Mining IPC, not SV2-native code) | Core 30.0 (Oct 2025) shipped the EXPERIMENTAL IPC Mining interface; 30.1 relaxed the -m requirement | experimental | JD: partial |
| The SV2-in-Core PR (#29432) was CLOSED — Core rejected embedding SV2. Instead it exposes a generic Mining interface over Cap'n Proto IPC; run multiprocess `bitcoin-node -m -ipcbind=unix` and an external SV2 TP sidecar (Sjors Provoost) connects to it. So a forked Core is no longer mandatory — pristine Core 30.x + sidecar works — but the interface is experimental and needs the sidecar. | ||||
| DMND (DEMAND) Pool | Pool (Mining Server), Job Declarator Server; supports miner-side JDC + TP | Launched Nov 2025 as first V2-native pool; first live JD block 2026-06-25 | production | JD: yes |
| 🔴 THE milestone: on 2026-06-25 DMND + GoMining mined mainnet block 955,318 using SV2 Job Declaration — the MINER, not the pool, selected transactions and built the template. Built on SRI. The first and (as of mid-2026) effectively only pool honoring job-declared work in live production. Still early: one flagship miner, not yet mass turnkey. | ||||
| AxeOS / ESP-Miner (Bitaxe) | Mining Device (native SV2 client) | Native SV2 early-access Mar 2026; stable in v2.14.0 (June 2026) | beta | JD: no |
| Native SV2 as a Mining Device only: binary protocol, Noise/ChaCha20-Poly1305 encryption, standard mining-channel messages, tested on BM1370 Bitaxe against the SRI reference pool. Speaks the SV2 TRANSPORT natively (no translator proxy) but does NOT do Job Declaration — it hashes assigned work. The second native-SV2 firmware family after BraiinsOS+. | ||||
End-to-end verdict
Can a miner run full Job Declaration today? PARTIAL. What works: a production pool (DMND) runs a live Job Declarator Server accepting miner-declared templates (proven on-chain); you can source templates from a pristine Bitcoin Core 30.x node via the experimental IPC Mining interface + Sjors' TP sidecar (a forked Core is no longer required); SRI provides working JDC/JDS/TP/translator roles. What is missing: it is a hand-assembled SRI/sidecar stack, not turnkey — you run your own node + TP sidecar + JDC and point them at a JD-capable pool, and effectively only ONE major pool (DMND) honors declared jobs in production today.
Native SV2 firmware. Two firmware families speak SV2 natively (transport, no translator proxy) in 2026: BraiinsOS+ (industrial Antminers — the only commercial firmware with a native client, transport-only) and AxeOS/ESP-Miner for Bitaxe (native SV2 since v2.14.0, Mining Device only). Everything else — stock Antminer/Whatsminer, VNish, LuxOS — is SV1 and needs the SRI Translator Proxy. Native transport is NOT Job Declaration: none of these firmwares do JD themselves; JD requires a separately-run JDC + Template Provider co-located with the miner.
The biggest gap. Turnkey, miner-side Job Declaration integrated into consumer firmware and pools. The pieces exist and interoperate (Core IPC TP, SRI JDC/JDS, one live production JD pool), but a normal miner still cannot flip a switch — broad pool-side JDS adoption and firmware-integrated JD are the missing last mile.
Open data (CC BY 4.0): CSV · JSON · API: /wp-json/dc/v1/stratum-v2-deployment
Why the transport-vs-Job-Declaration distinction is everything
A miner running SV2 without Job Declaration is still mining the pool’s chosen transactions — they just do it over a safer, leaner pipe. That’s genuinely valuable: the encryption closes the hashrate-hijacking attacks that plague SV1, and header-only work cuts bandwidth. But it does not move a single decision about which transactions get into a block away from the pool operator. The decentralization SV2 is famous for lives entirely in Job Declaration: a Job Declarator Client on the miner’s side takes a template from a Template Provider (a Bitcoin node the miner controls) and declares that transaction set to the pool’s Job Declarator Server, which must agree to honor it. Every link in that chain has to exist for it to mean anything — which is exactly why “we support Stratum V2” from a pool or a firmware vendor tells you almost nothing until you ask the follow-up: do you run a Job Declarator?
What changed in 2026
Three things moved the needle from “spec” to “shipping.” First, the DMND pool went live as the first V2-native pool running a Job Declarator Server, and on 25 June 2026 it and GoMining mined mainnet block 955,318 from a miner-declared template — the first time in Bitcoin’s history a pooled miner, not the pool, chose the transactions. Second, Bitcoin Core 30.0 shipped an experimental IPC Mining interface, so you can now source templates from a pristine Core node plus a Template Provider sidecar instead of running a patched fork (the direct SV2-in-Core proposal was closed in favor of this generic interface). Third, AxeOS added native SV2 in v2.14.0, making Bitaxe the second firmware family after BraiinsOS+ to speak the transport without a translator proxy. The honest caveat: Job Declaration is still a hand-assembled stack pointed at effectively one production pool, and no consumer firmware performs JD by itself. The pieces interoperate; the last mile is turnkey integration.
For the feature-by-feature V1-vs-V2 comparison and per-pool support, see the Stratum V1 vs V2 migration guide and the Stratum protocol support matrix. Which pools actually let you build your own template is scored in the pool censorship scorecard and the centralization tracker’s Template Sovereignty Index; the firmware that speaks SV2 natively is covered in the firmware comparison. New to the topic? Start at the mining pools hub.
Related products, repair, and setup paths
- how D-Central diagnoses ASIC repairs
- ASIC troubleshooting library
- ASIC manuals and repair guides
- replacement hashboards
- ASIC control boards
- ASIC power supplies
- immersion cooling hub
- home immersion cooling guide
- ASIC miners for immersion planning
- ASIC cooling parts
- airflow shroud before immersion
- compare miner specs in the database
- ASIC repair support
- compare ASIC miner specs
- ASIC miner database
- Antminer S19 specs and profitability
- buy a tested Antminer S19
- Antminer S19 maintenance guide
- Antminer S19 repair service
- Antminer S21 specs
- Bitmain Antminer S21
- Antminer S21 maintenance guide
- BM1370BC S21 Pro chip
- Antminer S9 specs
- Bitmain Antminer S9
- Antminer S9 maintenance guide
- S9 hashboard repair parts bundle
- Whatsminer M30S specs
- Whatsminer repair guide
- MicroBT Whatsminer M30S++
- Whatsminer M3x exhaust shroud
Last reviewed July 18, 2026.