The Contracts

The Skyhook Bridge contracts are the Ethereum contracts that turn verified Zcash payments into settled swaps. The Skyhook Bridge is one application of Skyhook, the mechanism that verifies shielded Zcash payments; this section describes the bridge, and the Chain Finality and Zcash side sections describe the mechanism it relies on. They hold escrowed ETH, record which counterparty has offered to fill a request, check that the Zcash payment matches the agreed terms, and pay out once a proof against a finalized root arrives. Every swap passes through the same four stages: request and lock, propose, accept and claim. Two exits (refund and cancel) cover the cases in which a swap doesn’t complete normally.

This section assumes the finality machinery described in Chain Finality; readers unfamiliar with roots, anchors and inclusion proofs should read that first. Function names appear as code, and gas figures refer to the deployment profile unless stated otherwise.

Roles

The contract pages use two roles. Alice, the requester, wants ZEC and locks ETH to pay for it. Bob, a liquidity provider, holds ZEC and wants ETH; he pays Alice in shielded ZEC and claims her escrowed ETH. Roles describe positions within one swap, not identities: the same address can be a requester in one swap and a provider in another.

Lifecycle

Main article: The Life of a Swap

A swap opens when Alice locks ETH alongside a 104-byte description of the Zcash payment she wants. Anyone, usually a liquidity provider, can then propose an intent that would satisfy it. Acceptance binds the intent to the request after the contract checks the payment’s note commitment. Once the Zcash payment is mined and final, anyone can submit the inclusion proof, and the full escrow is paid to the proposer. A refund once the request’s refund time passes and a cancellation before acceptance ensure that funds can never be stuck.

Pricing modes

Main article: Bespoke Haggling versus Standing Tickets

Counterparties agree on a price in one of two ways. In bespoke mode the requester writes the terms into the request, including how far below the stated amount she will accept, and anyone may fill it. In standing mode a provider locks ETH once and then signs short-lived, single-use quotes off-chain, whose amounts the contract enforces cryptographically. Both modes settle through the same lifecycle and the same finality machinery.

Providing liquidity

Main article: Providing Liquidity

Only the Ethereum side of a swap locks anything. A shielded ZEC holder provides liquidity by staying online and paying requests it chooses to fill, either by approving each one or automatically up to a limit, and is paid the escrowed ETH, including a spread. Its ZEC is never locked, and as the sender of a shielded payment it is never identified.

Lock-scripts

Main article: Lock-Scripts: Programs as Payouts

A request can instead commit to a program. A flag in the request blob makes the contract also bind a script root hidden in the Zcash note’s ciphertext. Later, anyone can execute the script: the contract checks the root’s position, the transaction’s inclusion and the exact bytecode, then runs the program on the ESMASTe virtual machine, which decides how the escrow is distributed. Execution is final.

Reading guide

Readers building integrations should read The Life of a Swap in full. Readers evaluating liquidity provision should start with the pricing modes, and readers interested in programmability should read Lock-Scripts together with the ESMASTe section. Shared terms are defined in the Glossary.