Market cap $2.76 T −0.24 % over 24 hours24h volume $74.15 BBTC dominance 59.6 %ETH 10.6 %Fear & Greed 59 GreedCoins 22,392

Zcash swaps through NEAR Intents leave a quantum trail: Zakura wants a separate viewing key for every swap

Zcash quantum risk in NEAR Intents swaps: Zakura gives each swap its own viewing key so a future quantum computer cannot link a whole wallet.

16 min read

Abstract eye and key beside an atom, a bridge and a padlock
Table of contents
  1. The weak spot: a shielded refund address posted on NEAR’s public chain
  2. Zakura’s fix: one throw-away viewing key per swap
    1. The cost: every extra key slows a restore from seed
    2. Why not a separate account per swap: hardware wallets
  3. Is Zcash quantum resistant? Not yet, and the swap fix does not claim it
  4. The January opcodes cover transparent ZEC, about 70% of supply
  5. Refunds were already the weak spot in Zcash swaps a year ago
  6. Ironwood and ZIP 2005: Zcash rebuilt its shielded pool this summer
  7. Explainer for newcomers: viewing keys, refund addresses and harvest now, decrypt later
    1. Shielded and transparent ZEC
    2. Viewing keys: read access without spending power
    3. Refund addresses: why a swap publishes one
    4. Harvest now, decrypt later
    5. Private information retrieval
  8. ZEC and NEAR prices, and the figures behind the story
  9. What is still unknown, and the dates to watch

Zakura, a Zcash development team, has published a design that gives every blockchain, where users swap tokens directly from their own wallets without handing custody of their funds to a company.">swap of shielded ZEC through NEAR Intents its own throw-away viewing key. It does not make Zcash quantum resistant as a whole, and Zakura does not claim it does. The aim is narrower: if a future quantum computer cracks one published refund address, it should learn about that swap and nothing else in the wallet. The engineering post by Adam Tucker was reposted on 18 October, CoinDesk reported the plan on 19 October, and the code is already in Zakura’s open-source wallet libraries, where pull request #163 was merged on 14 October.

What is at stake is privacy, not money. Spending in Zcash takes a separate key, so “the funds themselves would stay safe,” CoinDesk wrote. The risk is that someone who stores today’s public data could one day learn who paid whom, how much and with which memo.

It is also narrower than a network upgrade. This is a wallet-side feature from one team, delivered in its libraries. We found no Zcash Improvement Proposal (ZIP), no consensus change and no statement from the Zcash Foundation, Electric Coin Co or Shielded Labs about it. Wallets built on Zakura’s libraries, Vizor among them, will be able to add it for software wallets “in the coming weeks”, the post says, and CoinDesk reports the same. Hardware wallets would follow once their firmware supports it. Nobody has given dates, and the documentation in Zakura’s own code says the key derivation “still requires cryptographic review before issuing live addresses”.

The weak spot: a shielded refund address posted on NEAR’s public chain

NEAR Intents lets users swap assets across blockchains. Take a user who pays someone in USDC on Ethereum with shielded ZEC, the example in Zakura’s post. The wallet sends ZEC to a NEAR deposit address on the Zcash chain, and the swap quote names a refund address, one of the user’s own shielded addresses, in case the swap fails or some ZEC goes unused. That address is written to NEAR’s public chain as soon as the deposit registers, whether or not a refund ever happens, according to the post. CoinDesk describes the same mechanism.

Every swap out of ZEC posts a new refund address this way. Swaps in the other direction, into ZEC, post the user’s shielded address as the recipient. With today’s computers, none of that reveals anything: a shielded address does not show the payments it receives. The trouble lies in how wallets build their addresses.

In Zcash, all the addresses of one account come from a single account secret, the incoming viewing key, or IVK. Each address encodes a short value called a diversifier and a point on an elliptic curve. The wallet hashes the diversifier to a base point and multiplies that base point by the IVK to get the address’s point, as the Zcash protocol specification defines it. Change the diversifier and the wallet gets a new address, as many as it likes, and none of them looks related to the others. That is how one wallet can hand a fresh address to every payer.

Working backwards from those two points to the IVK is the discrete logarithm problem, out of reach for classical computers. A large enough quantum computer running Shor’s algorithm could solve it, Zakura’s post explains. The chain itself never shows either point, so an address passed privately from payee to payer is far less exposed than one posted in public. An attacker who recovered the IVK behind one published address would not see one address’s history. They would see every payment the account has received on any of its addresses, with the value and memo of each, according to the post.

Zakura’s post says shielded transactions hold up against future quantum attackers in many ordinary cases. The exposure starts when a shielded address is made public, and the post calls swaps through NEAR Intents the most concerning case, because publishing the address is part of how the swap works.

The calendar matters less than it seems. Quantum computers able to do this are “still likely years away”, CoinDesk writes, and no one has a firm date. The refund addresses, though, are on a public chain today, and anyone can copy them. This is the “harvest now, decrypt later” problem Zakura cites: collect the data now, read it the day the machine exists. A swap made this week could be unmasked years from now, and the user could do nothing about it then.

Abstract chain of blocks under a magnifying glass beside a floating document
Refund addresses written on a public chain today can be copied and studied later.

This has nothing to do with the deposit-notification bug that minted $3.8 million in ghost funds, described in our story on the NEAR Intents postmortem. That was a software flaw with money at stake. This one is a privacy exposure that needs hardware nobody has built yet.

Zakura’s fix: one throw-away viewing key per swap

The idea fits in two sentences. For each address that has to be published, such as a NEAR Intents refund address, the wallet derives a separate “one-time IVK” instead of reusing the account’s shared one, and the account’s spending key stays as it is. If a quantum attacker later breaks that address, they learn the payments made to that address alone.

The code is public. Pull request #163 in the zakura-core/wallet-libraries repository, titled “Spend one-time-key notes first when it costs nothing”, was opened on 12 October and merged on 14 October after 52 commits, with all 19 automated checks passing. Its commits add two crates, zakura-one-time-ivk and zakura-near-intents. In Zcash, a full viewing key is made of three values: ak and nk, tied to spending, and rivk, which randomises the IVK so that it reveals nothing about the other two. A one-time key keeps the account’s ak and nk and replaces only rivk, the crate’s documentation says. The new rivk comes from a keyed BLAKE2b hash of the account’s keys, a purpose (0 for refunds, 1 for incoming payments) and an index. ZIP 32 already uses the same construction for a wallet’s internal change keys, with a different first byte.

A new rivk gives a new IVK and a new address, while the account’s usual spending key still spends whatever arrives there. Tying a swap key back to the account would mean inverting a hash-based derivation, which Zakura says stays out of reach even for a quantum computer.

Other details touch wallets directly. The zakura-near-intents crate turns the status messages of NEAR Intents 1Click swaps into a common format the wallet can track. The pull request itself deals with spending: notes received on one-time keys go first when that never makes the transaction larger, their value moves into ordinary change that any wallet restored from seed can find, and they fill at most half of the candidates picked for consolidation. The documentation also asks for the byte that separates these keys from others, 0x85, to be reserved with the ZIP editors before live addresses are issued. The pull request never mentions quantum computers.

The cost: every extra key slows a restore from seed

Zakura’s post names the catch itself: “Each extra key is another key to scan with when restoring a wallet from seed.” A wallet that had made a hundred swaps would, done the simple way, scan the chain with a hundred extra keys to rebuild its balance. Recovery would get slower with every swap.

In daily use the cost stays small, because the wallet only scans with the keys of swaps still in flight and retires each one once its swap settles. The restore is the hard part, and Zakura’s answer leans on a quirk of NEAR’s bridge: every outgoing transaction it makes on Zcash is encrypted with the same all-zero outgoing viewing key, so anyone can index its payouts by address. Zakura builds that index into a database and publishes small filters, similar to Bloom filters, that every wallet downloads in full.

A restoring wallet checks its addresses against the filters and queries the database only for those flagged as paid. It does so through private information retrieval (PIR), the lattice-based technique Zakura already uses for lookups in coinholder voting and for transparent wallets, so the server never learns which address was asked about. To know which keys to rebuild, the deposit transaction leaves the wallet a note to self in its change output, encrypted to its internal viewing key, that records the refund index. Swaps into ZEC leave no such note, so the wallet derives addresses in order from index 0 and stops after 30 in a row that NEAR neither paid nor quoted.

Why not a separate account per swap: hardware wallets

An obvious alternative would be to put swap funds in separate accounts. The post rules it out because of hardware wallets. Keystone’s Zcash support “only allows signing from account index 0”, it says. Ledger can reach every account but spends from only one per transaction, which would mean several manual approvals for a single payment. Keeping one account, with one-time viewing keys under it, avoids both limits. Hardware wallet support still depends on firmware updates, and none has a date.

Is Zcash quantum resistant? Not yet, and the swap fix does not claim it

Zakura does not present the design as making Zcash quantum resistant. Its post says shielded transactions already keep their privacy against quantum computers in many ordinary cases, pointing to an explainer by Sean Bowe, and calls a published address “a glaring hole” until Tachyon, a planned Zcash upgrade, ships. A summary of the post by Zcash Türkiye, reposted by KuCoin on 18 October, puts the aim as making a compromised public address much harder to link to a user’s other transactions. We found no date for Tachyon and no source explaining how it would close the hole.

Zcash’s quantum work now runs on three separate tracks. None of the sources presents them as one programme, and each protects something different.

TrackWhat it protectsWhoStatus
ZIP 2005, Ironwood quantum recoverabilityFunds in the Ironwood pool, recoverable through a future Recovery Protocol if shielded protocols had to be switched offZIP authors Daira-Emma Hopwood and Jack GriggZIP status Proposed; Ironwood live since 28 July 2026; Recovery Protocol only outlined, not in consensus
Post-quantum signature opcodesSpending from transparent ZEC addressesZakuraPlanned for January; no activation date
One-time viewing keys for swapsPrivacy of shielded addresses that must be published, starting with NEAR Intents refundsZakura, in its wallet librariesCode merged 14 October; wallets “in the coming weeks”; hardware wallets later

ZIP 2005 changes how notes are built in the Ironwood smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool so that funds could be recovered later. By its own description it does not make the protocol quantum-secure, and it does not set out to hide who paid whom from a quantum attacker. Funds in the older Sapling, Orchard and Sprout pools are not covered and would have to move. The swap keys fill part of that privacy gap, for one kind of address.

The January opcodes cover transparent ZEC, about 70% of supply

The swap fix arrives ten days after a larger announcement. On 9 October, CoinDesk reported Zakura’s target for hash-based, post-quantum signature opcodes. “Our team plans for post-quantum signature opcodes to land in Zcash in January,” Roman Akhtariev of Zakura told the outlet. No activation date has been confirmed.

Those opcodes concern transparent ZEC, the part of Zcash that works like bitcoin, with visible addresses and amounts. That is most of the coin. About 11.96 million of 16.98 million ZEC, roughly 70%, sat in the transparent pool on 8 October, according to CoinDesk’s calculation from ZecStats data.

The plan followed a scare. On 8 October, Justin Drake described a “bunker mode” scenario in which AI could break the signature maths that guards wallets “in months, not years” in the worst case. ZEC ended that day near $1,185, down about 11% on the week, CoinDesk reported. Vitalik Buterin called it “plausible” that AI could break encryption within two years, according to Decrypt. Ethereum’s own post-quantum migration target is December 2029, CoinDesk noted.

On 11 October, Decrypt described the transparent side of Zakura’s plan: a fresh transparent address for every transaction, backed by a hash-based backup signature called WOTS. It also reported that PIR was rolling out that week in Vizor, where users can switch on “private queries” in the settings. Zakura wrote on X at the time: “While others are worrying about the viability of rotating transparent addresses, we’re already solving linkability.” The swap keys carry that idea over to shielded addresses.

The rest of the industry spent the week on the same subject. Google reported a 40-fold cut in quantum magic-state errors, covered in what Google’s magic-state result means for Bitcoin, and nine firms formed a group to define the term, in our report on the Quantum Alliance. Zakura’s work is narrower than either: a fix for one leak, in one kind of transaction.

Refunds were already the weak spot in Zcash swaps a year ago

The refund address has caused trouble before, with no quantum computer involved. On 21 October 2025, the on-chain investigator ZachXBT found that the NEAR Intents integration in the Zashi wallet sent a refund of 0.001598 ZEC to the transparent address he had shielded from. The refund tied his shielded and transparent activity together. The Zashi team said it would add ephemeral addresses and shielded refunds; we could not confirm whether those changes shipped.

The two problems differ in timing. The 2025 leak exposed a link at once, to anyone reading the chain. The new one would need a machine that does not exist yet. Both start at the same place: the address a swap service keeps on hand in case it has to send coins back.

Ironwood and ZIP 2005: Zcash rebuilt its shielded pool this summer

The quantum debate comes after a difficult summer for Zcash’s privacy pools. In late May 2026, Shielded Labs researcher Taylor Hornby found a flaw in the circuit of Orchard, then the main shielded pool, that could in theory have allowed undetectable counterfeit ZEC, The Block reported. There was no evidence it had been exploited. An emergency soft fork disabled Orchard activity on 2 June, and a hard fork with a corrected circuit followed the next day.

Ironwood, network upgrade NU6.3, activated on 28 July at block 3,428,143, with notes built to be quantum-recoverable under ZIP 2005. Orchard became withdrawal-only, with a turnstile limiting how much can leave it. At activation about 40,207 ZEC had moved to Ironwood and about 3.6 million ZEC were still in Orchard, according to a tracker snapshot cited by The Block, which may since have changed. “Orchard was fixed in 5 days and replaced in 60,” Josh Swihart of ZODL wrote on X, as quoted by The Block.

Holders have also voted on the next upgrade, NU7. Nearly 2.4 million ZEC took part, about two-thirds of the roughly 3.6 million eligible, Unchained reported on 16 September. About 99.9% backed cutting block time from 75 to 25 seconds, about 98.9% backed keeping halvings, and about 99.3% wanted NU7 shipped as soon as possible. No NU7 activation date has been announced.

Explainer for newcomers: viewing keys, refund addresses and harvest now, decrypt later

Shielded and transparent ZEC

Zcash has two kinds of addresses. Transparent ones work like bitcoin: anyone can see the sender, the receiver and the amount. Shielded ones hide all three, using zero-knowledge proofs to show a payment is valid without revealing its details. Our Zcash (ZEC) page covers the coin’s history and supply.

Viewing keys: read access without spending power

A viewing key lets its holder see a shielded account’s activity without being able to spend from it. An incoming viewing key shows the payments the account receives; a full viewing key shows outgoing activity as well. Users can hand one to an accountant or an auditor. The point in this story is that one incoming viewing key normally covers every address of an account, which is why cracking it from a single address would expose them all.

Refund addresses: why a swap publishes one

A cross-chain swap can fail: a price moves, a deadline passes, a deposit arrives late. The service then needs somewhere to send the coins back, so the user gives it a refund address, and on NEAR Intents that address is recorded on NEAR’s public chain. It stays there whether or not a refund ever happens.

Harvest now, decrypt later

Some data cannot be read today but can be kept. An attacker who copies public blockchain data now loses nothing by waiting for a machine that can decrypt it. Money can be moved to safer addresses before that day comes; a payment history already on chain cannot be taken back. That is why privacy faces a longer horizon than funds, and why Zakura acts years before any such computer exists.

Private information retrieval

PIR lets a client fetch a record from a server without the server learning which record it fetched. In Zakura’s design it lets a wallet check for refunds on its one-time addresses without telling a database which addresses belong to it, and it saves the wallet from scanning the entire chain with every extra key when it is restored from a seed phrase. Decrypt reported on 11 October that Vizor was rolling out PIR as a “private queries” setting.

Abstract wallet linked to a server rack and gears across a node network
With private information retrieval, a wallet can query a server without revealing its addresses.

ZEC and NEAR prices, and the figures behind the story

ZEC traded near $1,163 at 05:45 UTC on 19 October, up 3.0% over 24 hours and down 8.76% over seven days, according to Coindaro’s market data. NEAR traded near $5.05 at the same time, up 2.29% on the day and down 13.76% on the week. Nothing in the sources links those moves to the swap-key plan.

ItemValueSource and date
ZEC price$1,163 (24h +3.0%, 7d -8.76%)Coindaro market data, 19 Oct 2026, 05:45 UTC
NEAR price$5.05 (24h +2.29%, 7d -13.76%)Coindaro market data, 19 Oct 2026, 05:45 UTC
ZEC at the close of 8 Octoberabout $1,185, about -11% on the weekCoinDesk, 9 Oct 2026
ZEC in the transparent pool11.96 million of 16.98 million (about 70%)CoinDesk from ZecStats, 8 Oct 2026
ZEC moved to Ironwood at activationabout 40,207; about 3.6 million still in OrchardThe Block, 28 Jul 2026
Ironwood activationblock 3,428,143The Block, 28 Jul 2026
NU7 coinholder votenearly 2.4 million ZEC of about 3.6 million eligibleUnchained, 16 Sep 2026
Pull request #163opened 12 Oct, merged 14 Oct, 52 commits, 19 checks passedGitHub, zakura-core/wallet-libraries
Ethereum post-quantum targetDecember 2029CoinDesk, 9 Oct 2026

What is still unknown, and the dates to watch

Several points remain open after the announcement:

  • The publication date of Zakura’s post: the page does not show one clearly, and the earliest repost we found is dated 18 October.
  • Whether Zashi, ZODL, Ledger, Keystone or the NEAR Intents team plan anything, or whether any change is needed on the NEAR side. We found no comment from any of them when this piece was written.
  • Whether the design covers other cross-chain services; the sources only discuss NEAR Intents.
  • When the key derivation will pass the cryptographic review its own documentation calls for, whether Zakura’s PIR set-up has had independent review, and whether a ZIP will describe the one-time keys.
  • Whether Zashi’s 2025 promise of shielded refunds and ephemeral addresses was delivered.

The first date to watch is the wallet release: Vizor and other wallets on Zakura’s libraries could ship one-time swap keys within weeks, with hardware wallets later. The post-quantum signature opcodes for transparent ZEC are targeted for January, with no activation date confirmed. Tachyon and NU7 have no public dates yet.

Sources

  1. Zakura: Quantum Unlinkability for Zcash Swaps zakura.com
  2. GitHub: zakura-core/wallet-libraries pull request #163 github.com
  3. CoinDesk: Zcash developers plan a fix to keep ZEC swaps private from future quantum computers, 19 October 2026 coindesk.com
  4. ZIP 2005: Ironwood Quantum Recoverability zips.z.cash
  5. CoinDesk: Zcash developers set January target for quantum-resistant payments, 9 October 2026 coindesk.com
  6. The Block: Zcash activates Ironwood upgrade after Orchard vulnerability, 28 July 2026 theblock.co

Leave a Reply

Your email address will not be published. Required fields are marked *