Zcash developers at Zakura have proposed a wallet-level change designed to keep cross-chain swaps from exposing the rest of a user’s payment history to a future quantum attacker. The design gives each publicly posted swap address a separate incoming viewing key while leaving the account’s spending authority intact.
The engineering work targets a particular privacy leak around swaps through NEAR Intents. It is not a claim that quantum computers are currently stealing ZEC, nor a completed upgrade that makes every part of Zcash quantum-resistant.
A public refund address can outlive the swap
When a user swaps out of ZEC, the swap process publishes a shielded refund address on NEAR’s public chain. That reference can remain public even if the swap succeeds and no refund is needed. Swaps into ZEC similarly publish a recipient address.
Ordinary Zcash address diversification makes addresses look different, but addresses belonging to the same shielded account can share an incoming viewing key. A sufficiently capable future quantum computer could potentially recover that viewing key from one exposed address and use it to connect payments received by the account.
The concern is a lasting record that can be collected now and analyzed later. Keeping amounts private on one blockchain does not erase information that a separate application has published elsewhere.
Separate visibility, shared spending control
Zakura’s proposal changes the derivation of the viewing key for each swap. Its aim is to confine what can be learned from a compromised public address to payments associated with that address, rather than the broader account.
The spending key remains shared, avoiding the need to scatter a balance across separate accounts. That separation is central to the design: permission to inspect incoming payments and permission to spend funds are different powers. A privacy weakness should not automatically be described as a route to spending the victim’s coins.
For a wallet user, the intended result is less exposure without a new collection of accounts to manage. For wallet developers, however, generating additional keys creates a recovery problem: restoring an old wallet can require finding payments associated with many historical swap keys.
Recovery must preserve privacy too
The proposal addresses that problem with filters and private information retrieval, allowing a restored wallet to locate relevant swap payments without disclosing its address queries to the lookup server. Otherwise, a service introduced to make recovery faster could become another source of links between a person’s addresses.
These are implementation requirements, not evidence that every wallet has already adopted the design. Software integration and hardware-wallet support still matter. Users should not assume that an existing swap address has acquired new protections because a design has been published.
The work also differs from Zcash’s scaling effort, covered in our report on Tachyon code entering the private-payment software stack. Scaling reduces the cost of handling private transactions; this proposal limits the consequences of publishing a receiving address outside that private environment.
The practical question is now adoption: which wallets implement the key separation, how they recover older swaps, and which protections require additional hardware support. Until those details are delivered, this remains a specific engineering response to future privacy exposure rather than a blanket quantum-security guarantee.