Introduction
This report reviews Zcash network hashrate readings available on September 9, 2026, and explains how to interpret mining-pool distribution during an incomplete reporting month. It is a September 2026 month-to-date update, with the September 9 observation treated as provisional.
Three datasets matter here: estimated network hashrate, a pool’s share of attributed blocks over a defined period, and a pool’s self-reported hashrate. They describe related aspects of mining activity, but their measurement windows and calculation methods differ. Keeping them separate helps readers distinguish changes in network estimates from changes in observed pool block production.
A verified pool-distribution dataset for an exact September month-to-date window was not available for this update. Accordingly, no September pool ranking or pool-share percentages are presented.
Zcash Network Hashrate: Early September Readings
CoinWarz’s Zcash hashrate history displayed the following dated estimates at the time of review:
| Date (UTC) | Estimate as displayed by CoinWarz | Status |
|---|---|---|
| September 1, 2026 | 24.7 GH/s | Historical daily entry |
| September 8, 2026 | 27.9 GH/s | Historical daily entry |
| September 9, 2026 | 26.6 GH/s | Provisional current-day entry |
Unit note: The table preserves CoinWarz’s displayed GH/s label. Zcash mining power is normally expressed in solutions per second (Sol/s), with GSol/s denoting billions of solutions per second. The source’s unit mapping could not be independently confirmed, so these values have not been relabeled as GSol/s. Zcash solution-rate documentation.
Using the displayed September 1 and September 8 values:
Percentage change = (27.9 ÷ 24.7 − 1) × 100 ≈ 13.0%
This compares two dated estimates; it is not a month-to-date average. The source does not establish whether each daily entry is an average or a closing observation. Separately, CoinWarz lists a September 8 peak of 29.0 GH/s in its stored history, distinct from that day’s 27.9 GH/s entry. CoinWarz.
What the Hashrate Change Means
Network hashrate is estimated rather than obtained by counting mining machines. Zcash’s getnetworksolps documentation describes an estimate calculated over a specified number of recent blocks. This establishes how that RPC works; it does not establish the exact sampling method used by every data provider. Zcash RPC documentation.
Estimated hashrate can reflect both changes in actual mining power and variability in block discovery and estimation. Zcash targets an average block interval of 75 seconds, but individual block intervals vary. Different observation windows can therefore produce different readings. ZcashInfo’s estimation guide.
The figures alone cannot determine how much of the September increase came from additional mining power. A 13.0% increase in the displayed estimate does not establish that miners installed 13.0% more equipment.
For trend analysis, compare observations from the same provider using the same method and equivalent periods. A daily average, a point-in-time observation, and an intraday peak answer different questions. Their dates alone do not make them directly comparable. Until the aggregation method is clear, the dated entries above support a limited comparison of the source’s reported readings.
How Pool Distribution Should Be Measured
A useful measure of observed pool distribution is each pool’s share of blocks within a defined window:
Pool block share (%) = blocks attributed to that pool ÷ all blocks in the same window × 100
A September MTD breakdown can validly cover September 1 at 00:00 UTC through a specified cutoff. It describes that elapsed period, without predicting the final month’s distribution. A rolling seven-day or one-month ranking should not be labeled September MTD unless its boundaries match.
Any such breakdown should give the UTC window, total block count, per-pool counts and percentages, and an Unknown category. Unknown blocks remain in the denominator. Shorter windows can show more variation in realized block shares, particularly for smaller pools. ZcashInfo’s estimation guide.
For a full September report, the window would begin at September 1, 2026, 00:00 UTC and end immediately before October 1, 2026, 00:00 UTC. For an MTD report, the end boundary would instead be the stated cutoff. In either case, the numerator and denominator must use the same period and the same set of canonical-chain blocks.
ZcashInfo’s attribution methodology uses coinbase identifiers, software patterns, address continuity, and supporting on-chain evidence. These labels involve inference; blocks without sufficient evidence remain Unknown, and attribution can be revised as evidence improves.
The lack of a chart in this update is a data-verification limitation, not a restriction on reporting partial months. A verified MTD chart would be appropriate. Month-end would make the calendar window complete, but would not guarantee that every block could be assigned to a named pool.
What Pool-Share Data Can — and Cannot — Show
Pool block share describes attributed block production. It does not establish who owns the contributing hardware, where miners are located, or how many individual miners participate. A pool’s dashboard hashrate is a separate statistic with its own reporting window and accounting method. Even when windows match, observed block share can differ from a pool’s proportion of network mining power because block discovery varies.
A distribution chart can therefore describe how concentrated observed block production was among identified pool labels and Unknown blocks. It cannot, by itself, establish concentration of hardware ownership or explain whether participating miners could redirect their mining power elsewhere. These are different questions that require different evidence.
Similarly, a pool’s block share does not measure an individual miner’s earnings. The miner’s accepted work, chosen payment method, and applicable fees must also be considered. Reading a larger pool percentage as a promise of higher personal returns would go beyond what the distribution data show.
What ZEC Miners Should Monitor
Network Conditions and Accepted Work
For day-to-day operations, review network difficulty alongside your own accepted mining work and ZEC earnings. Keep these separate from pool settlement timing: expected block discovery and mining earnings depend on mining conditions, while settlement follows the selected payment method and pool rules.
Check worker connection status and rejected-share trends. If rejections increase, examine the reported reasons rather than assuming every rejected share has the same cause.
Use matching periods when comparing worker performance and credited earnings. A brief connection interruption and a full day’s earnings are different observations; the effect depends on how much work was accepted over the relevant accounting period. Pool block-share rankings alone cannot diagnose whether a particular worker is submitting work successfully.
Payment Method and Account Settings
ViaBTC introduced PPS+ for ZEC mining on January 9, 2026. Its announcement states that new accounts default to PPS+, while existing accounts retain their selected method unless changed. ViaBTC announcement.
Under PPS+, the PPS component pays theoretical earnings for valid shares using current network difficulty; transaction fees are distributed separately under PPLNS. PPLNS earnings depend on the pool’s block discoveries and the miner’s contribution within the relevant share window. PPS+ therefore reduces miners’ exposure to pool luck for the PPS component, but it does not guarantee an unchanging amount of ZEC income. ViaBTC payment methods and fees.
This distinction matters when interpreting changes in credited earnings. The PPS share value can change with network difficulty, while PPLNS results also reflect the pool’s actual block production. Settlement and withdrawal are separate steps, so the timing of an external transfer should not be confused with the period in which mining earnings were calculated.
Before changing payment methods or reconnecting hardware, confirm your selected method, current fees, withdrawal settings, and official connection details. Consult ViaBTC’s mining-pool documentation for connection information.
FAQ
Is this a complete September 2026 report?
No. It is a month-to-date hashrate update checked on September 9. The current-day reading is provisional, and no verified September pool-distribution breakdown is included.
Does rising estimated hashrate prove that more mining machines came online?
No. Actual mining-power changes and estimation variability can both affect the reading. The percentage change alone cannot establish a corresponding change in equipment numbers.
Can pool distribution be reported before month-end?
Yes. A clearly defined month-to-date window supports valid reporting of observed block shares. It should not be presented as the completed month’s result or a forecast of it.
Can pool block-share data identify the owners of mining hardware?
No. Pool labels indicate the source’s attribution of blocks. They do not identify the individual miners or owners of the equipment contributing to that pool.
Does a pool’s live dashboard hashrate equal its monthly block share?
No. Dashboard hashrate measures or estimates mining work over the pool’s reporting window; monthly block share describes the proportion of blocks attributed to that pool over a calendar month. Compare their windows and methods before drawing conclusions, and allow for variation in block discovery.
References
- CoinWarz, Zcash Hashrate Chart
- Zcash, getnetworksolps RPC Documentation
- ZcashInfo, How Solrate Is Estimated
- ZcashInfo, Pool Attribution Methodology
- ViaBTC Help Center, ViaBTC Now Supports PPS+ Payment Method for ZEC Mining
- ViaBTC, Payment Methods and Fees
- ViaBTC Help Center, Mining Pools Information


