The Centralization Crisis in Zcash Mining
Zcash has some of the strongest privacy technology in cryptocurrency, yet its mining infrastructure tells a different story. In September 2023, ViaBTC briefly controlled 53.69% of the Zcash network hashrate — a concentration severe enough to draw coverage from Bloomberg. That was not an anomaly. It was a symptom.
Today, four mining pools control roughly 84% of all Zcash hashrate. ViaBTC holds approximately 46%, F2Pool around 24%, 2Miners near 9%, and AntPool about 5%. This level of concentration means that a small number of pool operators make decisions that affect the entire network — which transactions get included in blocks, how quickly the mempool clears, and whether the network’s privacy guarantees are actually honored.
The consequences of this concentration are not theoretical. F2Pool has been censoring shielded transactions since April 2017. Over a period of years, F2Pool mined only about 120 blocks containing shielded transactions out of an expected ~86,849. When confronted, the pool operator attributed the omission to “laziness” — their pool software, dating back to 2016, simply never implemented the code to compute merkle roots for shielded transactions. Whether the cause was negligence or intent, the effect was the same: a quarter of the network’s hashrate was systematically excluding privacy-preserving transactions.
This matters more now than ever. Over 30% of ZEC is held in shielded addresses, up from 11% in early 2025. The demand for Zcash’s privacy features is growing, but the mining infrastructure has not kept pace. Miners using these pools have no ability to override the pool’s transaction selection. They contribute hashpower, but they have no voice in what goes into the blocks they help produce.
The disconnect was made painfully clear during the 2024 development fund signaling process. Not a single miner participated. When asked about enabling miner signaling, ViaBTC responded that it was “not possible” with their current infrastructure. The protocol that was supposed to give miners a say in Zcash governance could not reach them through the pools they were mining on.
What Bedrock Provides
Bedrock is a ground-up implementation of Stratum V2 for Zcash, designed to address each of these problems at the protocol level. It is not a patch on top of legacy mining software. It is a new foundation.
Stratum V2: A Modern Binary Protocol
The original Stratum protocol, designed over a decade ago, uses JSON-over-TCP. Every message — job assignments, share submissions, difficulty adjustments — is serialized as human-readable text, parsed on both ends, and sent without encryption. It works, but it wastes bandwidth and exposes every message to inspection and tampering.
Bedrock implements the Stratum V2 binary protocol, adapted for Zcash’s Equihash proof-of-work. Binary framing reduces bandwidth by approximately 60% compared to JSON. For mining operations at scale, this translates directly to lower operating costs and faster job delivery. The protocol handles Zcash-specific requirements including 32-byte nonces, 1,344-byte Equihash solutions, and the 140-byte input headers that Equihash demands.
Job Declaration: Miner-Controlled Transaction Selection
Job Declaration is the feature that directly addresses the centralization problem. It allows miners to select which transactions appear in the blocks they mine, rather than accepting whatever the pool provides.
Bedrock supports two modes. In Coinbase-Only mode, the miner customizes the coinbase transaction output while the pool provides the transaction set — a moderate step toward decentralization. In Full-Template mode, the miner runs their own Zcash node (Zebra), constructs the entire block template including transaction selection, and submits it to the pool for validation. The pool’s role is reduced to coordinating work and distributing rewards.
Full-Template mode means that no pool operator can censor shielded transactions for miners running Bedrock. If a miner’s node includes a shielded transaction in its template, that transaction will be part of the block the miner works on. The pool cannot override it.
FORGE: Compact Block Relay
FORGE (Fast Optimistic Relay with Grouped Erasure-coding) is Bedrock’s block propagation layer. When a miner finds a valid block, every millisecond of propagation delay increases the risk that another block is found first, rendering the original block stale.
FORGE uses compact block encoding combined with Reed-Solomon forward error correction to propagate new blocks across the network in sub-second time. Rather than transmitting the full block, FORGE sends only the compact representation — block header plus short transaction IDs — along with FEC shards that allow reconstruction even if some data is lost in transit. The result is propagation latency measured in hundreds of milliseconds rather than seconds.
Strata: Observability from the Ground Up
Mining operations generate continuous streams of data — share rates, job latencies, difficulty adjustments, connection health, block submissions. Strata is Bedrock’s observability layer, built around Prometheus metrics, structured logging, and OpenTelemetry tracing.
Strata exposes per-miner metrics including share submission rates, solution validation times, and difficulty targets. Pool operators get dashboards showing hashrate distribution, block find rates, and payout tracking. Every component in the stack — from the template provider polling Zebra to the share processor validating Equihash solutions — emits structured telemetry.
Noise_NK Encrypted Transport
All communication between miners and pools in Bedrock is encrypted using the Noise_NK handshake pattern with X25519 key exchange and ChaCha20-Poly1305 authenticated encryption. This prevents ISPs, network intermediaries, or co-located infrastructure from inspecting or modifying mining traffic.
Encryption is not optional. It is part of the protocol. This eliminates an entire class of attacks where an adversary between a miner and a pool could redirect hashpower, steal shares, or manipulate job assignments.
Why Now: The 25-Second Block Time Proposal
Zcash is considering reducing its block target time from 75 seconds to 25 seconds. This would follow the precedent set by the Blossom network upgrade, which halved the block time from 150 seconds to 75 seconds. A further reduction to 25 seconds would increase transaction throughput and reduce confirmation latency.
But faster blocks demand better infrastructure. At a 25-second block target, propagation latency becomes a much larger fraction of the inter-block interval. With legacy infrastructure, models project stale block rates around 3.9% — meaning roughly 1 in 25 blocks would be orphaned, wasting miner energy and reducing effective security. FORGE brings that stale rate to below 1%.
Job latency matters just as much. When a new block is found, miners need to receive updated work as quickly as possible. With Stratum V1 over JSON, typical job update latency is around 228 milliseconds. With Bedrock’s Stratum V2 binary protocol combined with Job Declaration, that drops to 2.4 milliseconds — nearly 100x faster.
Strata’s sub-second observability becomes critical at 3x the current block frequency. Operators need to detect anomalies, track performance, and respond to issues on a tighter timeline. Strata provides that visibility.
Getting Started
Bedrock is open source, developed in public, and designed for the Zcash community.
- Documentation: Read the operator guides and protocol reference to understand the architecture and deployment options.
- Source code: The full implementation is available at github.com/iqlusioninc/stratum-zcash.
- Community: Join the discussion on the Zcash Community Forum to share feedback, report issues, or contribute.
Whether you are a solo miner looking to run your own transaction selection, a pool operator evaluating Stratum V2, or a developer interested in Zcash mining infrastructure — Bedrock is built for you.