Policy and Compliance
This page gathers the facts about Skyhook and the Skyhook Bridge that matter to policy and compliance readers. Skyhook is the mechanism for verifying shielded Zcash payments on other chains; the Skyhook Bridge is the swap protocol built on it, which this grant completes, and most of what follows concerns the bridge. Other applications of Skyhook may make different choices. It describes how the system works and who controls what; it does not draw legal conclusions, which depend on jurisdiction and on how each deployment and interface is run. Each section links to the pages where the mechanisms are documented in full.
Who holds the funds
No one does. When a swap opens, the requester’s ETH is locked in a contract that releases it only when given a proof that the agreed Zcash payment was mined and is final, or returns it to the requester after the request’s refund time (The Life of a Swap). There is no key, operator or committee that can move escrowed funds in between, and no step at which a party “recognizes” a deposit.
The Zcash side is held by no one either. A liquidity provider pays the requester directly from its own shielded wallet and never deposits ZEC anywhere beforehand (Providing Liquidity). This is the main structural difference from custodial bridges and exchanges, where funds in transit sit with an operator who can hold them; the comparison page documents one such hold, of a user’s $589,000, lasting more than two months.
Finality, the evidence that a Zcash payment really happened, is also established without trusted parties: anyone can build a rollup, oracles submit blocks that the contract verifies itself, and no one votes (Chain Finality).
Who operates it
The grant funds open, reusable contracts, in the way Uniswap v2 is a public good, rather than a bridge run by the Skyhook team. Each deployment, for example one by the Zcash Foundation, is operated under its own governance, typically a DAO or a multisig, and sets its own parameters (What Lives On-Chain). Frontends, wallets and liquidity servers built on top are run by whoever chooses to run them.
Deployments are also interchangeable. Anyone can redeploy their own copy of the contracts, as with Uniswap, and a new copy can keep using an existing deployment’s block store, and so its oracles, rather than starting from scratch. No deployment is therefore a chokepoint: the protocol has no administrative key, and even if a particular deployment were run with one, new swaps could simply move to another copy. Swaps already open in a deployment remain governed by that deployment’s contracts until they settle or are refunded.
What stays private, and what doesn’t
- The sender of a Zcash payment is always private. The contract checks the payment without learning who made it.
- Until Milestone 3, a swap reveals the recipient’s address and the amount on Ethereum. The test web wallet uses a fresh address for each swap, so swaps can’t be linked through it.
- No viewing key is ever involved. An address can receive funds and nothing else; it cannot decrypt any transaction, reveal a balance, or spend.
- Liquidity providers are never identified on-chain, because they are the senders of shielded payments. The liquidity server they connect to does see what they advertise and how their device connects.
The full breakdown, with an interactive comparison against a leaked viewing key, is on the Milestone 3 page, and What Leaks, and to Whom steps through each role, including what users’ own setups can leak.
Voluntary disclosure
Skyhook keeps Zcash’s existing model of selective disclosure. A user who wants to show their activity to an auditor, an exchange or a tax authority can share their own viewing key, which reveals their transactions to that party alone, exactly as they could for any other Zcash use. Skyhook neither requires this nor prevents it, and because it never needs a viewing key itself, using the bridge doesn’t put one at risk.
Where policies can apply
The protocol has no administrative key that can freeze a swap, and no operator to instruct. Policies such as screening or jurisdictional restrictions can still be applied at the layers above it, by the parties who run them:
- Frontends decide which requests they display and submit.
- Wallets decide which swaps they let their users make.
- Liquidity servers decide which requests they route to providers, and providers decide which requests they fill.
This mirrors how the rest of the ecosystem works, and keeps such decisions with identifiable operators of services rather than inside shared infrastructure.
Parameters someone controls
A careful reader should know exactly where discretion exists. Each deployment controls three parameters, through whatever governance it chooses:
| Parameter | What it does | Worst case if mismanaged |
|---|---|---|
| Difficulty floor | The minimum proof-of-work difficulty the contract accepts | Spam; it can’t move funds or stall the bridge |
| Leftover address | Receives funds a faulty script leaves behind, so they can be requested back | The deployer holds those leftover funds until they are returned |
| Oracle fee curve | How a rollup’s fee is shared with oracles, capped at half | Rollups route around overpriced oracles |
The leftover address is the only place where a deployer can come to hold user funds, and only funds that a script failed to distribute. Whether it should instead default to the requester is an open design question for the committee and for each deployer.
Relationship to Zcash
Skyhook modifies no Zcash code and needs no change to the Zcash protocol. Code that others may reuse ships as independent crates and packages under the Apache 2.0 license, and the research it rests on is published as an IACR ePrint preprint.