RISK ALERT: Every shielded refund address you hand to NEAR Intents is written on-chain and stays there forever โ whether your swap settles or not. One key sits behind all of them.
Liquidity doesn't sleep. Neither does a published address.
Zakura โ the team building Zcash node and wallet software โ has put a design on paper that gives every shielded address posted during a NEAR Intents swap its own incoming viewing key. One address, one key. One swap, one slice of exposure. The stated purpose is to shrink what a future quantum machine could learn from any single address it decides to attack.
The engineering page lists the work as in review. It has not shipped.
Adam Tucker wrote the post. His framing is the part that matters, and I'll quote it precisely because the precision is the whole argument: until Zcash's planned Tachyon upgrade arrives, "a single published shielded address lets a quantum attacker link every payment that address's key has ever received."
Read that twice. Not "could eventually." Has ever received. Retroactive. Permanent. A receipt that never expires and can never be recalled.
I've spent the last several years tracing on-chain footprints for a living โ first as a security undergrad tearing through ICO whitepapers in Jakarta, later mapping eight billion dollars of FTX customer funds across chains in the middle of a panic, and now as an exchange market lead who gets asked the same question every quarter: is this thing actually private, or does it just look private from where I'm sitting?
Zakura's proposal is the first honest answer I've seen to that question from inside the Zcash ecosystem in a while. It's also narrower than the headline suggests. This is a wallet-layer patch on a protocol-layer problem, and the gap it closes is only closed for people running wallets that adopt it.
Everything else stays open. Let's walk it.
Zcash shielded accounts have a key hierarchy that most users never see and, honestly, most never need to see. Behind every shielded address sits one incoming viewing key. That key decrypts every note the account has received โ value, timestamp, and the memo field, which in Zcash is up to 512 bytes of arbitrary data. People put invoice numbers in there. People put names. People put things they would not put on a public ledger.
Classical computers cannot work that key out from an address. That's the entire security model and it holds. A sufficiently powerful machine running Shor's algorithm could โ Shor takes discrete logs, the address commits to a curve point derived from the viewing key, and a discrete log in that group hands you the key. From there, every payment the account ever received is readable. No such machine exists. That is not the same as saying the risk doesn't exist.
Here is the part that changes with context. In ordinary use, a Zcash holder hands an address privately to whoever is paying them. One recipient, one sender, one private channel. The address lives in a chat log and nowhere else.
NEAR Intents works differently, and it has to. Intents-based swapping means a solver network competes to fill your order, which means the protocol needs a deterministic destination to route value to, which means the refund address gets published on-chain once the deposit is logged. It stays published whether or not you get money back. Swaps into ZEC publish the receiving address too.
The addresses look unrelated. That's the design working as intended โ diversified addresses, different diversifiers, no visible link to a passive observer. But one key sits behind all of them.
So the swap venue becomes an address publication service, and the address publication service becomes a retrospective decryption index the moment a quantum adversary exists. That is the whole thesis, and it's correct.
I want to be precise about scope here, because the scoping is where most coverage will get it wrong. Zakura is modeling one specific attack: recover the viewing key from a published address, decrypt the history. The viewing key is derived from the spend authorizing key by a hash โ you cannot invert it โ so a quantum adversary with your viewing key reads your history but cannot move your funds. Retrospective decryption is not the same bug as spend authority. Different attack, different fix, and Tachyon is the thing that's supposed to address the broader set.
Hold that distinction. It matters in about four paragraphs.
The Design: Change the Randomness, Not the Account
Zakura's approach is surgical. It changes only the randomness that feeds the viewing key derivation, producing a fresh key per swap from a hashed index. The spending key stays put. Funds remain in a single account. No new account, no new seed, no new backup ceremony.
That last constraint is not laziness. It's the load-bearing wall. Tucker's post is explicit: opening a new account per swap was ruled out because Keystone hardware wallets sign only from the first account, and Ledger devices spend from one account per transaction. In his words, that "wasn't an acceptable UX to us."
I've shipped wallet integrations. I know exactly what that sentence cost to write. Somebody built the clean version first, watched it fail on a Keystone, and went back to the whiteboard. The architecture here is shaped by firmware constraints on two consumer devices, and that is worth knowing before you call it a protocol improvement.
The clean design โ one account per swap โ would have given you perfect key isolation and a seed restore that takes ten minutes per swap. Nobody would use it. A privacy feature with a 4% adoption rate is not a privacy feature. It's a badge.
Now the mechanics, because this is where the engineering gets interesting and where I have questions.
More viewing keys normally means a slower restore from seed, one full chain scan per key. With a hundred swaps, that's a hundred scans. Zakura's answer: the wallet leaves itself an encrypted memo noting each swap's index, checks published filters, then uses private information retrieval to look up matching NEAR bridge payouts without the server learning which addresses it asked about.
The memo-index trick is the clever bit, and it's clever for a reason people will miss. Because the memo lives in the note's memo field, it travels with chain data. It survives a seed restore on a fresh device. You don't lose your index when your laptop dies. That's the difference between a design that works and a design that works until someone restores from seed and quietly loses a year of swap history.
But there's an unspecified detail in there that I want pressure-tested, and I'll flag it as an open question rather than a flaw because the post doesn't give me enough to call it either way. The key that decrypts the index memo has to be derivable from the seed alone, independent of the per-swap viewing key โ otherwise you're in a chicken-and-egg loop where you need the key to find the key. The post describes the memo as encrypted but doesn't name the derivation path. If it's derived from the spending key hierarchy directly, the design closes. If it's derived per-swap, restore breaks silently and nobody finds out until a user with failed swaps migrates devices.
That's the kind of detail that decides whether a privacy feature survives contact with a real user base, and it's the first thing I'd ask for in review.
PIR, Filters, and the Thirty-Address Cliff
The private information retrieval layer deserves its own paragraph because it's doing more work than it looks like.
PIR lets a client query a database without revealing which record it wanted. Here, the wallet queries NEAR bridge payout records for addresses matching its per-swap keys, and the PIR server never learns which addresses were asked about. Good. Necessary. Without it, the wallet's own recovery path becomes a query log that reconstructs exactly the linkage the design spent all this effort to break.
But here's the thing about PIR that doesn't make it into the announcement posts: the privacy gain is about query pattern, not about the data. The NEAR bridge payout records are on-chain. They're public. Anyone can read them. What PIR hides is the correlation between your IP, your session, and your addresses โ which is genuinely valuable, and also a different claim than "your swaps are private."
It also introduces a new dependency. Somebody operates that PIR endpoint. Single-server computational PIR has real bandwidth costs and real trust assumptions; multi-server PIR trades those for a coordination problem. Zakura hasn't said who runs it. In a bull market, nobody asks. Alpha moves before the charts confirm the truth, and the truth here is that a wallet that phones a server to recover itself has added an operational surface it didn't have before.
Then there's the gap limit, which I'll call the most borrowed idea in the whole design.
For swaps into ZEC, the wallet checks addresses in order and stops after 30 unused ones in a row. That's BIP-44 wallet engineering, imported wholesale into a privacy protocol. It's the standard heuristic and it's the standard heuristic for a reason โ it bounds restore time.
It also inherits the standard failure mode. Thirty consecutive unused addresses and the scan halts. In Bitcoin, that means a user with a long gap of unused addresses loses sight of later funds until they manually raise the limit. In Zcash, the equivalent scenario is a streak of failed swaps โ solver competition doesn't fill, refund address published anyway, address unused, address unused, thirty-one times, and the wallet stops looking. The addresses were still published. The linkability is still on-chain. The wallet just can't see the funds anymore.
That's not a catastrophic bug. It's a support ticket generator, and support tickets are how privacy features die โ users conclude the wallet ate their money and go back to the exchange.
Data lies, but volume never cheats. Watch the restore complaints before you watch the marketing.
What This Actually Fixes โ and What It Doesn't
Now the contrarian read, and I want to be fair to the team while being honest about the shape of the problem.
This is a client-side mitigation of a server-side disclosure. Zakura builds node and wallet software. It does not control what NEAR Intents publishes, and NEAR Intents publishes your refund address by design because intent-based routing requires a deterministic destination. So the fix works by making each published address individually worthless to a quantum adversary rather than by stopping the publication.
That's a legitimate strategy. It's also structurally fragile, because privacy is a weakest-link property. Every user on an old wallet build, every user on a wallet that never adopts the library, every user who swaps once through a different front-end โ they all sit in the fully-linkable pool. And a pool with any meaningful population in it is the pool an adversary targets.
Zakura expects software wallets using its libraries, such as Vizor, to be able to add it "in the coming weeks." Hardware wallets follow once firmware supports it. Read that timeline with the skepticism it deserves. "In the coming weeks" from an engineering team on a project listed as in review means months. Hardware firmware cycles are longer than that. Speed is the entire product, and this product is not shipping at speed โ it's shipping at the speed of a Ledger firmware release.
Here's the insight I think is genuinely unreported, and it's the one I'd lead with if I were writing the risk memo instead of the news story.
The mitigation is itself a fingerprint.
NEAR publishes whatever address the wallet supplies. A wallet that generates a fresh address per swap produces a visible pattern: one address, one use, one address, one use. A wallet that reuses a refund address produces a different visible pattern. Both are on-chain. Both are permanent. So the moment adoption becomes uneven โ and adoption is always uneven โ the publication log starts partitioning users by wallet behavior. A per-swap pattern tells an observer: this user is on a current build with the privacy patch. A reused-address pattern tells them: this user is not.
That's not a deanonymization. It's a classification. But classification is how targeting starts, and in a market where the difference between a patched and unpatched wallet is the difference between a readable and unreadable history, "which build is this user running" is a question worth money.
There's a second, harder point. The upgrade is not retroactive, and privacy patches never are.
If you have ever reused one shielded address across multiple NEAR Intents swaps โ and plenty of users have, because that's what wallets did before this existed โ that address's viewing key still unlocks everything routed through it. The new per-swap keys protect the swaps you make after you upgrade. They do nothing for the ones already on-chain. A single pre-upgrade address remains a quantum-readable window into your legacy history, sitting there in the block data, waiting for a machine that doesn't exist yet but might.
Which brings me back to the distinction I asked you to hold.
Zakura's proposal is scoped to linkage and retrospective decryption. It is not scoped to spend authority. A quantum adversary that can take a discrete log in the diversifier group can also take one in the spend-authorization group once a signature is on-chain โ that's a known, separate exposure in the Zcash design space, and Tachyon is the roadmap item that addresses it. Zakura isn't claiming otherwise. But readers will conflate the two, and the conflation is dangerous in exactly one direction: it makes people think the quantum problem is solved when a specific sub-problem has been mitigated at the wallet layer by a design still in review.
Chaos is where the institutional money hides. So is nuance, apparently.
One more thing, and this is where my 2024 self shows up. I spent that year reading S-1 filings line by line to find the clauses that mattered before the financial press found them. The lesson transferred cleanly: the status line is the story. "In review" is not "audited." "Has not shipped" is not "will ship." A design document that solves the linkage problem on paper has solved the linkage problem on paper. The gap between a published design and a wallet you can actually run is where most privacy improvements go to die, and the Zcash ecosystem has a long enough memory to know it.
The Real Chokepoint
If I were sitting across from NEAR Intents' protocol team instead of Zakura's wallet team, I'd ask a shorter question.
Why is the refund address published at all, and for how long does it need to be public?
Intent-based routing needs a deterministic destination during the fill window. It does not obviously need a permanent, globally readable record of that destination after settlement. There are designs โ rotating destinations, one-time claim addresses, delayed publication โ that shift the disclosure from forever to during the fill. None of them are free. All of them add solver complexity. But the asymmetry is stark: Zakura is asking users to upgrade wallets, restore from seed correctly, run a PIR query, and hope their hardware vendor ships firmware, all to compensate for a publication policy on the other side of the trade.
Liquidity is the only religion in the DeFi temple, and the corollary nobody preaches is that liquidity providers never volunteer for friction. So I don't expect NEAR to change publication policy because a Zcash wallet vendor asked nicely. I expect them to change it when a large enough share of their ZEC flow is on patched wallets and the unpatched remainder becomes a visible liability.
Which means the actual adoption curve to watch isn't Zakura's. It's Vizor's, and then Ledger's, and then whatever NEAR's flow analytics look like six months after both.
What I'm Watching
Three things, in order.
First, the encrypted memo derivation. If the index key comes from the seed hierarchy cleanly, restore works and this design is solid. If it doesn't, the first user to migrate devices with a failed-swap streak discovers it publicly. Ask the question now.
Second, whether the per-swap pattern becomes a standardized address-discovery convention or stays a wallet-specific sidecar. A sidecar format is a migration liability. If Tachyon changes the address format โ and post-quantum address schemes generally do โ every wallet that built around this index has to rebuild, and the users who don't upgrade keep their legacy exposure forever. Privacy migrations don't fail loudly. They fail as a long tail of people who meant to update.
Third, NEAR Intents' publication window. Nobody has published how long a refund address needs to be globally readable versus how long it currently is. That number, if it exists, is the real story. Everything else is compensation.
Zakura's proposal is good work. It's honest about its scope, it names its constraints out loud, and it solves a real problem for the users who adopt it. That puts it ahead of most of what ships in this market.
But the address you already published is still out there. It doesn't care that a fix is in review.