Under traditional Stratum V1, a handful of dominant pool operators build all block templates, giving them centralized power to filter transactions or comply with regional censorship lists.
My take:
- Stratum V2 gives individual hashers total control over transaction selection, restoring decentralized censorship resistance while reducing latency and bandwidth.
- However, adoption remains slow because major pool operators have little financial incentive to surrender template control, leaving small miners defaulting to V1 convenience.
Do you think Stratum V2 adoption will happen organically through miner demand, or will it take a major transaction censorship event to force the shift? Drop your perspective below! 👇
There is no incentive for miners to take on this responsibility, so no. And if a major censorship attack happened, I don't see miners shifting, but rather just complying. It will be the realm of enthusiasts / technologists so probably won't get more than a percentage or two of the total network hashrate ever, imo.
Not if they mine with a pool. The pool can refuse to pay out shares submitted for custom templates created by individual hashers.
Two things that I think get missed in this framing:
1. Template control in SV2 is a separate, optional piece. SV2 is really several sub-protocols. The encrypted, binary mining protocol is what most "SV2 support" means today. Miner-built templates need the Job Declaration protocol on top, and as Kruw says, a pool that runs JD can still refuse to pay for templates it doesn't like. So "SV2 adoption" and "hashers choose transactions" aren't the same metric. The second one is the one to watch.
2. Censorship doesn't need to be fixed at 100%, it needs to stay expensive. If pools with 70% of hashrate filtered a transaction, it would still confirm, just in about 3x the expected time. Censorship only really bites near majority hashrate. So the useful question isn't "will most hashers build templates?" but "will there always be enough non-filtering hashrate that filtering stays pointless?" That's a much lower bar, and miner-side templating (Ocean's DATUM, DEMAND's JD pool) already clears part of it without SV2 winning everywhere.
On incentives: I'd expect SV2 to spread for boring reasons first. Encryption stops hashrate hijacking on the wire, and there are bandwidth and latency gains. JD would come along later as an opt-in for the people who care, rather than as a mass response to some censorship event.
Individual hashers can already make their own pool or select a politically aligned one
If one doesn't like or trust a pools policy decisions, why would one also expect them to change their software? It's like going to a restaurant who serves food you don't like expecting them to change it.
The software doesn't change the fact that individual hashers are an irrelevant amount of hash.
It's the kind of nonsense armchair activism only an NGO psyop could astroturf
https://m.stacker.news/161285
Stratum V2 helps, but it isn't a silver bullet by itself.
What it actually fixes: with Job Declaration, the hasher (or a JD client they trust) can build templates, so a pool can't silently filter txs just by owning the template. It also cuts bandwidth vs V1.
What it doesn't fix on its own:
So: V2 is the right protocol fix for technical censorship-at-the-template, but a crisis is avoided only if enough hashers actually run JD (or solo/DATUM-style paths) and treat pools as dumb payment routers. Worth pushing; not worth waiting on alone.
Technical nuance worth adding (AI-assisted answer):
SV2 is really three specs: the mining protocol (binary, encrypted pool<->miner link), Template Distribution (pulls templates from your own Bitcoin Core), and Job Declaration (JD). Only JD moves transaction selection to the miner, and it's optional. A pool can run SV2 and still send its own templates.
With JD, the miner runs a Job Declarator Client plus a local node, builds the template, and declares it to the pool's Job Declarator Server. As Kruw notes, the pool can still reject declared jobs or refuse to pay those shares. But that refusal is visible and attributable, which is the point: censorship stops being silent, and miners can leave a pool that rejects templates containing certain transactions.
Economics matter too: most pools pay via FPPS, so the pool carries fee risk. A miner-built template that pays fewer fees costs the pool money, which is part of why pools are slow to allow it. It's not just inertia.
My guess: it spreads gradually as a feature for larger self-hosted miners, not all at once. A visible censorship event would speed it up, because with SV2 miners can actually verify what their pool is doing.