Zcash Proposal Would Give Each NEAR Intents Swap Its Own Viewing Key

Zakura’s proposal for Zcash targets a narrow but consequential privacy weakness in cross-chain swaps. A refund address tied to a wallet’s viewing-key structure could reveal more transaction history than a user intended if future cryptographic advances let an attacker exploit that connection. The concern is about what an attacker might learn from a key, not about gaining the ability to spend the funds.

That distinction matters. Privacy systems often separate the ability to inspect transaction information from the authority to move assets. A viewing key can expose information without acting as a spending credential, but that information may still be sensitive: transaction links can help reconstruct activity that a user expected to keep private. A refund mechanism adds another point where the system must check addresses and transaction status.

Containing the scope of a compromised key

The idea is to assign each Zcash swap made through NEAR Intents its own viewing key, while keeping spending authority with the user. Instead of relying on a key structure associated with a wallet’s broader history, the swap would have a key scoped to that individual transaction. If one key were compromised, the exposed information would be limited to that swap rather than the wallet’s broader history.

This is a form of damage containment. The proposal doesn’t remove the possibility that a key could be exposed; it seeks to reduce what that exposure would disclose. Similar designs in privacy-sensitive systems often divide access by task or data set, so one credential doesn’t automatically reveal everything else. That can narrow the consequences of a failure, though it also creates more key-management work for the software handling each transaction.

There’s a practical tradeoff here. Per-swap keys may improve privacy boundaries, but wallets and swap services would need to create, retain and use those keys consistently. If the implementation falls back to a broader wallet key during a refund or recovery path, the intended separation could weaken. The details of how keys are generated, stored and associated with each swap will therefore matter as much as the basic proposal.

Reducing what refund checks reveal

The design also considers private information retrieval, a technique that could let software find relevant refunds without publicly revealing the addresses a user is checking. In a conventional lookup, a service may learn which address or record a client is querying, even if it can’t see the user’s private key. Private information retrieval aims to reduce that exposure by allowing a client to retrieve matching information while concealing the specific query.

That would address another point where swap-related information might become visible. A refund check can seem like a routine operation, but it may disclose which transactions a wallet is monitoring. The privacy question therefore extends beyond the funds and the on-chain transaction: it includes what a wallet asks a service to look up, and what those requests could reveal when combined over time.

(And this is the part most people overlook.) A privacy feature can protect transaction data while leaving the surrounding service interactions exposed. Reducing that kind of metadata leakage is useful, but it can add complexity and operational demands. The proposal’s value will depend on whether the retrieval approach can work reliably within the swap flow without creating new points of failure.

Preventive work, with open questions

There’s no demonstrated quantum attack on Zcash behind the proposal. This is preventive work aimed at a possible future threat, and the design is still under review; a widely deployed solution hasn’t emerged. That caution is appropriate: a future cryptographic risk can justify examining how information is compartmentalized, but it shouldn’t be described as an active compromise.

The broader context is that systems built around privacy have to account for more than the strength of their core cryptography. Keys, lookup patterns, refund procedures and wallet integrations can all affect how much information leaks. A design can protect one layer and still leave identifying traces elsewhere. The proposal is a reminder that privacy often depends on how separate components interact.

What adoption will determine

My read is that the proposal focuses on containing the damage if a viewing key becomes exposed. That’s a sensible objective, but the practical value will depend on implementation, auditing and adoption by wallets. A technically sound design won’t help users if the software they rely on doesn’t support it, applies it inconsistently, or handles recovery in a way that restores broad access.

If you're working in this space, the key questions are concrete: whether each swap really gets an isolated viewing key, whether refund checks avoid disclosing unnecessary query information, and whether independent review confirms those protections in the implemented system. This is more significant than it looks because it treats the swap’s privacy boundary as something that must hold across the full workflow, not just at the moment funds move.

For now, the proposal is a direction under review, not a demonstrated fix in widespread use. Its promise rests on limiting disclosure when something goes wrong. The hard part will be preserving that limit across wallets, services and refund handling.

Written by the News Desk and edited by Samuel Rae.