Ask whether a quantum computer threatens Zcash mining and you will get an argument about Grover's algorithm and hashrate. That argument has a clear answer, and the answer is no. Proof-of-work is not where mining is exposed.

The exposure is custody. A miner accumulates ZEC into an address, and that address is protected by elliptic curve cryptography, which is the one thing a quantum computer is genuinely good at breaking. This is worth understanding because the fix is free, takes minutes, and most miners have not done it.

How a transparent Zcash address is actually exposed

Zcash's transparent layer is Bitcoin's. A t1 address is pay-to-public-key-hash, a t3 is pay-to-script-hash, both Base58Check encoded, with Bitcoin-style scripting and opcodes. Inheriting that design means inheriting its quantum properties exactly.

The property that matters is this: in pay-to-public-key-hash, the address is a hash of your public key, not the public key itself. The public key stays off the chain until the first time you spend, and spending reveals it.

Address stateWhat is on the chainWhat an attacker needsRealistic?
Never spent fromA hash of the public keyTo reverse a hash, which needs Grover, a square-root gain onlyNo. Grover does not parallelise and the target stays enormous
Spent from at least onceThe public key, in the clearTo solve the discrete log, which is Shor's algorithm working on its home turfNot today. This is the one that eventually matters

So an address you have received to but never spent from exposes only a hash. The moment you spend, the public key is published permanently, and from then on that address is protected by elliptic curve hardness alone.

For a miner, that pattern is the problem. Mining produces a stream of payments into one address you keep using, and the first withdrawal publishes the key that protects everything that arrives afterwards.

The part Zcash already solved, quietly, in consensus code

Here is something most miners do not know: Zcash protects the block finder automatically, and has since before shielded coinbase existed.

Before the Heartwood upgrade, the protocol was blunt about it. A coinbase transaction was forbidden from containing shielded outputs at all, so every block reward was paid to a transparent address. To compensate, a second rule required that transparent coinbase be spent only into shielded addresses. Miners called it the "coinbase must be protected" rule, and it made shielding mandatory rather than optional.

ZIP 213 changed the first half at Heartwood by permitting Sapling output descriptions in coinbase transactions, so a block reward can now be paid directly into a shielded address. The second half survives: transparent coinbase outputs still carry a 100-block maturity requirement, and a transaction spending transparent coinbase must still have empty transparent outputs, which is the consensus way of saying it has to go shielded.

Net effect for a solo miner: whether you take the shielded coinbase route or the transparent one, Zcash consensus pushes your block reward into the shielded pool. Bitcoin has no equivalent. A Bitcoin miner's coinbase can sit in a reused transparent address forever, and plenty do.

The gap: that rule does not cover pool payouts

This is the point of the article, and it follows directly from how the rule is written.

The consensus requirement applies to coinbase outputs. When you mine in a pool, the coinbase belongs to the pool, because the pool's address is what goes into the block it found. Your payout is something else entirely: an ordinary transaction from the pool's wallet to your address, no different in protocol terms from any other payment.

Ordinary transactions carry no shielding requirement. So:

  • Solo miner: consensus forces your reward into the shielded pool. Protected by default, no decision required.
  • Pool miner: your payout is a normal transaction to whatever address you configured. If that is a t-address you have ever spent from, your public key is published and stays published.

Given that the overwhelming majority of Zcash hashrate mines in pools, the protection Zcash built into consensus does not reach most of the people mining it. Not because the rule is weak, but because pool payouts are outside its scope by construction.

What to actually do, which costs nothing

  1. Set your pool payout address to a shielded address. Most Zcash pools support paying directly to a z-address or a unified address. This is the single change that matters, and it takes one settings edit.
  2. If your pool only pays to t-addresses, treat that address as a doorway, not a vault. Sweep to shielded on a schedule rather than accumulating a balance in a t-address you keep spending from.
  3. Stop reusing a t-address you have spent from. Once it has published its public key, every future coin sent there sits behind elliptic curve hardness alone. A fresh address restores the hash-protected state.
  4. Do this now rather than later, because the exposure is retroactive. A public key published in 2026 is public in 2046. You cannot un-publish it. Moving coins later helps only the coins you move.

None of this requires new hardware or new software, and all of it is worth doing for ordinary privacy reasons regardless of quantum computing. A reused transparent payout address already tells chain analysts your total mining revenue.

How far off is the attack, really?

Worth anchoring against measurement instead of forecast, because the gap is large and specific.

The quantum computing as a service platform Zero Kelvin Simulation Foundry ran Shor's algorithm against real elliptic curves and published exactly which keys it recovered and where it stopped. Since Zcash's transparent layer inherits Bitcoin's curve, those figures apply to your t-address directly:

  • Private keys of 3, 4, 5, 6 and 7 bits recovered from their public keys, using 9 to 21 qubits
  • Two-qubit gate counts rising from 328 at 3 bits to 235,470 at 7 bits, roughly five times per additional bit. Width grew slowly, depth ran away
  • A 3-bit key survived 99.0 percent gate fidelity; a 4-bit key needed better than 99.8 percent. One extra bit moved the requirement from most devices to only the best
  • A real 256-bit key needs on the order of 2,304 logical qubits. Nothing close to that exists

That is the standard worth holding every quantum headline to, and the same provider applies it across a set of industry benchmarks it describes as measured rather than claimed, cryptography among them. Whether a number came from a run or from a roadmap is usually the only question that matters.

Checking this yourself is cheap, which is the point of quoting it. On published quantum cloud list prices, simulation runs at a fraction of a cent per job, and real hardware is rented by the shot: about $0.30 per task plus $0.000425 per shot on Rigetti's 108-qubit Cepheus, or $0.30 plus $0.00145 per shot on IQM Garnet. Roughly $20 buys 46,000 shots. That is less than a day of electricity on a single Z15 Pro.

The short version

  • Is your hashrate at risk? No. Grover does not parallelise and Equihash is memory-hard, so proof-of-work is the safe part.
  • Is your payout address at risk? Eventually, if it is transparent and you have spent from it, because that publishes the public key permanently.
  • Does Zcash protect miners? It protects the block finder, through the consensus rule that transparent coinbase must be spent into shielded addresses. Pool payouts are ordinary transactions and fall outside that rule.
  • What should you do? Point your pool payout at a shielded or unified address. It is free, immediate, and it also stops chain analysts reading your revenue.