Zcash developer proposes quantum privacy fix for NEAR Intents swaps

Zcash infrastructure developer Zakura has proposed a new wallet security feature that would give each ZEC swap through NEAR Intents a separate viewing key to protect users’ transaction histories against potential future quantum computing attacks.

In an engineering post, Zakura developer Adam Tucker explained that the proposed system would prevent an attacker from using a single publicly exposed Zcash address to uncover payments received across a user’s shielded account.

The feature, called a one-time incoming viewing key, would generate a different key for every swap while keeping the wallet’s existing spending key unchanged. According to the team, wallets built using Zakura’s open-source libraries could begin integrating the feature in the coming weeks.

Zakura identified NEAR Intents as a particular concern because the cross-chain swapping service permanently publishes certain Zcash addresses on NEAR’s public blockchain, even when the transactions are completed without requiring refunds.

Although current computers cannot use the exposed information to recover the underlying viewing keys, the team warned that sufficiently powerful quantum computers could eventually do so.

Zcash swaps through NEAR Intents expose refund addresses

NEAR Intents allows users to exchange assets across different blockchains without manually managing each step of the transaction.

When someone exchanges shielded ZEC for USDC on Ethereum, their wallet sends ZEC to a deposit address associated with the service. The swap request contains a refund address where any unused ZEC can be returned.

According to Zakura’s technical explanation, the refund address is recorded on NEAR’s public blockchain once the deposit is registered.

The address remains publicly accessible even if the swap succeeds and the service never sends a refund.

Zcash wallets can normally generate multiple shielded addresses that appear unrelated. However, the addresses associated with a single account generally share an incoming viewing key, which allows the wallet to identify and decrypt payments sent to it.

The underlying cryptography uses elliptic-curve calculations that conventional computers cannot practically reverse.

Zakura warned that a sufficiently powerful quantum computer running Shor’s algorithm could theoretically recover the incoming viewing key from the public information contained in one exposed shielded address.

An attacker possessing the recovered key could then identify payments received by the account, including their amounts and attached private memos.

The exposure concerns transaction privacy, not direct control of the funds. Zcash uses separate cryptographic keys to authorize spending, meaning the recovered incoming viewing key would not itself allow an attacker to transfer the user’s ZEC.

The team explained that shielded transactions do not ordinarily publish the recipient’s address on the Zcash blockchain. However, publicly recorded swap addresses create a permanent source of information that a future attacker could collect.

The issue applies to swaps in both directions. Exchanges from ZEC into assets on other networks publish refund addresses, while swaps into ZEC publish the receiving shielded address.

Zcash’s use in cross-chain transactions has expanded beyond ordinary token transfers. In September, Aurora Intents processed more than $19 million across 1,718 swaps connected to the zkSNARKS auction, accounting for more than half of the assets converted and deposited into the ZEC-denominated sale.

The transactions used NEAR Intents solvers to convert assets from other networks into ZEC, while the destination-side bids remained shielded on Zcash.

Zakura’s proposed fix keeps spending under one account

Zakura’s proposed solution assigns a separate incoming viewing key to each swap address without requiring users to create a new wallet account every time.

Under the design, the wallet derives a new key using its existing account credentials, the intended purpose of the address and an index identifying the swap.

Each address would therefore have its own viewing key, while the original spending key continues controlling the funds received through all of them.

The engineering post explained that the process changes the randomized component used to derive an incoming viewing key. The account’s authorization and nullifier keys remain unchanged.

Zakura uses a keyed hash construction already employed by Zcash’s ZIP 32 key derivation system, with a separate domain identifier to distinguish swap keys from existing internal wallet keys.

According to the team, recovering one swap’s viewing key would reveal only payments associated with that address. Linking the recovered key to other swap addresses would require reversing the hash-based derivation.

Creating a completely separate Zcash account for every transaction could provide similar separation, but Zakura said the approach would cause problems for hardware wallet users.

Keystone’s Zcash implementation currently supports signing transactions only from account index 0, according to the post. Ledger can access multiple accounts but requires separate transactions and approvals when spending funds from different accounts.

A user who accumulated funds across numerous swap accounts could therefore face restrictions or repeated approval requests when attempting to spend them.

The proposed one-time key design would keep the funds spendable through the original account and its existing authorization process.

Zakura said its implementation would leave an encrypted note in the change output of an outgoing ZEC swap. The note records the index used to derive the refund address, allowing the wallet to reconstruct the appropriate key during recovery.

Once NEAR completes the swap, any unused ZEC returned to the designated address can be spent using the wallet’s normal spending key.

Wallet recovery uses private database searches

A separate part of Zakura’s proposal addresses the additional work created when a wallet needs to recover payments associated with hundreds of individual viewing keys.

Zcash wallets normally identify incoming payments by checking encrypted transaction outputs against their viewing keys.

Under the proposed design, every swap would generate another key that might need to be checked during wallet restoration.

According to the engineering post, repeatedly scanning the entire blockchain with each key would make recovery progressively slower as the number of swaps grows.

Zakura has proposed using private information retrieval, or PIR, to locate the relevant transactions without revealing the wallet’s addresses to the database operator.

The system relies on a specific feature of NEAR’s Zcash bridge. Its outgoing transactions use an all-zero outgoing viewing key, allowing the transactions to be indexed by their destination addresses.

A wallet restoring its transaction history would first download filters identifying addresses that may have received payments through the bridge.

The filters are downloaded in full, so the server does not learn which addresses belong to the user.

When a filter identifies a possible payment, the wallet would submit an encrypted database request using PIR. The server could return the location of the matching transaction without learning which address was queried.

Zakura said the system uses the same lattice-based private retrieval technique developed for its transparent wallet lookups and Zcash coinholder voting.

The recovery process differs slightly for swaps into ZEC because the receiving wallet does not create an outgoing Zcash transaction containing a record of the address index.

In those cases, the wallet would generate addresses in sequence and check them against published filters until it encountered 30 consecutive addresses that had neither received payments nor been supplied to NEAR.

The team said abandoned swap quotes would not cause addresses to be reused, since each new transaction receives an address that NEAR has not previously encountered.

Zcash quantum protection remains under development

Zakura’s proposal arrives as Zcash developers prepare separate protections against future quantum attacks on transaction signatures.

As crypto.news previously reported, developers have targeted January 2027 for introducing post-quantum signature instructions that would allow transparent Zcash transactions to use hash-based signatures.

The proposed instructions would address a different security concern from the one-time viewing keys. They are intended to protect spending authorization, while Zakura’s latest design focuses on preventing historical shielded payments from becoming linked through an exposed address.

Approximately 11.96 million ZEC, representing roughly 70% of the issued supply as of Oct. 8, was held in transparent addresses, according to the earlier reporting.

Zcash’s July Ironwood network upgrade introduced quantum-recoverable notes through ZIP 2005, allowing a future recovery mechanism to be developed if advances in quantum computing threaten existing cryptographic protections.

However, the feature did not independently make the network quantum-secure, as a separate recovery protocol would still need to be designed and activated.

Concerns over quantum attacks have received attention following Google’s latest research involving its Willow processor.

On Oct. 15, Google reported a 40-fold reduction in quantum computing errors using a technique known as magic state cultivation.

The experiment achieved 99.99% logical fidelity under the researchers’ testing method, although it did not demonstrate an attack against Bitcoin, Zcash or other cryptocurrency networks.

No quantum computer capable of recovering the elliptic-curve keys used by Zcash has been publicly demonstrated.

Zakura has not announced a confirmed release date for its one-time viewing key feature. The team expects software wallets using its cryptographic libraries, including Vizor, to begin integrating the design in the coming weeks.

Hardware wallet support will follow once the relevant firmware can accommodate the new key derivation process.