The refund address does not expire.
When a user swaps ZEC through NEAR Intents, the wallet hands over a shielded refund address, NEAR logs the deposit, and the address goes on-chain. It stays there whether the swap completes, fails, or gets refunded three weeks later. Swap into ZEC and the receiving address gets published too. To an observer the strings look unrelated โ different prefixes, different checksums, no visible thread.
They are not unrelated. One incoming viewing key sits behind all of them.
Zakura, the team that maintains Zcash node and wallet software, published a design this week that gives each of those published addresses its own viewing key. Adam Tucker wrote the post. The engineering page lists the work as in review. It has not shipped, and nothing on-chain has changed. Two words, in review, carry the entire risk profile of the announcement.
A design document is not a deployment. That is the sentence worth keeping in view for anyone reading this as a Zcash bull case.
Zcash's shielded pool runs on a single-account abstraction. Each shielded account holds one spending key and one incoming viewing key. The IVK decrypts every note addressed to any address derived from that account. Derive a thousand addresses, publish a thousand of them, and a thousand strings still resolve to one key.
Deriving the key from an address is not feasible on classical hardware. It is feasible, in principle, on a machine large enough to run Shor's algorithm against the curve primitives involved. No such machine exists. Tucker is explicit about the conditional: 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 trigger is not Zcash's own wallet flow. In ordinary use a holder hands an address to a payer privately, once. NEAR Intents inverts that. It is a cross-chain swap service that publishes addresses as part of its settlement path, converting a private handoff into a permanent public artifact.
Intent-based architectures trade metadata for execution quality by design. The solver needs to see the order to fill it; the fill needs to be verifiable on-chain; verification needs an address. That is the architecture working as specified, not a defect in NEAR's implementation. The cost lands on the user's privacy, and until now nobody had priced it at the wallet layer.
Zakura's proposal is scoped narrowly: change only the randomness feeding IVK derivation. The spending key stays put. Funds stay in one account. Each swap gets a fresh IVK derived from a hashed index, so a single published address stops unlocking the payment history of every other one.
Zakura is not a protocol team. It builds the node and wallet plumbing that other people's Zcash runs on, which is why a design doc from them carries more weight than a thread from a privacy influencer โ and also why the ship date depends entirely on other teams' firmware.
The design decision worth studying is the one they rejected.
Opening a fresh account per swap would be the clean cryptographic answer. Zakura ruled it out on hardware constraints. Keystone wallets sign only from the first account. Ledger devices spend from one account per transaction. Tucker called that "not an acceptable UX to us," which is the correct read โ a privacy primitive that forces users to move funds between accounts before every swap loses to the version that doesn't.
So the spending key stays. Only the IVK derivation changes. If-then: if the only thing rotating is the viewing key, the on-chain footprint of the account is unchanged, and the only new attack surface is the index.
That index is where the engineering gets interesting. Restoring a wallet from seed with N viewing keys means N chain scans. That is a linear cost function against a chain that only grows, and it is the kind of thing that looks fine in a design doc and turns into a support ticket at scale.
Zakura's mitigation: the wallet writes itself an encrypted memo recording each swap's index, then on restore reads the memo, checks published filters, and uses private information retrieval to query matching NEAR bridge payouts without the server learning which addresses were asked about. For swaps into ZEC, where no inbound memo exists, the wallet walks addresses in order and stops after 30 consecutive unused ones.
I have timed wallet recovery before. In 2023, while auditing node sync behavior after the Solana halt, I built a small RPC health checker and then used it to measure how long three wallet implementations took to reach a usable state from seed. The spread was not subtle โ the slowest was more than an order of magnitude behind the fastest, and bandwidth was not the variable. Scan count was.
That is what the 30-unused-address heuristic actually is. A termination condition, not a privacy guarantee. If a user generates 40 swap addresses and only 25 ever receive funds, the wallet may stop early. If indices are sparse and the gap pattern is unusual, the scan runs long. Both outcomes are recoverable. Neither is free.
PIR is the other dependency worth pricing. It hides the query from the server, which is the right property, but it adds a round trip and a trust assumption about the PIR implementation itself. Privacy primitives sitting in the critical path of a wallet restore have a habit of being the first thing disabled when a user complains about load time.
And the memo is a single point of failure by construction. Lose it โ restore from seed on new hardware, corrupt a database, migrate a device โ and the index map is gone. The wallet falls back to sequential scanning. Privacy survives. UX does not.
What the design actually buys, concretely: an attacker who breaks one published address recovers one swap's value and memo instead of the account's lifetime history. Compartment size drops from everything to one transaction. That is a real reduction in blast radius, and it is measurable โ which is more than can be said for most privacy announcements this cycle.
Compare that to the alternative most wallets would reach for: one account, one key, and a promise not to publish addresses. That promise is unenforceable. The moment a settlement path publishes an address โ and any cross-chain route that settles on-chain will โ the promise is broken and the account's entire history is exposed to whoever ends up holding the key. Compartmentalization is the only mitigation that does not depend on counterparty behavior.
Zakura also inherits a dependency it does not control. If Tachyon ships first and removes the single-key exposure at the protocol level, this whole design becomes a compatibility shim. A fine outcome for users, a bad one for anyone building a roadmap on it.
Here is the part the quantum framing obscures.
The vulnerability Zakura is patching does not require a quantum computer. It requires a viewing key. Viewing keys get disclosed constantly โ to auditors, to counterparties in a dispute, to tax preparers, to the compliance desk that asks for read-only access. Any party holding an account's IVK today can link every payment that account has ever received. Not in 2035. Now.
So the honest description of this design is not quantum readiness. It is key compartmentalization. The quantum scenario is the upper bound of the threat model. The disclosure scenario is the operating condition.
That distinction changes who should care. If the risk is quantum, the timeline belongs to somebody else and the correct move is to wait for Tachyon and keep using the pool. If the risk is disclosure scope, the correct move is to rotate keys per counterparty now โ which is exactly what this design does, and why "in review, not shipped" is the actual news in the post.
The quantum narrative is also convenient for a market that needs one. Every cycle produces a threat that justifies a new primitive, and quantum has been the designated threat for privacy coins since at least 2021. That does not make Zakura's work marketing โ the design is specific, the constraints are named, the rejection of per-swap accounts is documented against real vendor behavior. It just means the framing should be read as framing.
The second thing the framing hides is the gate. It is not cryptography. It is firmware. Zakura expects software wallets built on its libraries, Vizor among them, to integrate "in the coming weeks." Hardware follows when firmware supports it. Ledger and Keystone were named as constraints on the original design, and they are the same two vendors that decide whether the shipped version reaches anyone holding size.
The ledger remembers what the code tries to hide. Every refund address from every NEAR Intents swap is sitting on-chain right now, waiting for a key that might one day be derivable. You cannot retroactively un-publish them. This design buys a smaller blast radius on the next swap, not immunity for the last ten thousand.
Watch three things, none of them the quantum narrative.
Whether Tachyon lands on a schedule that makes per-swap keys redundant before they ship. Whether Vizor's integration survives contact with real restore times, because a wallet that takes four minutes to recover from seed after a swap is a wallet users abandon. And whether the hardware vendors treat firmware support as a roadmap item or a favor.
Trust the math, verify the chain, ignore the hype. I trade the gap between expectation and execution. The expectation here is a privacy upgrade. The execution is an IVK derivation change gated on firmware, with a heuristic termination condition and a PIR dependency in the restore path. Those are not the same product, and only one of them is on the engineering page.
The measurable test is a stopwatch. Time a restore from seed on the shipped build and compare it to the same wallet before the change. If it has doubled, the privacy is real and the adoption is not.