Zcash Plans to Shield Payment History From Quantum Attacks

Zcash developers want to stop a public swap address from exposing unrelated incoming payments to future quantum attacks. The proposed protection still needs cryptographic review.
Zakura has published an experimental implementation that gives swap addresses separate incoming viewing keys while retaining the account’s spending authority. Its October 15 release candidate says the key derivation requires review before live addresses are issued.
Key Takeaways
- Different swap addresses can share access to the same incoming-payment history.
- The proposal separates their viewing keys without creating separate spending accounts.
- Private lookups help restored wallets locate payments without revealing address ownership.
A refund address can expose more than one swap
Swapping ZEC through NEAR Intents requires an address for returning unused funds. In an engineering explanation, Zakura’s Adam Tucker says this shielded refund address is recorded on NEAR’s public blockchain when the deposit registers, even if no refund follows. Swaps into ZEC also publish the receiving address.
These addresses can look unrelated while sharing one incoming viewing key. Recovering that key could therefore reveal receipts beyond the swap itself.
The attack described requires a sufficiently capable future quantum computer to recover the key from an exposed address. It could then identify incoming payments associated with that key, including amounts and memos. The proposal addresses that future confidentiality risk, rather than reporting an attack already taking place.
Separate viewing keys would keep the spending account intact
Zcash distinguishes viewing authority from spending authority. Its wallet key-derivation standard supports deriving keys and addresses from a single seed, allowing wallets to manage multiple addresses without requiring a separate backup for each one.
Simply generating another address does not necessarily create an independent incoming viewing key. Zakura’s proposed change operates behind the address: it derives a separate viewing key for each swap refund or incoming swap.
The implementation preserves the account’s spending authority. A user could spend funds received through those separate swap keys from the same account, avoiding the operational burden of splitting balances across many accounts.
What changes behind the address
Shared viewing key: Recovering one key can expose incoming payments across several addresses.
Separate swap keys: Recovering one swap’s viewing key would expose receipts tied to that key without automatically opening unrelated incoming payments.
A viewing key does not itself authorize spending. The intended protection is narrower: limit the payment history that one compromised key can reveal.
Recovery must find payments without revealing ownership
Separate keys create a discovery problem when a wallet is restored. Regenerating keys from a seed does not tell the wallet which ones received payments. Trying every swap key against the entire transaction history would increase recovery work with each additional swap.
Outbound swaps provide a place to leave a recovery record. The proposed implementation puts an encrypted memo in a note belonging to the user’s funding transaction. That memo records the index used to derive the refund key. During restoration, the wallet can recover the index and reconstruct the corresponding key and address.
Incoming swaps need another approach because the Zcash wallet did not create a funding transaction in which to leave that memo. The design instead checks deterministically derived addresses in sequence, using records of addresses paid or already disclosed to the swap provider to determine how far discovery must continue.
To locate payments, the receiver-discovery system uses public filters that the wallet checks locally. A possible match leads to a private information retrieval request, or PIR, which identifies the relevant transaction without sending the server a readable query naming the address.
The wallet can then decrypt the payment with its corresponding viewing key. This avoids making each recovered key perform a separate search across the entire chain.
Private queries also prevent a readable series of lookup requests from revealing that several addresses belong together. Otherwise, a server could receive requests for address A, then B, then C and associate them with one wallet, undermining some of the separation created by the new keys.
Review and wallet support remain unfinished
The experimental code does not establish that wallets have enabled the feature for ordinary users. Cryptographic review remains outstanding, and the implementation specifies that hardware signers need firmware qualification before one-time keys are enabled for hardware accounts.
Zakura’s engineering post anticipates integration into compatible software wallets, including Vizor, in the coming weeks. That is a development estimate, not a confirmed release date.
This work is separate from January’s planned protections for transparent Zcash payments, which concern payment authorization. The swap proposal concerns the privacy of shielded incoming-payment history.
New derivation also cannot remove addresses already recorded publicly. Isolating future swap keys would not erase earlier disclosures tied to an existing shared viewing key.
The remaining delivery work is specific: review the derivation, integrate payment discovery and restoration, and qualify supported signers. Those steps must be completed before users can rely on the proposed separation in a released wallet.
This article is provided for informational purposes only. The proposed feature is experimental and requires further review before live use.









