Zcash Mining

Key Facts

• ZIP 301 documents Equihash 200/9 in the Zcash Stratum mining and pool-server context.
• ZIP 68 records the post-Blossom 75-second target block spacing; real block intervals can still be uneven.
• Zcash's published economics describes a current 1.5625 ZEC block subsidy, which is separate from transaction fees and a miner's net result.
• The Field Guide shows a completed ZcashInfo 24-hour provider-labelled pool window as raw attribution, not a hashrate census, ownership map, reliability score, or pool ranking.
• Network difficulty is a consensus-work measurement. It is not a count of mining machines, people, electricity consumption, or identifiable operators.

What Zcash mining actually does

A Zcash miner competes to produce a block that satisfies the network's current proof-of-work target. If the block is valid under consensus rules, it can be added to the public chain and become part of the shared record that full nodes verify. That is the core job. Mining is not a privacy feature by itself, not a wallet, and not a promise that a particular machine will earn a predictable amount of ZEC.

For the current Stratum context, ZIP 301 names Equihash 200/9. Stratum is the protocol layer that connects mining clients to a pool server; it is not a universal statement about any pool's custody, payout formula, or trustworthiness. A pool can use a common protocol and still have materially different fees, reward methods, geographic infrastructure, policies, and account-security risks. The word mining pool describes coordination around work and rewards. It does not magically remove the need to inspect the operator's current terms.

The cleanest mental model is public work against a moving target. The target is a consensus condition. Difficulty expresses how demanding that condition is at the network level. A valid block proves that the accepted candidate met the required condition. It does not reveal the identity of the person, company, location, hardware, or power contract that produced it. It also does not show whether the producing setup was profitable after every cost and every pool rule.

That boundary matters because mining pages often turn a few public numbers into a confident profitability story. Difficulty, a ZEC price, and a nominal block reward are not enough to do that honestly. A real calculation needs hardware efficiency, actual electrical pricing and tariff structure, cooling and hosting costs, downtime, pool fee and payout method, worker-side rejection rate, share variance, exchange or custody costs, taxes, and the possibility that every relevant input changes. This guide refuses to manufacture an ROI number from a thin slice of that reality.

Equihash, difficulty, and the 75-second target are different facts

Equihash 200/9 is the proof-of-work parameter context documented in ZIP 301. It describes the kind of work miners are trying to perform for Zcash's Stratum protocol. Difficulty is the current network-level condition attached to that work. The two ideas are related, but they answer different questions: the algorithm tells you what kind of puzzle is in play; difficulty tells you how demanding the current target is. Neither one tells you how many individual miners exist.

The 75-second target block interval sits beside both. ZIP 68 records the shorter post-Blossom target spacing. A target is a protocol design cadence, not a stopwatch guarantee. Blocks arrive probabilistically. Some intervals are shorter, some longer, and a small observation window can look unusually fast or slow without proving that consensus is broken. For that reason, the Field Guide labels the 75 seconds as a target and labels the provider's recent block count as an observed source window. It never silently turns one into the other.

You may see network hash-rate estimates elsewhere. Those are estimates derived from recent block work over a selected window, not a field census of devices. The legacy Zcash RPC documentation for getnetworkhashps explicitly describes an estimate based on the last n blocks and marks that RPC as deprecated in favor of getnetworksolps. The caveat is the useful part: an estimate can help describe recent network work, but it cannot identify physical equipment, ownership, or energy use. House of Zcash withholds the secondary aggregate whenever its chain tip is stale rather than showing a number that only looks live.

Difficulty also does not say whether a chain is decentralized enough for every reader's preference. Public work can be broadly distributed, clustered in one operator, temporarily routed through a pool, or labelled imperfectly by an indexer. A serious decentralization analysis needs definitions, a credible observation method, and a clear statement of what it cannot see. It is not the same thing as sorting a 24-hour pool table.

Block subsidy is protocol issuance, not a miner's take-home pay

Zcash's published economics describes a maximum 21 million ZEC supply, a roughly 75-second target cadence, and a current block subsidy of 1.5625 ZEC. The subsidy is protocol issuance associated with a block. It belongs in an explanation of mining because it is the scheduled issuance layer that miners and funding streams relate to. It does not by itself answer what a pool participant receives, whether a machine has paid for itself, or what ZEC is worth in another currency.

The current active allocation also needs the right scope. Under the NU6.1-era rule described by Zcash's official economics material, 80% of the block subsidy goes to miners, 8% to Zcash Community Grants, and 12% to Coinholder Funding through the lockbox. That is a policy fact about the subsidy. It is not an all-in payout calculation and it does not erase transaction fees, pool fees, share accounting, orphan risk, payout thresholds, or an individual miner's costs. The Zcash Issuance page keeps that policy layer visible in more detail.

An observed block reward can differ from a bare subsidy reading because transaction fees are a separate part of a block's economics. It is tempting to look at the last block and call that figure 'the block reward' in every context. The better language is precise: one number is the current scheduled subsidy; another is the total observed reward for that block; a third is the amount a specific pool distributes after its own terms. Collapsing those numbers creates a clean headline and a dirty explanation.

The same discipline applies to market price. A ZEC price changes the currency value of revenue, but it does not change the proof-of-work condition or remove costs. Treat price as an external, volatile input rather than as the center of a mining explainer. Anyone considering a real deployment should build their own model from vendor-grade hardware data, local power terms, documented pool policies, and a conservative failure case.

How to read the pool-attribution window without inventing a ranking

The Mining Field Guide reads the ZcashInfo mining-pools endpoint at build time and validates that each returned row reconciles with the provider's completed 24-hour total. The visible table uses the provider's own pool labels, the block counts, and a derived share of that exact window. If the provider returns an unnamed row, the site says 'Unattributed / unnamed' instead of pretending that every block belongs to a known pool. That is a small but important honesty check.

This is block attribution in one source window, not a pool recommendation. A provider label may be incomplete, may aggregate several operations, may identify a service rather than an owner, or may change as the provider changes its methodology. A 24-hour share can move sharply because blocks are lumpy, a participant can redirect work, an operator can change routing, or the window itself rolls forward. None of that tells a reader the pool's fee, uptime, jurisdiction, security controls, custody model, customer support, or the identity of everyone contributing work.

It also cannot prove a pool's percentage of global hash power. Block counts are a practical observation, but they are not a transparent census of every actor behind the label. The Field Guide therefore calls the leading row 'largest labelled record' rather than 'best pool' or 'dominant miner.' That wording is deliberate. It reports what the source returned without smuggling a recommendation into the interface.

If you are comparing a real pool, use the source window as a starting point, then examine the pool's own current documentation. Look for its reward method, fee schedule, payout threshold, supported connection details, account-security model, privacy policy, maintenance record, legal terms, and incident history. Do not disclose a seed phrase, private key, wallet file, or full viewing key to a pool or a web page in the course of that research. A mining pool should need a payout address or worker credential according to its documented setup, not recovery material.

A practical evidence checklist for miners and researchers

Start by saying what question you are actually asking. 'How does Zcash proof of work work?' calls for protocol records such as ZIP 301 and ZIP 68. 'What is the current block subsidy?' calls for the official monetary schedule. 'How did this provider label blocks in the last 24 hours?' calls for a dated pool-attribution endpoint. 'Will this setup make money?' calls for private operating inputs that this public site does not have. Different questions require different evidence, and a single dashboard cannot answer all of them.

Next, preserve the observation time. Mining numbers decay quickly. The pool window on this site is a build-time snapshot with its source URL and timestamp; the browser does not query an explorer or pool on your behalf. That is more privacy-respecting and more reviewable than a fake blinking-live widget. When the source is stale, the proper response is to refresh and re-check, not to infer a current condition from an old label.

Then separate consensus evidence from business evidence. A valid block, current difficulty, and target spacing belong to the public protocol layer. Hardware availability, power price, contractual terms, hosting, taxes, and pool operations belong to the deployment layer. The public layer can teach you how a system works. It cannot take responsibility for a buyer's lease, electricity bill, account, or payout address.

Finally, keep the privacy boundary intact. Zcash is a privacy-preserving cryptocurrency, but proof of work does not hide off-chain metadata. Mining or pool participation can still involve IP addresses, account identifiers, payout records, exchange activity, and local operational traces. A shielded payment path has its own protocol and wallet requirements. Do not promise a privacy outcome from mining alone, and do not hand secrets to a website that claims it can optimize or verify your operation remotely.

Method and review contract

The Mining Field Guide is built from a server-side source snapshot. It records the primary ZcashInfo chain height and difficulty, a completed 24-hour ZcashInfo pool-attribution response, and official protocol and economics documents. It validates that the returned pool rows reconcile with the total block count before the data can reach the page. The browser does not connect to a miner, pool account, wallet, address, API key, worker, or node.

The three lenses change the explanation, not the underlying source contract. Network Work distinguishes Equihash, difficulty, and target spacing. Block Economics separates the current subsidy from transaction fees and profitability. Pool Window exposes the provider's raw labels and their limits. The complete evidence matrix remains server-rendered for readers and crawlers even when a visitor never opens the detail control.

This page has a 30-day review window. A change to the protocol record, active subsidy, allocation, provider response shape, or material source methodology requires review. Until then, this is a dated research reference. It is not an ASIC recommendation, a pool endorsement, a financial model, an availability guarantee, or a claim that public labels reveal the people behind the work.

FAQ