How Stratum V2 Increases Mining Profitability
Stratum V2 can improve Bitcoin mining profitability by reducing stale shares, lowering latency, improving block propagation, and protecting miners from hashrate hijacking. Based on benchmark results from Hashlabs machines, miners using Stratum V2 with Job Declaration may see up to a 7.75% net profit improvement when operating on a 10% margin.
In Bitcoin mining, milliseconds matter. A small delay can cause a miner to submit stale shares, work on outdated jobs, miss transaction fee opportunities, or lose a block propagation race. These inefficiencies reduce miner revenue and, for operations running on thin margins, have an even larger impact on net profit.
For more than a decade, Stratum V1 (SV1) has been the standard protocol connecting ASIC miners to mining pools. But SV1 was built for an earlier era of mining. It lacks modern encryption and authentication by default, relies heavily on pool-side job distribution, and introduces inefficiencies that can reduce revenue.
Stratum V2 (SV2) is the next-generation mining protocol. It improves miner-pool communication, reduces latency, strengthens security, and supports Job Declaration, which allows miners to construct their own block templates using a local Bitcoin node. These efficiency improvements can increase miner revenue and, because mining margins are often narrow, translate into meaningful profit gains.
SV2 is now more relevant than ever. The first known Bitcoin block using Stratum V2 Job Declaration has now been found through DMND infrastructure by GoMining, showing that miner-built block templates are now being used in production.
Last year, the Stratum V2 team published a case study using Hashlabs machines. We conducted the test together with them. This article focuses on the profitability side of those results.
Objectives & Methodology
The objective was to evaluate whether SV2 improves mining efficiency and profitability compared to SV1.
The benchmark measured:
Share submission
Latency:
Block change latency
Job latency
Block propagation
Hashrate hijacking
The test used two identical S19k Pro ASIC miners, one running SV1 and one running SV2, in a controlled environment with simulated network latency, containerized infrastructure, and an early-stage open-source benchmarking tool.
Two SV2 configurations were tested: SV2 without Job Declaration using a Translation Proxy, and SV2 with Job Declaration using a local Bitcoin node and Job Declaration Client.
Let's go through each factor we tested one by one and see how they impact mining profitability.
Share Acceptance Rate
Share Acceptance Rate measures how much submitted miner work is accepted by the pool. Valid shares are paid. Stale shares are submitted too late and rejected, which means wasted hashpower.

The benchmark showed that SV1 miners waste around 0.1% to 0.2% of hashpower on shares that do not result in payouts. SV2 without Job Declaration reduced this to around 0.08%. SV2 with Job Declaration reduced it almost entirely, assuming the miner and pool node have similar connectivity.
For miners operating on a 10% profit margin, eliminating this avoidable inefficiency can increase net profit by up to 2%.
Most of this improvement come from the Job Declaration Client. By connecting to a local JDC linked to the miner’s on-site Bitcoin node, SV2 helps miners receive fresher jobs and reduces the chance of working on outdated templates.
Latency
SV2’s latency improvements come mainly from Job Declaration. With SV2, the Job Declaration Client can sit inside the mining farm’s local network and deliver fresh jobs directly to ASICs. SV1 relies on remote pool infrastructure, which introduces more latency.
The benchmark used an average production pool round-trip time of approximately 110 ms to simulate realistic network conditions.

We will now break down the latency improvements further in three categories:
Block change latency
Job latency
Block propagation
Block Change Latency
Block Change Latency is the delay between a new Bitcoin block being found and the miner switching to the next valid job. During this delay, miners may keep hashing on outdated work.

The benchmark results were:
SV1: 325 ms
SV2 without Job Declaration: 57.8 ms
SV2 with Job Declaration: 1.42 ms
SV2 with Job Declaration was more than 228 times faster than SV1. Over a year, this avoids around 4.9 hours of wasted hashing time using SV1 compared to SV2.
For miners operating on a 10% profit margin, this equals roughly a 0.54% net profit improvement. Since block change latency directly contributes to stale shares, this should not be double counted with the share acceptance gain.
Job latency
Job Latency is the time it takes for miners to receive updated jobs. Lower job latency helps miners work on fresher block templates that include more recent transactions and potentially higher fees.

The benchmark results were:
SV1: 228 ms
SV2 without Job Declaration: 57.8 ms
SV2 with Job Declaration: 2.44 ms
SV2 with Job Declaration was more than 93 times faster than SV1.
Using a dataset of 53,154 Bitcoin blocks, the benchmark estimated that this timing advantage was worth approximately 0.00141 BTC per block compared to SV1.
That equals around 0.75% of all the transaction fee revenue per block. Against the full block reward, including subsidy and fees, it equals around 0.04% of total block revenue.
For miners operating on a 10% margin, this translates into an estimated 0.4% net profit improvement.
Block Propagation Latency
Block Propagation Latency measures how quickly a newly mined block is broadcast and accepted by the Bitcoin network. Faster propagation matters during rare block races, where two miners find competing blocks close together.

SV2 with Job Declaration reduced block propagation time from 96.3 ms with SV1 to 3.44 ms.
This improvement comes from SV2’s architecture. With Job Declaration, a block can be propagated from the miner-side Job Declaration Client as well as the pool-side Job Declaration Server. SV1 only propagates blocks from the pool-side server.
The long-term profit impact is difficult to model because block races are rare and unpredictable. But the downside of losing a block race can be the full block reward, making faster propagation an important risk-reduction benefit.
Hashrate Hijacking
SV1 exposes miners to hashrate hijacking because it lacks encryption and authentication by default. An attacker positioned between a miner and pool can intercept job data and submit the miner’s shares under their own credentials.
Industry estimates suggest this type of attack can result in 1% to 2% of hashrate being stolen while remaining difficult to detect.
SV2 prevents this by encrypting the communication channel and enforcing authentication. For miners operating on a 10% profit margin, recovering even 0.5% of effective hashrate can increase net profit by up to 5%.
Summary
By reducing stale shares, lowering latency, improving block propagation, and securing miner-pool communication, SV2 can create a meaningful profitability improvement.
Based on the benchmark, SV2 with Job Declaration can increase revenue by approximately 0.775% and net profit by up to 7.75% for miners operating on a 10% margin.
| Improvement | Estimated Net Profit Gain (at 10% margin) |
|---|---|
| Reduced stale shares | +2.0% |
| Fee gain from lower job latency | +0.4% |
| Hashrate hijacking protection | +5.0% |
| Block change latency | (not counted twice) |
| Block propagation | (unmeasured) |
| Total estimated net profit gain | up to 7.4% |
These gains come from protocol-level improvements, not from replacing ASIC hardware.
For miners who want to explore SV2 in production, DMND Pool is the first Stratum V2 mining pool and supports miner-side block template construction. This gives miners a practical path to test SV2 benefits such as lower latency, encrypted communication, and greater control over block construction.
The results should be viewed as directional, since the benchmarking tool and SV2 applications are still evolving. Still, the conclusion is clear: SV2 is not only a decentralization upgrade. For miners, it is also a profitability upgrade.
For the full benchmarking setup and methodology, including hardware configuration, simulated network latency, pool infrastructure, and SV2 application details, see the original Stratum V2 case study published by the Stratum V2 team.