Zcash Developers Propose Quantum Privacy Fix for NEAR Swaps

NEAR swaps expose Zcash refund addresses

NEAR Intents lets applications arrange exchanges across blockchains through competing execution providers called solvers. Moving value between networks also moves information between systems with different privacy properties.

Zakura identifies refund addresses for outgoing ZEC swaps and recipient addresses for incoming ZEC swaps as exposure points. A refund address becomes public when the deposit registers, even if the swap succeeds and no refund is needed. Different-looking addresses can still share one underlying viewing key.

The distinction between an address and its key is central. Changing the visible address is insufficient if the secret that reads incoming payments remains the same. An attacker recovering that shared secret could connect payments that otherwise look unrelated.

Zcash cofounder Sean Bowe’s explanation of quantum privacy says shielded transactions retain privacy in many ordinary cases, but identifies possession of the payment address as an important exception. A sufficiently capable quantum adversary changes the assumptions behind elliptic-curve protections.

An incoming viewing key reveals payment information, including amounts and memos. That is different from spending authority. The distinction does not mean Zcash is immune to every quantum threat: Bowe separately discusses risks to the validity of proofs and the possibility of counterfeiting.

As of 09:07 UTC October 19, the developer material and reporting reviewed for this article did not identify a demonstrated quantum attack, attributable theft total, victim count or attack wave for this issue. The assessment concerns a future privacy exposure, not a confirmed fund-draining incident.

That places it alongside wider preparation such as Coinbase’s Bitcoin quantum-custody work, while addressing a different consequence. Payment-history confidentiality and unauthorized spending require separate assessments.

One-time viewing keys retain spending authority

The proposed change keeps the account’s spending key and creates a separate viewing key for each exposed swap address. Its intended benefit is containment: one recovered viewing key would no longer serve as a window into the entire account’s incoming payment history.

Zakura proposes varying a randomness component used to derive the viewing key, with a purpose and an index distinguishing swaps. The components responsible for signing and tracking spent notes remain unchanged. This is intended to preserve a single spendable account while separating the information that each published address can reveal.

The underlying wallet model already separates different kinds of authority. Zcash’s ZIP 32 standard defines deterministic shielded-wallet key trees derived from a seed, allowing viewing and spending capabilities to be handled separately without giving away the master seed.

That architecture also explains why recovery belongs in the design. A wallet backup must reconstruct the information needed to find funds, rather than merely generate a new address. Additional privacy keys create additional discovery work unless the software records or derives the relevant history.

The standard’s seed-based approach supports recovery across derived addresses. It does not mean every wallet can interpret every future derivation scheme automatically. Implementations need compatible support before users can rely on a new address or recovery format.

The proposal should therefore be assessed at the wallet level as well as the cryptographic level. A protocol-compatible design, an integrated application and compatible signing firmware are distinct delivery milestones. None is demonstrated solely by publishing the plan.

Nor does generating safer addresses erase addresses already recorded publicly. The prospective benefit concerns newly generated swap addresses; the reviewed material does not establish retroactive protection for earlier exposure.

Wallet recovery and rollout remain the tests

Zakura’s engineering tracker labels quantum unlinkability for swaps as in review. The write-up anticipates integration by compatible software wallets, including Vizor, in the coming weeks, with hardware wallets following when their firmware supports it. No fixed release date is given.

Recovery would use private information retrieval, or PIR, to request relevant records without telling the database operator which addresses the wallet is checking. The goal is to avoid replacing public-chain linkage with a new source of linkage at the lookup service.

For outgoing swaps, the design puts an encrypted note in the deposit transaction’s change output identifying the refund index. A restored wallet could reconstruct the swap key from that index. Incoming swaps need another approach because there is no outgoing Zcash deposit in which to leave that note: the wallet would check sequentially derived addresses against published filters, with a bounded gap of unused addresses marking where to stop.

Zakura’s separate transparent-wallet privacy design explains the same operational concern. Ordinary wallet queries can show a server that several addresses belong to one client, even when those addresses appear separate on-chain. Transport encryption alone does not hide the queries from that server.

PIR protects the lookup, rather than making transparent transactions private on the blockchain. The transparent-wallet work also targets January for post-quantum signature instructions. That is a separate development track from isolating incoming viewing keys for shielded swaps.

The swap proposal is also distinct from the NU7 testnet rollout, which concerns block timing, transaction rules and fee allocation. A consensus-upgrade milestone cannot substitute for evidence that a particular wallet has implemented this privacy feature.

Alternative.me’s index displayed 59, classified as Greed, versus 53 previously. It measures broad market sentiment rather than Zcash’s technical readiness.

The next checks are reviewed implementation, named wallet releases and supported recovery and signing flows. Until those are available, integration timing, hardware compatibility and adoption remain unresolved.