SkyhookRoadmap: What Gets Built

Milestone 3: Full Privacy

Funded by this grant

Milestone 3 extends Skyhook’s privacy from the sender to both sides of a swap. Today the sender is completely private, but the recipient’s public key, that is, their address, is visible on-chain; no viewing key is ever exposed. That is the same level of privacy offered by the leading intent-based systems and the right scope for a beta. This milestone adds a zero-knowledge circuit that proves a payment went to the right recipient without revealing who that recipient is. It is accepted when a reviewer can inspect an executed swap and find no recipient public key anywhere in its transaction data. It is the largest milestone in the program because circuit engineering carries the most uncertainty.

Starting point

Stating the starting point precisely matters, because it defines what the circuit has to do. No sender key, sender address or sender linkage appears on-chain at any stage of a swap today. The recipient’s public key does appear, because the beta mechanism pays a named address without any hiding circuitry. That was a deliberate choice: it separated the risk of the settlement mechanism from the risk of the cryptography, so the bridge could prove settlement first and defer hiding to this milestone.

The baseline also narrows the circuit’s task. It has to hide the recipient within a mechanism that already works, rather than invent payments and privacy at the same time. Note commitments are already recomputed exactly on-chain, nullifiers are derived and recorded correctly, and the ciphertext structure is pinned by tests, so the circuit fits into well-characterized interfaces.

An address, not a viewing key

What the beta exposes is the recipient’s address: the diversified base g_d and public key pk_d that any sender must already know in order to pay them. It never exposes, uses or asks for a viewing key. The distinction is the difference between a contained leak and a catastrophic one. An address can receive payments and nothing else: it cannot decrypt any transaction, reveal any balance, show when a note is spent, or authorize spending. A leaked unified full viewing key (UFVK), by contrast, would let anyone read every incoming and outgoing transaction of the wallet, past and future. No viewing key is involved at any point in a Skyhook swap.

The swap does reveal a little more than the address, and it is worth being exact about what:

  • The address, so an observer can see that a swap paid it. The test web wallet uses a fresh diversified address for every swap, a new g_d and pk_d derived from the same key, so one swap can’t be linked to another through it.
  • The amount, because the contract recomputes the note commitment from openings that include the value.
  • A costly link to the next spend. With enough computation, an observer could in theory link the swap’s note to the transaction that next spends it.

Parties who need more privacy today can use an offline NIZK: they verify the proof off-chain and agree on the note commitment between themselves, so the openings never reach the chain. Milestone 3 brings full privacy on-chain, with an online or online-offline NIZK, and removes all three.

What a swap revealsInteractive

What an observer learnsIf a UFVK leaked
never happens in Skyhook
Skyhook exposes at most a recipient's address, the public key any sender already needs, and never a viewing key. The right-hand column shows, for contrast only, what a leaked unified full viewing key (UFVK) would give away. Each row gives the reason.

For every role in a swap or deposit, step by step and observer by observer, including leaks that come from a user’s own setup, see What Leaks, and to Whom.

Why the recipient is the hard part

Sender privacy follows fairly directly from shielded notes: the spender proves ownership without revealing identity, a guarantee native to Zcash that extends across the bridge without new machinery. Recipient privacy is harder. Settlement has to send funds somewhere specific, and every addressing mechanism available to smart contracts names its destination plainly. Hiding the recipient therefore means proving that a payment went to the correct address without revealing or decrypting that address. Statements of that shape are what zero-knowledge circuits express well and ordinary contract logic can’t express at all, which makes this a cryptography milestone rather than an engineering one.

What full privacy means

After this milestone, inspecting the blockchain reveals neither party to an atomic swap. Amounts remain visible where the transacted values require it, but sender and recipient identities, their addresses, and any link between a swap’s two sides are absent. Correlation and clustering analysis have no endpoints or addresses to work with. Zcash already shields both sides of its own transfers; the milestone brings the same standard to operations that have no native equivalent, such as an Ethereum contract paying a shielded recipient, so that crossing chains never means leaving the shielded set.

Two implementation paths

Two paths are funded deliberately. The primary path is a full NIZK circuit verified on-chain, so that all hiding is enforced by consensus. The fallback is an online-offline NIZK, which achieves the same hiding through off-chain interaction: it costs less on-chain and requires more communication between participants, and its privacy against third-party observers is identical. Whichever path first meets the acceptance criterion ships, and the other remains a contingency.

The two-path structure addresses the schedule risk that dominates cryptography programs. If the full circuit runs into fundamental obstacles, the online-offline variant reuses its constraint design; only the deployment differs. Funding both costs less than funding one path twice after a failure.

Schedule

The twelve-week deadline reflects the realities of circuit engineering: designing the constraint system, which parallelizes poorly; a trusted setup, if one is needed; tuning prover performance; optimizing the gas cost of the on-chain verifier; and an independent audit at the end.

Acceptance

Verification is a check for absence. An evaluator takes the complete transaction data of an executed atomic swap and confirms that the recipient public key appears nowhere in it: not in calldata, emitted events or committed structures. Unlike a claim of presence, a claim of absence can be checked exhaustively, because the transaction record is finite and nothing can hide outside it. The criterion is therefore binary and requires no cryptographic expertise from the reviewer.

Status

Done

The machinery the hiding circuit must fit within is in place and verified. Note commitments are recomputed exactly on-chain, nullifiers are derived and recorded correctly, and the structure of the ciphertext, which carries the diversifier, value and seed, is pinned by tests throughout the pipeline. The beta deliberately leaves the recipient layer transparent, which fixes the exact baseline the circuit must improve on: the sender is fully private today and the recipient public, and the boundary between them is completely characterized.

Remaining

The circuit itself has not been built, and no circuit code exists yet. Either the full on-chain NIZK or the online-offline variant will satisfy the milestone, chosen as described above. Acceptance is a swap whose transaction data contains no recipient public key, verified by inspection.