Two shielded Zcash addresses can look unrelated and still sit behind a single incoming viewing key. That is not an edge case in the protocol's design; it is the default. Every address a shielded account generates shares the same key material, which means the practical anonymity set of a Zcash payment is bounded not by the number of addresses in circulation but by the number of accounts — a far smaller and far more concentrated quantity. Zakura, the team that maintains Zcash node and wallet software, published a design this week that would derive a fresh viewing key for every shielded address a user posts during a NEAR Intents swap. The engineering page lists the work as in review. Nothing has shipped.
Adam Tucker, who wrote the post, states the exposure plainly: until Zcash's planned Tachyon upgrade arrives, "a single published shielded address lets a quantum attacker link every payment that address's key has ever received." That sentence deserves more scrutiny than it will receive, because it describes a structural property of shielded pools rather than a defect in one wallet.
NEAR Intents is the part of the story that converts a private act into a permanent public artifact. In ordinary Zcash use, a holder hands an address privately to whoever is paying them; the address is disclosed to one counterparty and forgotten. A cross-chain swap service cannot work that way. When a user swaps ZEC for another asset, the wallet must supply a shielded refund address. NEAR publishes that address on-chain once the deposit is logged, and it remains there whether or not the user ever gets funds back. Swaps into ZEC publish the receiving address on identical terms. To a casual observer the addresses look unrelated — different strings, no visible linkage, no shared prefix. One key sits behind all of them. The chain accumulates a growing, timestamped list of distinct-looking identifiers that a single derivation collapses into one identity.
That is the forensic problem, and it predates quantum computing entirely. A classical adversary with the address list and enough patience has a clustering input. Quantum is the multiplier, not the origin.
To be precise about what leaks: an incoming viewing key decrypts the value and memo of every payment an account has received. It does not authorize spending. That distinction is why the exposure has been tolerated for so long — a viewing-key compromise is a disclosure event, not a theft event — and it is the wrong frame for a quantum threat model. Shor's algorithm applied to an exposed address does not politely stop at the viewing key. The memo field is the deeper problem: Zcash memos carry invoice references, exchange deposit tags, and free-text coordination notes. A key that decrypts memos does not merely reveal that money moved. It reveals why.
NEAR Intents publishes refund addresses for a defensible reason. An on-chain record of where a bridge payout is owed is what makes a failed swap recoverable, and the service has already demonstrated the value of that record by tracing and recovering stolen funds in a prior incident. The recovery property and the privacy property are drawn from the same ledger, and any design has to pay for both.
The fix Zakura proposes is cryptographically modest. It changes only the randomness that feeds the viewing key, deriving a fresh key per swap from a hashed index. The spending key is untouched, so funds remain in a single account. That constraint was deliberate: Tucker writes that opening a new account per swap was ruled out because Keystone hardware wallets sign only from the first account and Ledger devices spend from one account per transaction, "which wasn't an acceptable UX to us."
That single sentence is the most informative in the post. The binding constraint on Zcash privacy engineering is not the mathematics — per-address key derivation is a solved problem — but the firmware behavior of two hardware vendors. The privacy boundary of a shielded pool is currently set by a signing routine inside a secure element. I have run this class of stress test before: in 2020 I built a composability model in which each protocol's exposure was a function of a shared underlying key, and the failure mode was always identical — the system looked diversified at the address layer and was singular at the key layer. Liquidity is the pulse; policy is the brain. In shielded pools, key derivation is the policy, and it is being written by hardware teams who have never published a roadmap.
The restore path is where the design earns its complexity. More viewing keys normally means a slower wallet restore from seed, because each key requires its own full chain scan. Zakura's approach leaves the wallet an encrypted memo recording each swap's index, checks published filters, then uses private information retrieval to locate matching NEAR bridge payouts without the server learning which addresses were queried. For swaps into ZEC, the wallet walks addresses in sequence and halts after 30 unused ones in a row — a gap limit borrowed from Bitcoin's HD wallet conventions, carrying the same failure mode: a user who generates 31 consecutive unused addresses silently loses the ability to detect the 32nd.
Zakura expects software wallets built on its libraries, Vizor among them, to integrate the change "in the coming weeks." Hardware wallets follow "once their firmware supports it." No date is offered. The firmest commitment in the document is a software timeline; the harder dependency has none. The Tachyon upgrade is meant to retire this entire class of workaround by changing how shielded state is committed. Until it ships, every mitigation is a patch applied to a construction that is scheduled for replacement.
Here is what the framing obscures. Per-swap viewing keys fragment the blast radius of a future quantum adversary across many keys, which is real progress against the stated threat. But the spending key is unchanged by design, and the encrypted memo index that makes restore tractable is itself a linkage spine — one list, in one wallet, that reconstructs the entire set of swap indices. Compromise that memo through device seizure, a wallet bug, or a key-recovery advance, and the fragmentation reverses in a single step. The design trades a public linkage for a private one. It does not eliminate the linkage. Value is a consensus, not a fundamental truth; so is anonymity, and both are being repriced here without anyone announcing the trade.
The second blind spot is adoption asymmetry. Address publication is enforced by NEAR's bridge contract; key derivation is enforced by wallet software. Users on a Ledger device, or on any wallet that has not shipped the update, keep publishing addresses that share one key. The privacy improvement therefore accrues only to the cohort that upgrades first — and in a system where linkage is cumulative and permanent, partial adoption does not halve the leak. It leaves the leak fully intact for the un-upgraded and adds a new class of distinguishable per-swap-key users on top of it.
Zcash has spent a decade arguing that shielded transactions should be the default, then letting wallet ergonomics decide whether the argument wins. Zakura's proposal is the right shape: it accepts the hardware constraint instead of fighting it, and it keeps the spending key stable so the user experience does not regress. But the timeline locates the actual leverage — with firmware teams holding no public commitment, and with a Tachyon upgrade that has not yet removed the need for the workaround at all. The question worth asking is not whether per-swap viewing keys close the gap. It is why, in the third year of an institutional bull market, the privacy of a cross-chain swap is still being negotiated inside a signing routine.
