Zcash mining difficulty can rise while your miner's hashrate stays flat. When difficulty rises, the same effective hashrate has a lower probability of finding a block over a given period, reducing expected ZEC earnings if other conditions remain unchanged. This also affects the theoretical value of work paid under PPS-based accounting: protection from pool luck does not mean protection from network difficulty changes.
However, higher difficulty is not the only possible cause. Fewer accepted shares after accounting for share difficulty, a lower miner subsidy, or short-term pool luck under PPLNS can also reduce credited ZEC. To identify the cause, separate device-reported hashrate, pool-estimated hashrate, network difficulty, and credited earnings, and compare them over matching periods.
How higher difficulty reduces expected ZEC earnings
Network difficulty determines how hard it is for mining work to meet the block target. If your effective hashrate and operating time stay unchanged, higher difficulty means fewer expected blocks attributable to that work. It does not itself reduce the subsidy paid for each block.
For example, assume your effective hashrate, operating time, miner subsidy, and pool fee remain unchanged, and set aside transaction-fee changes and short-term luck. If network difficulty is 20% higher throughout the comparison period, expected subsidy earnings are approximately:
Previous expected earnings ÷ 1.20 = 83.3% of previous expected earnings
That is a decline of about 16.7%, even though your hashrate has not changed. This is an expectation under the stated assumptions, not a prediction of an individual day's credited earnings. ViaBTC's PPS calculation similarly uses network difficulty to determine the block-reward payment for contributed work (ViaBTC: How are profits calculated?).
Read difficulty correctly
Zcash proof-of-work requires a valid Equihash solution and a block header hash at or below a network target; a lower target corresponds to higher difficulty. Unlike Bitcoin, which retargets on a fixed block interval, Zcash adjusts its target after every block. Its calculation uses a 17-block target-averaging window, median timestamps, and damping to respond to recent block timing. The post-Blossom target spacing is 75 seconds (Zcash Protocol Specification, §7.7).
A displayed network-hashrate figure is a separate estimate with its own measurement window. Zcash's getnetworksolps RPC call returns estimated network solutions per second based on the last n blocks, with a default lookback of 120 blocks that a caller can change (Zcash getnetworksolps documentation). Two dashboards using different lookback windows can legitimately show different hashrate figures for the same moment.
The practical conclusion is that difficulty and a displayed network-hashrate figure are not simultaneous readings of the same underlying quantity. A short run of faster-than-target blocks can push difficulty upward while a 24-hour hashrate average still looks flat. This can reflect short-term variance and different measurement windows; it does not, by itself, prove that total network hashrate increased.
For earnings analysis, check how difficulty changed during the period you are comparing, rather than relying only on whether a network-hashrate chart looks flat.
Hold device inputs constant
Before attributing a change in ZEC earnings to network conditions, isolate what is actually constant at the device level. Three distinct measurements exist, and they are not interchangeable:
- Device-reported hashrate — the rate shown on the miner's own interface, based on its internal solution count.
- Pool-estimated worker hashrate — the pool's estimate of a worker's contribution, derived from submitted shares and their assigned difficulty over a pool-defined window.
- Network hashrate — an estimate of total network work derived from recent blocks and their timing.
A flat device-reported hashrate does not confirm that the same amount of valid work reached the pool throughout the comparison period. Rising latency, intermittent connectivity, worker restarts, an unstable overclock, or a misconfigured endpoint can reduce credited work even when the local display appears unchanged. ViaBTC's ZEC mining documentation instructs users who see persistent invalid shares to check their settings (ViaBTC ZEC Mining guide).
Raw share counts also need context. A share submitted at a higher assigned difficulty represents more expected work, so fewer accepted shares do not necessarily mean a lower contribution. Compare accepted work weighted by share difficulty, or pool-estimated hashrate over comparable periods, alongside uptime and rejection rates. Compare raw counts directly only when the assigned share difficulty is the same, allowing for short-term statistical variation (ViaBTC: Share Difficulty vs. Network Difficulty).
Holding device inputs constant therefore means checking effective contribution over time, not just a local hashrate reading or the number of accepted shares.
Separate reward and network changes
The miner subsidy per block is not identical to the total block subsidy. Zcash's getblocksubsidy RPC reports a miner component separately from funding-stream and other subsidy components (Zcash getblocksubsidy documentation).
A scheduled halving reduces the subsidy. A protocol upgrade can also reduce the miner subsidy if it lowers the amount allocated to miners. However, a change in how funding is divided among other recipients does not necessarily change the miner's allocation. Check the actual miner subsidy at the relevant block heights rather than assuming every funding-stream change reduces mining earnings.
The key distinction is straightforward: a lower miner subsidy reduces the ZEC available to miners per block; higher difficulty reduces the expected number of blocks attributable to a fixed amount of mining work. These are separate mechanisms. Any change in difficulty following a halving is a separate adjustment, not the mechanism that cuts the subsidy (Zcash Protocol Specification, §7.8).
Reconcile pool output
Once effective device contribution is confirmed, check both network difficulty and the miner subsidy, then examine how the pool converts contributed work into credited ZEC. The observations below are starting points for investigation, not proof of a single cause.
| Observation | Possible explanation | What to check |
|---|---|---|
| Device hashrate flat, pool-estimated hashrate lower | Connectivity loss, stale/invalid shares, reduced uptime, or short-term estimation variance | Compare matching periods; review uptime, rejection reasons, and accepted work weighted by share difficulty |
| Pool-estimated hashrate flat, ZEC credited lower | Higher network difficulty, lower miner subsidy, or changes in transaction-fee income | Compare difficulty and miner subsidy across the earnings periods, then review reward components |
| Pool-estimated hashrate flat, ZEC credited lower under PPLNS | Pool luck may contribute alongside difficulty and reward changes | Compare actual blocks found with expected blocks or the pool's reported luck for the period |
| ZEC credited lower across all workers | A shared factor such as network difficulty, miner subsidy, or pool luck under PPLNS | Check network and pool conditions before attributing the drop to a subsidy change |
| Reported network hashrate chart flat, difficulty rising | Different measurement windows and short-term block-timing variance | Compare the chart's averaging period with the difficulty history for the same earnings period |
Under PPLNS, a pool pays from blocks it actually finds, allocating rewards according to eligible contributed work within its accounting window. Short-term bad luck — fewer blocks than statistically expected — can reduce credited ZEC even if effective worker contributions remain unchanged. Higher network difficulty can also lower expected block production for unchanged pool hashrate; that is a change in the expectation, rather than evidence of bad luck. ViaBTC's payment-method documentation explains that PPLNS earnings fluctuate because distributed coins depend on blocks actually mined (ViaBTC: Choosing a Payment Method).
Under PPS+, the PPS component pays for valid contributed work independently of whether the pool finds a block. This removes short-term pool-luck exposure from that component, but its theoretical value still depends on network difficulty and the applicable block reward. The "+" component covers transaction fees distributed using PPLNS-style accounting and can still vary. Confirm the active payment method in your ViaBTC account settings when interpreting earnings (ViaBTC: How are profits calculated?).
Decide what to investigate
A structured check helps identify which variable changed:
- Match the time window first. Compare credited ZEC and pool-estimated hashrate over comparable periods, rather than comparing a daily earnings figure with an instantaneous device reading.
- Check effective contribution. Review uptime, pool-estimated hashrate, rejection reasons, and accepted work weighted by share difficulty. A raw share count alone is insufficient.
- Compare network difficulty. If effective contribution is stable, higher difficulty can still reduce expected ZEC earnings, including the PPS component of PPS+.
- Verify the miner subsidy. Check the subsidy at the block heights corresponding to both periods. A broad earnings decline is a reason to investigate shared factors, not proof of a subsidy change.
- Review the payout method and reward components. Under PPLNS, check pool luck after accounting for difficulty and subsidy changes. Under PPS+, distinguish the difficulty-dependent PPS component from variable transaction-fee income.
These checks help separate a change in expected mining output from a share-quality problem, a reward-schedule change, or short-term variation in pool earnings.
FAQ
Does rising Zcash difficulty always mean the network hashrate increased?
Not necessarily in the short term. Difficulty adjusts after every block using recent targets and block timing, while displayed network hashrate is an estimate over a separately defined period. Short-term block-timing variance and different measurement windows can produce apparently divergent readings.
Why did my ZEC earnings drop even though my hashrate display looks the same?
Higher network difficulty can reduce expected ZEC earnings even when your effective hashrate is unchanged. Other possible causes include less accepted work reaching the pool, a lower miner subsidy, variable transaction-fee income, and pool luck under PPLNS. Compare matching periods and check pool-estimated hashrate, difficulty, subsidy, and the active payment method.
Does the payment method affect how much pool luck impacts my earnings?
Yes. Under PPLNS, earnings come from blocks the pool actually finds, so short-term luck affects credited ZEC. Under PPS+, the PPS component is independent of pool luck but still depends on network difficulty and the applicable reward; the transaction-fee component can vary. Confirm your active payment method in the account settings.
Can a Zcash halving reduce my earnings without any difficulty change?
Yes. A halving reduces the subsidy directly. Difficulty adjusts through a separate mechanism, so a subsidy cut can reduce expected earnings even if difficulty has not changed.
References
- Zcash Protocol Specification — proof-of-work, difficulty adjustment, and miner subsidy
- Zcash
getnetworksolpsRPC documentation - Zcash
getblocksubsidyRPC documentation - ViaBTC: How are profits calculated?
- ViaBTC: How to Choose the Optimal Payment Method (PPS+, PPLNS)?
- ViaBTC: ZEC Mining
- ViaBTC: Mining Pool Difficulty Adjustment Explained: Share Difficulty vs. Bitcoin Network Difficulty