Every ZEC swap routed through NEAR Intents leaves a permanent public artifact on a public chain: the shielded refund address, published the moment the deposit is logged, and never removed โ not on completion, not on refund, not on abandonment. That artifact is a hash, and to a classical machine it is noise. Zakura, the team building Zcash node and wallet software, published a design that tries to keep it that way. The proposal: derive a distinct incoming viewing key for every shielded address that appears in a NEAR Intents swap, so that a future quantum adversary who cracks one address learns nothing about the others.
The design is in review. It has not shipped.
Adam Tucker, who wrote the post, states the underlying constraint without decoration: until Zcash's planned Tachyon upgrade lands, "a single published shielded address lets a quantum attacker link every payment that address's key has ever received." That sentence is the entire problem. The rest of the document is an argument about how much of it can be deferred.
A Zcash shielded account has one incoming viewing key. Every address that account ever hands out โ one per invoice, one per merchant, one per swap โ is a diversifier over the same underlying material. Diversification is not segmentation. The addresses look unrelated on-chain. The key behind them does not.
Classical computers cannot invert that relationship. Shor's algorithm, run on a machine with enough stable logical qubits, could. No such machine is public. This is the recurring shape of post-quantum engineering: you are asked to spend real complexity today against an adversary who is, by every available measurement, late.
Ordinary Zcash use keeps the exposure small. You hand an address to a counterparty privately, they pay, the address is never published. NEAR Intents breaks that pattern structurally. A user swapping ZEC for another asset supplies a shielded refund address to the wallet; NEAR publishes it on-chain once the deposit is logged, and it stays there regardless of outcome. Swaps into ZEC publish the receiving address the same way. The bridge is doing what a bridge must do โ reconciling a deposit to an on-chain event โ and the byproduct is a durable, indexable, permanently public record of an address that was designed to be handed out once, in private.
That is the gap. Not a bug in Zcash. Not a bug in NEAR Intents. A collision between a privacy primitive built for one-shot disclosure and a routing layer built for public reconciliation.
Zakura's fix is deliberately narrow. It changes only the randomness feeding the viewing key, deriving a fresh key per swap from a hashed index. The spending key is untouched; funds remain in a single account. That restraint is the design's virtue and, as I will get to, its ceiling.
The obvious alternative โ a new account per swap โ was ruled out on hardware grounds. Tucker writes that Keystone devices sign only from the first account, and Ledger devices spend from one account per transaction, "which wasn't an acceptable UX to us." Read that twice. The cryptographic architecture of a privacy system is being constrained by the signing model of two consumer wallets. That is not a criticism of Zakura; it is an accurate description of where the industry's design authority actually sits. Firmware determines cryptography, and firmware is shipped by two companies.
The cost of more keys is restore time. One full chain scan per key, historically. Zakura's design routes around it: the wallet leaves itself an encrypted memo recording 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 were queried. For swaps into ZEC, the wallet walks addresses in order and halts after 30 consecutive unused ones. The 30 is a heuristic, and heuristics leak. A scanner that stops at a fixed depth is a scanner with a signature.
Private information retrieval is a trust assumption, not a proof. PIR removes the server's ability to see which address you queried; it does not remove the server. Someone still answers the query, and honest-but-curious is doing real work in that sentence. The design also checks published filters before querying โ filters are public, and a filter check is a fingerprint. Whether that leaks at the network layer depends on infrastructure Zakura does not control. I have watched this movie before. The cryptography holds; the deployment leaks. Static analysis reveals what marketing hides, but it does not reveal what the network sees.
Now the part the design does not address, and the reason I would not treat this as closed.
The threat model is internally inconsistent. The proposal assumes an adversary who recovers a viewing key from a published address but not the spending key. Shor's algorithm is not selective in that way. The surface it actually attacks is the public key material that appears on-chain when a note is spent โ and from that material, the spending key is the prize, not the viewing key. If a quantum adversary obtains the spending key, every derived viewing key in the scheme is reachable by re-running the same deterministic derivation across the same hashed index space. Per-swap key rotation raises the cost of a partial compromise. It does nothing against a total one. Tucker's framing concedes this without naming it: the spending key stays the same, so funds remain in a single account. Correct as an engineering tradeoff. Also an admission that the master lock is untouched.
The index is the new metadata. The encrypted memo records the swap index. The index is what reconstructs the key. So the memo is not incidental bookkeeping โ it is the recovery path, and it sits inside the same trust boundary as the wallet. Compromise the wallet, enumerate the indices, derive the keys. The attack surface moved from the chain to the client. Whether that is an improvement depends entirely on which you consider harder to breach, and I would not default to the client. A wallet that reconstructs its state from an encrypted memo index must, by construction, be able to decrypt that memo without the user present. Zakura does not claim otherwise, but the framing โ quantum attacker, published address โ directs attention at the chain and away from the device, which is where the key material now concentrates.
The proposal is forward-only. Nothing in the design reaches back to addresses NEAR Intents has already published. A per-swap key derived today cannot retroactively segment a key that was already exposed, because the exposure is not the key โ it is the linkage. The design reduces future accumulation. It does not reduce the accumulated set.
And "decentralized" privacy infrastructure still publishes to a public ledger. The permanent refund address is not an accident of NEAR Intents; it is what on-chain reconciliation requires. A bridge that can prove a deposit landed is a bridge that leaves a record. This is the same ledger-entry logic that governs every claim of ownership in this industry โ ownership is a ledger entry, not a feeling โ and privacy claims are subject to the same arithmetic. A shielded address that is published is not shielded. It is a hash with a timestamp.
Where does the work stand? In review, unshipped. Software wallets using Zakura's libraries, Vizor among them, are expected to add it "in the coming weeks." Hardware wallets follow firmware. Assume malice, verify everything, trust nothing โ including ship dates announced in a market paying a premium for privacy narratives.
Here is what the bulls have right, and it is more than the skeptics will credit.
The design is cheap where cheap matters. Changing only the viewing-key randomness means no new account model, no change to the spending path, no change to the shielded pool's commitment structure. A privacy improvement requiring no fund migration is a privacy improvement that can actually be adopted, and adoption is the only metric that has ever mattered for privacy tooling. Every ambitious post-quantum redesign in this space has died in the gap between the paper and the wallet.
The team also published its limits. Tucker names the exact gap, names the constraint that produced the workaround, and names the pending upgrade that would make the whole exercise unnecessary. The proof is in the logic, not the promise โ and a design document that states what it does not solve is worth more than a launch post that states what it will.
And the honest read on the quantum timeline: it is not now. The correct posture is not panic. It is amortization โ reduce what a future adversary can learn from artifacts you are publishing today, because those artifacts are not retractable.
The real deadline in this document is Tachyon, not the quantum computer. Until Zcash's upgrade lands, every NEAR Intents swap deposits a permanently public hash into a corpus that no future re-keying can reach backwards into. You cannot rotate a key you have already published. You can only limit what it opens.
So the question worth asking Zakura is not whether per-swap viewing keys work. They do, within a narrow model. It is what happens to the addresses already on-chain. Complexity is the camouflage for incompetence only when nobody audits the model. Here the model is auditable and the gap is documented, which is a better outcome than most of this cycle will produce.
Ship the patch. Publish the migration plan for the historical set. And stop describing an address that a bridge wrote to a public ledger as shielded.