Zakura has published an experimental implementation that gives Zcash swap addresses separate incoming viewing keys while retaining the account's spending authority. According to its October 15 release candidate, the key derivation requires review before live addresses are issued.

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 would require 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 a future confidentiality risk rather than reporting an attack already taking place. And because those addresses are recorded on a public blockchain, disclosures made today would remain available for that kind of analysis whenever a capable machine arrives — the long-horizon exposure pattern often described in the industry as harvest now, decrypt later.

Separate viewing keys would keep the spending account intact

Zcash distinguishes viewing authority from spending authority. Viewing keys are designed to let holders share read-only access to their incoming payments — for accounting or audits, for example — without surrendering control over funds. Its wallet key-derivation standard, described in ZIP 32, 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, as described in the implementation's documentation.

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.

Under the current shared-key model, recovering one key can expose incoming payments across several addresses. With 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 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.

This article originally appeared on Coindoo.