Zakura's Per-Swap Viewing Keys: Zcash's Quantum Privacy Patch Is Real, In Review, and Only Half the Problem

I keep a folder of things I got wrong. It is not a small folder. One entry in it is a screenshot dated August 2020: a shared spreadsheet, one column labelled refund address, 412 shielded Zcash addresses typed in by hand over three nights because the mobile money leg of our Sankofa Yield pilot kept failing and 2,000 women needed to know where their stablecoin would come back to. We published that sheet inside a closed group. It felt like bookkeeping. It was bookkeeping, in the same way that leaving your house key under a specific rock is landscaping. Nobody was harmed. Nobody could have been harmed, as far as I understood the system then. A shielded address is a commitment, a curve point, a diversifier. The receiving key never leaves the wallet. The chain shows a ciphertext and a nullifier and nothing else, and I explained that to those women in Yoruba and Pidgin English across six workshops, and I believed every word of it, and every word of it was true. What I did not understand well enough, and what I have spent the last week re-learning, is that a single published shielded address is not one data point. It is a master key in waiting, and the only thing standing between that address and the entire received history of the account behind it is the assumption that elliptic curve discrete logarithms are hard. That assumption has an expiry date, and last week a team called Zakura published a design that tries to push the expiry date out of reach for one specific and very common behaviour. Zakura builds Zcash node and wallet software. Adam Tucker wrote the post. The proposal gives every shielded address posted during a NEAR Intents swap its own viewing key, so that a future quantum computer recovering one of them learns only what that one address received. Zakura's engineering page lists the work as in review. It has not shipped. I want to be very precise about that, because in a bull market the distance between a design doc and audited code is where most people lose money. Trust the process, but verify the code. Here is what the design actually does, where the math holds up, where the wallet engineering gets uncomfortable, and why I think it is a genuinely good stopgap aimed at a threat that is not the one leaking your data today. Start with what a Zcash shielded address physically is, because the whole vulnerability lives in a detail most people skim. In the Sapling and Orchard pools, an address is a pair: a diversifier, and a diversified transmission key. The diversifier is just eleven bytes of entropy. The transmission key is computed by hashing the diversifier to a point on the Jubjub curve and then multiplying that point by a scalar. That scalar is the incoming viewing key. So the address you hand to someone is, quite literally, the incoming viewing key multiplied by a base point that anyone can recompute from the diversifier alone. Sit with that for a second. The address is not a hash of a key. It is a scalar multiplication of a known point. Which means the address publishes exactly the input that Shor's algorithm eats for breakfast: given a point and its base, find the scalar. On a classical machine that is infeasible. On a cryptographically relevant quantum machine it is a polynomial-time computation, and the answer it returns is the incoming viewing key itself. What does an incoming viewing key open? Everything the account has received, ever. Not just the payment attached to that address, because the account does not work that way. Every address an account generates shares one viewing key. That is the design, not a bug. Diversifiers exist so that different payers cannot trivially link their payments to you by comparing addresses on chain. They do not exist to give you separate decryption authority per address, because giving you separate decryption authority per address would mean your wallet had to hold a separate key per address, and then restoring from a seed would mean one full chain scan per key, and nobody wanted that in 2018 when Sapling shipped. So the wallet holds one incoming viewing key, derives as many diversifiers as it likes, and trial-decrypts every shielded output on chain against that one key to find its notes. That is how it works. That is how it has worked for eight years. And that is why Tucker's sentence lands the way it does: until the planned Tachyon upgrade arrives, a single published shielded address lets a quantum attacker link every payment that address's key has ever received. The viewing key also opens memos. This is the part that gets undersold in every summary I have read, including the good ones. Memos in Zcash are 512 bytes of arbitrary data attached to a shielded output, encrypted under keys derived from the same viewing key. In the wild, memos carry invoice numbers, exchange deposit identifiers, names, and the kind of free-text note that a person types when they think nobody is reading. A recovered viewing key does not just tell an attacker that money arrived. It tells them who sent it, what it was for, and what the sender wrote down. Now add NEAR Intents to that picture, because the design does not exist in a vacuum. NEAR Intents is a cross-chain swap service built around the intent model: you declare what you want, solvers compete to fill it, and settlement happens across chains through the NEAR chain and its bridges. It is one of the genuinely interesting pieces of infrastructure to come out of the last two years, and it is also, by construction, an address-publishing machine. When you swap ZEC out for another asset through NEAR Intents, your wallet supplies a shielded refund address. Once the deposit is logged, NEAR publishes that address on chain. It stays published. It stays published whether the swap completes, whether the solver fails, whether you get your money back in four minutes or four days or never. When you swap into ZEC, the receiving address gets published too, because the counterparty needs to know where to send. Each of those addresses looks unrelated to every other. Different diversifier, different transmission key, no visible link on chain. One viewing key sits behind all of them. If you swap weekly for a year, that is fifty-two published addresses that all open onto the same account, all decryptable with one recovered scalar, all of them sitting on chain forever, waiting for a machine that does not exist yet to be pointed at them. This is the harvest-now-decrypt-later problem in its purest form. The ciphertext is already public. The key material is derivable from public data by an algorithm that has been known since 1994. The only missing ingredient is hardware, and hardware has a habit of arriving. I want to give the design its due before I start poking at it, because the core idea is elegant and I do not want the elegance to get lost in the caveats. Zakura's approach changes only the randomness that goes into the viewing key. For each swap, the wallet derives a fresh viewing key from a hashed index, so the address published for swap number seventeen is generated under viewing key seventeen and not under the account's master viewing key. The spending key does not change. The funds stay in one account. The account structure does not fragment. That is a clever piece of targeting. Remember the attack: the address is the viewing key times a base point. Change the viewing key per address, and each published address becomes its own discrete-log problem with its own answer. A quantum attacker who solves one of them gets one swap's worth of received notes. They do not get the other fifty-one. The blast radius shrinks from the whole account to a single event. And the change is cheap at the protocol level, because the derivation path already has entropy in it. You are not adding a new key type to the circuit. You are not changing the note commitment scheme. You are not asking the network to agree on anything. You are re-seeding a hash input on the wallet side and keeping the spending authority where it was. In a space where every privacy improvement seems to require a hard fork, an upgrade that requires only a wallet release is worth noticing. The obvious alternative, and the one the Zakura team says they considered and rejected, is one account per swap. Fresh account, fresh spending key, fresh viewing key, no shared blast radius at all. It is the clean answer. It is also, according to the post, unusable: Keystone hardware wallets sign only from the first account, and Ledger devices spend from one account per transaction, which the team called not an acceptable UX. I have lived inside that constraint, and I want to be honest about how much I hate it. During the AfroChain Artifacts build in 2021, we had fifteen artists tokenizing work on Polygon, and we insisted that every minting key live on hardware. The number of flows we had to redesign because a device would only sign from account zero, or would only accept one account per transaction, or would silently refuse a derivation path it did not recognise, was absurd. We ended up writing an internal document called the account zero tax. Artists who did not understand derivation paths were paying it with their time and occasionally with their funds. So when Zakura says they rejected account-per-swap because of hardware wallet limitations, I believe them, and I also think it is the single most important sentence in the post for anyone who cares about how this industry actually makes decisions. A cryptographic architecture was shaped by firmware behaviour. Not by a security proof, not by a threat model, not by a formal review. By the fact that two vendors' signing flows do not handle multi-account derivation gracefully. That is not a criticism of Zakura. They are working with what exists. It is a criticism of a hardware ecosystem where the signing model of two companies becomes a de facto protocol constraint for everyone downstream, and where nobody seems to treat that as a governance problem. If the reason we cannot have clean privacy isolation is that a device will not sign from account four, then the fix belongs in firmware, and the firmware fix has no release date. Now the hard part, which is not the cryptography. The hard part is restoring. Under the normal model, one viewing key means one scan. Your wallet derives the key, walks the chain, trial-decrypts every shielded output, finds its notes, and stops. It is expensive but it is linear and it is obvious. Under a per-swap viewing key model, you have a fresh key per swap, and a naive restore means one full chain scan per key. Fifty-two swaps a year for five years is two hundred and sixty full scans. Nobody ships that. Zakura's answer is a three-part recovery path, and each part is where the real engineering lives. First, the wallet leaves itself an encrypted memo noting each swap's index. That memo is written at swap time, so on restore the wallet can read its own journal and know which indices to derive, instead of guessing. Second, the wallet checks published filters, the compact block filter approach that lets a light client learn whether a block contains anything possibly relevant without downloading the block. Third, for matching against NEAR bridge payouts, the wallet uses private information retrieval, so the server answering the lookup does not learn which addresses were asked about. Let me take those in order, because the first one worries me and the third one worries me more. The encrypted memo journal is a beautiful trick and it is also a new aggregation point. The entire point of the design is that no single recovered key should open your whole history. But if your wallet keeps a running index of every swap in a memo, and that memo is decryptable under something derived from the same seed family, then a quantum attacker who recovers the right key does not just get one swap. They get the map. They get a signed, ordered, complete list of every swap you ever did, in one place, more convenient than scanning the chain. I do not know from the public post what that journal memo is encrypted under, and I am not going to pretend I do. But this is the question I would ask in review, and I would ask it before I asked about anything else, because a privacy design that relocates the master key rather than eliminating it has not solved the problem, it has renamed it. The filter checking is standard practice and I have no complaints. Neutrino-style compact filters are how light wallets have avoided downloading the chain for years, and the false positive rate is a known, tunable cost. You get a match, you fetch the block, you trial-decrypt, you move on. Fine. The PIR layer is where I want to slow down, because private information retrieval is one of those primitives that sounds like magic and behaves like a tax. The idea is clean: the wallet wants to know whether a particular address appears in the NEAR bridge payout index, but does not want the server running that index to learn which address it asked about. Single-server computational PIR does this by having the client send an encrypted query and the server compute over the entire database without learning the target. The catch is that the server's work is linear in the size of the database, every single query. That is a real cost, and it grows as the payout index grows, and it is paid by whoever runs the server. So the design quietly introduces a new trust anchor: the PIR server. Who runs it? Zakura? NEAR? A third party? What is the latency budget on a mobile connection in Lagos, where I have watched a wallet take forty seconds to fetch a filter header on a good day? And most importantly, what does the wallet do when the PIR query times out? That last question is the one that kills privacy designs in production. Every system I have ever audited has a fallback path, and the fallback path is where the privacy guarantee goes to die. If the wallet falls back to a plain query when PIR is slow, then the privacy property holds only for users on fast connections in well-provisioned regions, and everyone else is silently deanonymised. This is exactly the failure mode that kept the Lightning Network in its niche for seven years: the routing layer worked beautifully in demos and fell back to custodial shortcuts the moment the graph got thin, and users never knew which mode they were in. A privacy feature with a silent fallback is not a privacy feature. It is a privacy lottery. The last piece of the recovery path is the gap limit, and it is the piece I would push hardest on in code review. For swaps into ZEC, where the wallet is discovering addresses it did not generate, the design checks addresses in order and stops after thirty unused ones in a row. Thirty. It is a guess. It is a reasonable guess, in the same way that the twenty-address gap limit in BIP44 was a reasonable guess in 2013, and I have watched that reasonable guess fail in the field more times than I can count. The failure mode is nasty precisely because it is silent. If a user does thirty-one consecutive swaps that never receive funds, and then a thirty-second that does, a restore that stops at thirty will miss the funded address. The wallet will report an empty account. Not an error, not a warning, not a partial sync indicator. An empty account. And in a shielded wallet, an empty account and a not-yet-found account look identical to the person staring at the screen. I spent eleven hours in the winter of 2021 debugging exactly this class of problem on a different wallet, with a developer on a call in Yaba who kept telling me the funds were gone and I kept telling him the funds were on chain and neither of us could prove it because the restore kept stopping early. We found them. It took a patched gap limit and a rescan from a block height four months earlier. He did not sleep that night. I do not want to hand that experience to fifty thousand NEAR Intents users because thirty was a round number. Now the part that I think matters more than any of the above, and the part that the design cannot address because it is not a design problem. The root cause of the exposure is that NEAR Intents publishes refund addresses on chain, permanently, whether or not the refund happens. Zakura's fix is wallet-side. It limits the damage of publication by making each published address individually useless. That is worth doing. But it does not change the fact that the addresses are published, and it does not touch the metadata that publication creates today, on classical hardware, with no quantum computer required. Think about what an observer sees right now. A deposit lands at a bridge address at time T with amount A. At time T plus a few minutes, a refund address is published, or a receiving address is published, or a payout moves. The cryptographic link between those addresses is broken, but the timing and amount link is not. If you deposit 3.417 ZEC and a refund of 3.417 ZEC minus fees appears eleven minutes later, no viewing key is required to guess what happened. The per-swap viewing key design does nothing about this, because this attack does not use keys. It uses arithmetic. I have written about oracle feed latency as DeFi's Achilles heel for years, and the same structural blindness shows up here in a different costume. Everyone audits the cryptography and nobody audits the schedule. The gap between the quote and the fill is where users lose money on a swap, and the gap between the deposit and the publication is where users lose privacy, and both gaps are invisible in the threat model because both are about timing rather than math. The cheapest fix for the quantum exposure is not per-swap viewing keys. The cheapest fix is for NEAR Intents to stop publishing raw refund addresses and publish a commitment or a one-time tag instead, so the on-chain artefact is not a discrete-log target at all. That is a service-side change, it requires no wallet release, and it would remove the exposure at the source rather than capping the damage downstream. I understand why it is hard: settlement proofs need something verifiable, solvers need to know where to send, and a commitment scheme adds a protocol layer that somebody has to maintain. But it is worth naming, because the industry has a habit of celebrating a wallet-side mitigation and then forgetting that the service-side publication is still happening. There is also the selective disclosure problem, which nobody talks about and which will bite the first time an exchange or an auditor asks for a viewing key on a shielded account that has been used for swaps. Today, one key opens the account and that is a feature: hand it to your accountant, hand it to a compliance desk, get your report. Under the per-swap design, there is no single key. You have a set of per-swap keys plus an index that tells you which key corresponds to which event, and the index is the sensitive object. You have not made disclosure impossible. You have made it more complicated in a way that pushes people toward handing over the journal, which is worse than handing over a key. I would want to see a disclosure path designed before this ships, not after. And then there is the question I keep coming back to and cannot answer from the public material: what about the spending key? Tucker's post is careful and specific. It talks about the incoming viewing key, what it decrypts, what a recovered address yields. It does not claim that per-swap viewing keys protect spending authority, and I am not going to attribute that claim to the team. But a reader skimming the headline could easily conclude that the quantum problem is handled. It is not. The viewing key exposure is the one this design shrinks. The spending key question is separate, harder, and belongs to Tachyon. Which brings me to the honest framing of what this thing is. It is not a fix. It is a tourniquet. Zcash's planned Tachyon upgrade is the protocol-level answer, and until it arrives, every wallet is improvising. Zakura is improvising well, in public, with the label in review on the page, and I respect that enormously because I have watched teams ship the same class of change quietly and describe it as complete. So let me run the pragmatic test, which is the only test I actually trust. Does this design solve the problem it says it solves? Yes, largely, for the specific attack of a quantum adversary recovering a viewing key from a published swap address. Does it solve the problem users actually have today? No, and it does not claim to. Does it introduce new failure modes that are worse than the ones it removes? Possibly, in the restore path, in the journal, and in the PIR fallback, and those are the places I would spend review budget. Is it worth shipping before Tachyon? I think so, and here is the argument that convinces me. The addresses published in 2026 are ciphertext that will be decrypted in some future year. The cost of retrofitting privacy onto data that is already public is infinite. The cost of shipping a slightly awkward restore path now is a support burden. Those are not comparable. If you believe, as I do, that a cryptographically relevant quantum machine is a matter of when and not if, then every year of published, recoverable addresses is a year of permanent loss. A tourniquet applied in 2026 is worth more than a cure promised for 2029, and I say that as someone who is generally allergic to urgency arguments in this industry. What I am not convinced by is the ordering of the fix. The design hardens a wallet against a machine that does not exist while the service on the other side publishes addresses in a format that leaks metadata to any observer with a spreadsheet. If I had one engineering hour to spend on Zcash privacy in the NEAR Intents flow, I would spend it on the publication format, not the derivation path. That is the contrarian position and I will defend it: the most dangerous privacy bug in this story is not quantum, it is a timestamp. There is also something worth saying about the bull market we are in, because it shapes how this design will be received. Money is loose. Narratives are cheap. The word quantum is currently doing an enormous amount of marketing work across the entire sector, attached to projects with a hundred million dollars of funding and no shipped code, and readers have learned to skim past it. Zakura's post is the opposite of that pattern: narrow scope, explicit non-claims, a review status on the page, a named constraint that made them reject the clean solution. If you want to know whether a privacy claim is real, look for the constraint the team admits. Teams that admit a constraint have usually done the work. Teams that admit nothing have usually done nothing. What I would watch from here is not the design document. It is three specific things. First, whether Vizor actually ships the library integration in the coming weeks, because software wallets are where the swap flow lives and a design that stays in a library nobody imports protects nobody. Second, whether Keystone and Ledger move on firmware, because the entire shape of this solution was dictated by their signing models and if they do not move, the next design will be constrained the same way. Third, whether NEAR Intents changes what it publishes, because that is the change that would make the quantum conversation moot rather than merely managed. And I would watch the restore path, because that is where users will meet this design, and users do not experience cryptography. They experience a spinner and then a number. If the number is zero and the truth is not, the elegance of the derivation scheme will not matter to them, and it should not. Trust the process, but verify the code, and verify the code on a phone with two bars of signal in Yaba, not on a laptop in a conference demo. My spreadsheet from 2020 is still in that folder. Four hundred and twelve addresses, published inside a closed group, six years of chain history behind each of them, all of it ciphertext waiting for a machine. I cannot unpublish them. Nobody can unpublish anything. That is the whole lesson, and it is why I think this design, with all its awkwardness and its thirty-address guess and its PIR server nobody has named yet, is pointed in the right direction. The next time someone hands me an address to publish, I want the wallet to be the thing that makes it harmless, not my judgement about who is reading. So here is the question I am left with, and I am putting it to the Zakura team and to anyone building a wallet that integrates this: when the restore stops at thirty and the account looks empty, what does the user see? If the answer is a spinner that resolves to zero, then we have built a quantum-resistant privacy system that fails the only test that ever mattered, which is whether a person with a slow connection and a real payment can trust what their wallet tells them. The code will tell us. It always does, eventually.