The Address Is the Artifact: A Cold Review of Zakura's Per-Swap Viewing Keys for Zcash

Zakura's engineering page carries two words that decide how everything below should be read: in review. The Zcash node and wallet team has published a design, not a release. No commit hash. No activation height. No third-party audit. What exists is a document describing how to give every shielded address posted during a NEAR Intents swap its own viewing key.

Adam Tucker, who wrote it, states the underlying fact without decoration: 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."

That sentence is correct. It is also more damaging than the proposal that follows it, because it describes a structural property of the protocol rather than a bug in a wallet. Zcash's shielded pool was designed so that address diversity would substitute for key diversity. Against a classical adversary, that substitution holds. Against an adversary running Shor's algorithm on a cryptographically relevant quantum computer, it does not hold at all. The diversifier diversifies the string. It does not diversify the secret.

No such machine exists. That is the entire reason this is a design document and not an incident report. But a permanent public ledger does not care when the adversary arrives. It only cares that the ciphertext was written down.

I have spent most of my career on exactly this class of problem: the gap between what a cryptographic construction proves and what an operational system actually publishes. The math here is not the weak point. The weak point is that the design accepts a permanent, timestamped, value-bearing public artifact as a fixed constraint, and then optimizes around it.

Here is what the artifact is, what the fix buys, and what it quietly sells.

What an Incoming Viewing Key Actually Is

Zcash's shielded architecture is a hierarchy, and the hierarchy is the vulnerability.

A spending key sits at the root. From it, a wallet derives a spend authorizing key and a nullifier key. Together with an outgoing viewing key, those form the full viewing key. From the full viewing key, a deterministic pseudorandom function produces the incoming viewing key — the IVK. The IVK is the thing that lets a wallet trial-decrypt notes addressed to it. It is the read capability. It is not the spend capability, and that distinction matters enormously for the threat model, because it means a compromised IVK drains nothing. It only reveals.

Now the address. A Sapling address is a pair: a diversifier, which is a short byte string, and a transmission key derived by hashing the diversifier to a curve point and multiplying by the IVK. In Orchard the curves change — Pallas and Vesta instead of BLS12-381 — but the algebra is isomorphic in the way that matters here. The transmission key is a scalar multiple of a group element whose scalar is the IVK.

That is the whole problem in one line. An address is a commitment to the IVK under discrete logarithm. Discrete logarithm is precisely what Shor's algorithm solves.

Recover the IVK and you can trial-decrypt every note the account has ever received, at every diversifier, for the entire history of the chain. Not just future payments. The ones already written down, years ago, by counterparties who have since rotated keys, changed employers, or died.

This is the harvest-now-decrypt-later doctrine, and it is not speculative in the way people casually assume. The doctrine does not require a quantum computer to exist today. It requires only that someone is archiving the chain today, which they are, in multiple jurisdictions, at multiple levels of completeness. The decision to break the assumption is deferred; the data collection is not.

Zcash's unified address specification made this worse in a subtle way that few users internalized. A unified address can carry multiple receivers — an Orchard receiver, a Sapling receiver, and, if the wallet is careless or the user is migrating from legacy tooling, a transparent pay-to-public-key-hash receiver. That last one is not quantum-hidden at all. It is an elliptic curve public key in the clear, and it is linkable to every other transparent input and output it has ever touched. A unified address that includes a transparent receiver is a privacy downgrade dressed as a compatibility feature.

When I dissected the ERC-721 metadata layer behind Bored Ape Yacht Club in 2021, the finding that mattered was not that the images were hosted off-chain. It was that the decentralization claim was load-bearing for the valuation and false at the infrastructure level. The same pattern is visible here. Shielded addresses are marketed as unlinkable. They are unlinkable under a hardness assumption that has a known, published, polynomial-time adversary — one that merely requires hardware nobody has built yet.

Why a Swap Publishes What a Payment Does Not

In ordinary Zcash use, the address is a private artifact. You hand it to the person paying you, over a channel of your choosing, and it never touches the chain in cleartext. The chain records a note commitment and, later, a nullifier. Nothing that binds the address to the transaction in a way a passive observer can read.

NEAR Intents inverts that.

Intents-based cross-chain systems work by having a user declare a desired end state and letting competing solvers fill it. The user does not submit a transaction to a bridge contract; they express a constraint, and the solver network resolves it. To make that work for a private asset, the user must supply a refund address — somewhere the protocol can return funds if the intent fails, expires, or is only partially filled. That address is not a secret. It gets published on-chain once the deposit is logged, and it remains published whether or not the user ever recovers a satoshi.

Swaps into ZEC publish the receiving address as well. So a user who swaps in and later swaps out has at least two shielded addresses on permanent public record, plus whatever the solver's own accounting surface exposes.

To a classical observer these addresses look unrelated. Different diversifiers, different transmission keys, no visible thread. To an adversary holding the IVK, they are one account with two timestamps.

The swap did not create the quantum vulnerability. It created the publication event that converts a theoretical vulnerability into a scheduled one.

This distinction is the reason the proposal exists at all, and it is also the reason the proposal is narrower than its framing suggests. Zakura is not fixing Zcash's key hierarchy. It is fixing the fact that a third-party protocol has adopted a habit of writing your address into a public append-only log.

The correct framing is uncomfortable: a privacy coin's threat surface is now partly determined by the disclosure conventions of an interoperability layer that is not a privacy system and was never designed as one. NEAR Intents is doing what intents protocols must do to be auditable and dispute-resolvable. Publishing the refund address is a feature. It is a feature that happens to be incompatible with the survival of a shielded pool across a cryptographic transition.

The Proposal, Stripped

Zakura's change is minimal, and minimality is a virtue in cryptographic engineering. The design alters only the randomness that feeds the viewing key derivation. Each swap gets a fresh key, derived from a hashed index. The spending key is untouched. Funds remain in a single account. The user experience is unchanged.

The rejected alternative is the interesting part. Opening a new account per swap — a genuinely independent spending key, a genuinely independent IVK, no shared root — was considered and discarded. Tucker's stated reason: Keystone hardware wallets 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 sentence twice.

The security boundary of a privacy protocol's quantum migration path was set by the derivation-path conventions of two hardware vendors' firmware. Not by a threat model. Not by a formal analysis of the adversary's capability. By the fact that Keystone's firmware indexes into account zero and Ledger's transaction flow assumes a single account context.

I have written this before and it remains true: assumptions are just risks wearing disguises. The assumption here is that hardware wallet UX is a fixed constraint rather than an engineering variable. It is not fixed. It is a firmware decision, made by a small number of teams, revisable in a release cycle, and entirely outside the control of the protocol that depends on it.

What the design does buy is real, and I want to be precise about it rather than dismissive. Under the current scheme, a Shor-capable adversary who recovers the IVK from any single published address obtains the read capability for the account's entire note history. Under the proposed scheme, the adversary who recovers the IVK from a published swap address obtains the read capability for that swap's notes and nothing else, because the IVK is derived from a hashed index rather than being a single fixed function of the full viewing key.

Critically, the IVK does not yield the spending key. The IVK is a pseudorandom function output keyed by the spend authorizing key; inverting it is not a discrete log problem, it is a preimage problem on a hash. So the blast radius of a recovered IVK is bounded by whatever that specific IVK can decrypt. Scoping the IVK scopes the damage. That is a genuine improvement, and it is cheap, and it is backward compatible with the existing note structure.

The spending key remains singular, however. And that is where the design's protection ends.

Blast Radius: What the Fix Buys and What It Sells

A compact accounting is useful here. Consider an account that has participated in N swaps over its lifetime, each publishing one shielded address.

| Adversary capability | Single IVK (today) | Per-swap IVK (proposed) | Fresh account per swap (rejected) | |---|---|---|---| | Recovers one published address's key | Decrypts all N swaps, full memo and value history | Decrypts 1 swap | Decrypts 1 swap | | Recovers the root spending key | Decrypts all N swaps | Decrypts all N swaps, plus the index map | Decrypts all N swaps only if the wallet's seed derivation is enumerable | | Public artifacts on chain | N addresses, 1 key behind them | N addresses, N keys behind them | N addresses, N independent keys | | Restore cost from seed | 1 chain scan | Up to N chain scans | N chain scans, N account derivations |

The first row is the win. The second row is the problem nobody wants to discuss.

Under the proposed design, the spending key is unchanged, and the per-swap IVK is derived from a hashed index. If an adversary obtains the spending key — by Shor against a spent note's revealed spend validating key, by device compromise, by seed extraction — they can derive every IVK for every index. The index space is small. Indices are sequential integers. Enumeration is trivial.

The scheme therefore relocates the single point of failure rather than eliminating it. It moves the catastrophic key from the viewing layer to the spending layer. That is not nothing — the spending key is not published on-chain, whereas the IVK is recoverable from a published address — but it is a narrower claim than "closes a quantum privacy gap."

There is a second, sharper observation. In Zcash, the spend validating key is revealed in the clear when a note is spent, because the spend authorization signature requires it. That key is a scalar multiple of the spend authorizing key. Against a Shor-capable adversary, a single spent note from the account reveals material that leads back to the spending key — and from the spending key, every per-swap IVK falls out deterministically.

So the honest description of the design is this: it protects the viewing layer against a quantum adversary, and it does not protect the spending layer, and the spending layer is the one that unlocks the viewing layer. The proposal reduces the probability of a partial compromise. It does not change the consequence of a total one.

That is a defensible trade. It is not the trade the marketing sentence implies.

Restore Is the Hidden Cost Center

More keys means more scanning. This is the operational tax, and it is where most privacy designs quietly fail.

A standard Zcash wallet restores from seed by trial-decrypting every note in the shielded pool against its IVK. With one IVK, that is one pass over the chain. With N per-swap IVKs, a naive restore is N passes. For an account with a few dozen swaps over three years, that is tolerable. For a wallet with two hundred, on a phone, over a mobile connection, it is not.

Zakura's mitigation has three components. First, the wallet leaves itself an encrypted memo recording each swap's index. Second, it checks published block filters to narrow the candidate set. Third, it 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 stops after thirty consecutive unused ones.

Each of these is individually reasonable. Together they form a chain of dependencies where the weakest link sets the security of the whole.

Start with the memo. The wallet writes an encrypted memo to itself containing the index. On restore, the wallet needs to find that memo. To find the memo, it needs the IVK for the note containing it. To derive the IVK, it needs the index. The index is in the memo.

This is circular unless there is a bootstrap path — most plausibly, that the index registry notes are written to a base address derivable from the account-level key, which is always scannable on a first pass. If that is the design, then the base address becomes the master linkage point: one address, one key, and every swap index in the account's history encrypted under it. That is a smaller surface than today's, but it is the same shape. If that is not the design, the restore path has an unresolved dependency that I would flag as review-blocking.

I have not seen a specification resolving this. The engineering page describes the mechanism; it does not, in the material I can read, close the bootstrap question. The math holds, but the humans did not verify it — and in a design review, the unverified human step is where implementations diverge.

The Gap Limit Is a Probability, Not a Guarantee

Stop after thirty unused addresses in a row.

This is a heuristic borrowed from hierarchical deterministic wallets, where the gap limit exists because an address space is unbounded and a wallet must decide when to stop looking. Bitcoin wallets use twenty. Zakura uses thirty.

The heuristic is not wrong. It is a truncation, and truncations have tail behavior.

If a user's swap indices are contiguous — 0, 1, 2, 3 — the gap limit never binds. If a user's indices have gaps — because a swap failed before the index was consumed, because a wallet restored from an older backup and re-derived, because two devices raced on the same account — then the thirty-unused rule can terminate the scan before reaching a funded address. The failure mode is silent. The wallet reports a balance that is lower than reality, and the user has no signal that anything is missing.

There is a second-order issue. The scan pattern itself is observable by whatever serves the filters. A wallet that walks addresses in strict index order and stops at a fixed gap produces a query signature that is structurally distinguishable from random. PIR hides which address was queried. It does not hide that a sequential walk occurred, or where it stopped. That is a metadata leak, and metadata is what actually deanonymizes people in practice.

Correlation is the comfort of the unprepared. The per-swap design's entire claim is that a quantum adversary cannot correlate addresses across swaps. It says nothing about a classical adversary correlating the timing of the swap, the size of the deposit, the solver that filled it, and the moment the refund address appeared on chain. Those four facts are public today, in cleartext, and they are sufficient to cluster a meaningful fraction of swap activity without any quantum computer at all.

PIR Hides the Question, Not the Answer

Private information retrieval is the most interesting primitive in the proposal, and the most under-examined.

PIR lets a client query a server for a record without revealing which record. In this context, the wallet asks a light-client server which NEAR bridge payouts match its per-swap addresses, and the server cannot tell which addresses were asked about. That is a real and non-trivial privacy property, and it is the correct primitive for the job.

But PIR protects query privacy. It does not protect response completeness.

A malicious or compromised server can return an empty set for a query and the client cannot distinguish that from a genuine miss without performing a full scan of the chain. The client's only defense is redundancy — querying multiple independent servers and cross-checking — which reintroduces a correlation surface of a different kind, since the same wallet now queries several operators with the same structurally identical request.

There is a subtler problem. The filters the wallet checks are published by a server. A server that omits a block from the filter set produces a wallet that never scans that block. The privacy of the query is preserved perfectly. The completeness of the answer is not.

In my 2020 work on Compound's cToken interest rate models, the finding that mattered was not that any single parameter was wrong. It was that the model's correctness depended on an oracle whose latency was assumed rather than bounded, and the edge case lived exactly in the interval where the assumption failed. The same structure appears here: the wallet's correctness depends on a filter server whose honesty is assumed rather than verified, and the failure lives exactly in the interval where that assumption breaks.

Zakura's design would be stronger if it specified a verification path for filter completeness — a checkpointed filter commitment, or a proof of inclusion in the published set — rather than relying on the operational goodwill of the server operator. That is a specification gap, not a fatal flaw, but it is the kind of gap that survives into production because it is invisible until it is exploited.

Firmware as a Security Parameter

The Keystone and Ledger constraints deserve their own section because they reveal how the design was actually bounded.

Keystone hardware wallets sign only from the first account. Ledger devices spend from one account per transaction. These are not protocol properties. They are implementation choices in firmware, and they are revisable.

By accepting them as fixed, the design cedes a security parameter to a party with no stake in Zcash's privacy guarantees. If Ledger ships multi-account transaction support in eighteen months — and there is no technical reason it cannot — the justification for the entire architecture evaporates, and the per-swap IVK scheme remains as accumulated complexity with a diminished rationale.

This is a general pattern in cryptographic engineering, and I have watched it play out repeatedly since 2017, when I spent two weeks proving that Tezos's on-chain governance voting did not guarantee consensus stability under Byzantine conditions. The critique was ignored by the retail market and cited by three enterprise developers, which was the correct outcome distribution. The lesson was not that governance is broken. The lesson was that a mechanism designed around the convenience of its current participants inherits the fragility of those participants.

Provenance is a story we agree to believe in. So is the claim that a design is constrained by hardware. It is constrained by hardware today, by the vendors who currently dominate, at their current firmware revision. That is a moving target, and architecture built around a moving target has a shelf life measured in firmware cycles.

The Artifact Multiplication Problem

Here is the inversion I have not seen made anywhere else, and it is the reason I am writing this at length rather than posting a paragraph.

The per-swap IVK design reduces the key blast radius per published address. It does so by converting one published address per account into N published addresses per account.

Privacy is not monotone in the number of public artifacts. Adding artifacts to a permanent ledger can reduce privacy even when each artifact is individually better protected, because the adversary's inference problem is not only about keys. It is about the joint distribution of timestamps, values, and network-level metadata.

Consider what a single published address reveals today: one anchor, one time, one implied account. Consider what N published addresses reveal: a time series. Swap frequency. Swap cadence. The intervals between swaps, which correlate with market volatility and with individual trading behavior. The size distribution of deposits, which is encrypted but eventually decryptable and, more immediately, inferable from solver-side liquidity movements that are not encrypted at all.

Under the current scheme, a quantum adversary who breaks one address gets everything, and a classical adversary who breaks nothing gets one anchor. Under the proposed scheme, a quantum adversary who breaks one address gets one swap, and a classical adversary gets a time series.

The design improves the post-quantum column and degrades the present-day column. That trade may be correct — the post-quantum threat is permanent and the present-day leak is bounded — but it is a trade, and it is not disclosed as one.

The mitigation, if you want one, is to decouple the publication event from the address. NEAR Intents could publish a commitment to the refund address rather than the address itself, revealing it only in a dispute. That is a protocol change on NEAR's side, not Zakura's, and it is the change that would actually matter. Zakura is optimizing the wallet because the wallet is what it controls. That is rational for Zakura and insufficient for Zcash.

Tachyon and the Shelf Life Problem

The design is explicitly a stopgap. Tucker frames it as holding the line until Zcash's planned Tachyon upgrade arrives, which Shielded Labs has positioned as a scaling overhaul of the shielded pool.

A stopgap that has not shipped, protecting against a threat that has not materialized, pending an upgrade that has not shipped either.

That is not a reason to reject it. Defense in depth against a permanent ledger is cheap insurance, and cheap insurance is usually worth buying. But it does mean the design carries migration debt that should be priced explicitly.

If Tachyon changes the key derivation architecture — and a scaling overhaul of the shielded pool plausibly would — then the per-swap index map becomes dead weight. Every wallet that adopted the scheme holds an index registry that no longer maps to anything. The restore path must then support both derivations, indefinitely, because the old notes are still on chain and still need to be found. That is the standard cost of a backward-compatible privacy migration, and it compounds: each generation of derivation logic must be carried forward forever, because the chain does not forget.

There is also the question of what Tachyon actually does for the quantum exposure. Scaling is not the same problem as post-quantum security. A faster shielded pool with the same discrete-log address construction has the same harvest-now-decrypt-later exposure, just at higher throughput. If Tachyon does not change the address algebra, Zakura's stopgap becomes permanent infrastructure by default.

I would want to see the answer to one question before treating this as a bridge rather than a destination: does Tachyon change the relationship between the incoming viewing key and the address encoding? If yes, the design has a defined lifetime. If no, it does not.

The Transparent Receiver Nobody Mentions

One open question I cannot resolve from the published material, and which I flag as a review item rather than a finding.

NEAR Intents handles cross-chain assets. Not all of them are shielded. If a swap route touches a transparent Zcash address — a t-address — then the quantum argument is irrelevant because the leak is immediate and classical. A transparent address is an elliptic curve public key in the clear, linked to every input and output it has ever touched, with amounts visible in plaintext.

The proposal addresses shielded refund addresses. It says nothing about the routing layer's address selection. If a wallet's default behavior under some conditions emits a transparent receiver, then the entire per-swap IVK construction protects a surface the user is not actually using.

This is exactly the failure mode I documented in 2021 when I traced BAYC's metadata to a single AWS node. The decentralization claim was true at the layer being discussed and false at the layer doing the work. Here, the quantum privacy claim may be true at the key derivation layer and false at the address selection layer. The second layer is the one users touch.

I would want an explicit assertion in the specification that per-swap refund addresses are always shielded-only, with no transparent fallback, and a test vector demonstrating it. Absent that, the guarantee is conditional on wallet behavior that is not part of the design being reviewed.

What the Bulls Got Right

Three things, and they are not small.

First, the harvest-now-decrypt-later framing is correct, and the Zcash community was early to it in a way most of the industry still is not. A permanent public ledger means that any confidentiality guarantee resting on a hardness assumption has a shelf life, and the adversary chooses when to open the box. Scoping the reading capability per transaction is the cheapest available mitigation for that class of risk, and it is available today, with no consensus change.

Second, the design is honest about its own limits in a way that is rare. Tucker states the vulnerability in plain language, states that no quantum computer exists, and states that the work is in review. That is more disclosure than most teams provide, and it should be rewarded rather than punished.

Third, the refusal to open a new account per swap is defensible on grounds the privacy community routinely ignores: a design that breaks hardware wallet signing does not get adopted, and an unadopted privacy feature protects nobody. Adoption is a security property. A theoretically perfect scheme used by four people on a laptop has a smaller anonymity set than a slightly weaker scheme used by forty thousand. The team chose the larger anonymity set. That is the correct instinct even if the constraint that forced the choice is contingent.

And the broader point stands: Zcash's shielded pool is the only production system where this problem is even legible. On a transparent chain, there is no viewing key to scope because there is no privacy to lose. The fact that this is a live design question is evidence that the protocol is doing something real.

Takeaway

Zakura has published a competent, narrow, backward-compatible mitigation for a real structural weakness, and it has done so with unusual candor about the fact that it has not shipped. That is the correct behavior for a team in this position.

The design's claim is smaller than its framing. It scopes the viewing layer, not the spending layer. It reduces the blast radius of a partial compromise and does nothing about a total one. It multiplies public artifacts while reducing per-artifact exposure, and it does not disclose that trade. Its restore path has an unresolved bootstrap dependency and its gap limit is a truncation with a silent failure mode. Its most interesting primitive, PIR, protects query privacy but not response completeness.

None of these are reasons not to ship. They are reasons to ship with a threat model written down, rather than a sentence about hardware wallet UX standing in for one.

The question I would put to the team is not whether the cryptography holds. It does. The question is whether the constraint that shaped it — two vendors' firmware conventions — is a parameter or an assumption. If it is a parameter, the architecture has a lifetime. If it is an assumption, then the design has already told you what it is: a risk, wearing a disguise.