The Zcash Side

The Zcash side of Skyhook covers everything that happens on Zcash before a contract on Ethereum can verify a payment: the structure of the shielded notes being spent, the shielded pool they live in, and the software that finds, spends and checks them. The contracts consume exactly three values from each note (its commitment cmx, its nullifier, and the first 52 bytes of its ciphertext), and everything described in this section exists either to produce those values correctly or to protect the secrets behind them.

The section moves from static structure to process. Anatomy of a Note defines every field of a note, because every later operation refers to them. Ironwood and Branch Identifiers describes the pool introduced by network upgrade NU6.3, because witnesses and digests depend on which pool a note belongs to. The Pipeline then follows a real transaction through the five stages that build and verify it.

Who learns what

Each note is seen differently by different parties. The recipient’s wallet learns everything about it by trial-decrypting it with its viewing key, and the sender can recover the same information with the outgoing viewing key. The Skyhook contract learns the commitment, the openings it is recomputed from, and fragments of the ciphertext: enough to verify a payment, never enough to decrypt or spend anything. Until Milestone 3, those openings put the recipient’s address and the payment’s value on Ethereum, where anyone can read them. No viewing key ever crosses the boundary, and an address cannot decrypt any transaction; the sender stays entirely hidden. Auditors assessing privacy should check that nothing beyond these values crosses the boundary.

Pools and pipeline in brief

Zcash has two shielded pools with separate commitment trees and digests. Orchard holds historical activity, and Ironwood has received all new shielded activity since NU6.3. The note format and action encoding survived the transition, so Skyhook’s verification needed no changes, but each pool’s trees must be kept strictly apart and transactions must carry the current consensus branch.

The pipeline has five stages, each a separate program: scanning finds the notes a key owns, opening derives their full contents, witnessing produces a Merkle path to a recent root, filling builds and proves the spending transaction, and broadcasting submits it and verifies the result. The pipeline page traces a live 50 TAZ testnet transfer through all five.

Conventions

Field sizes are given at first mention. Hex strings are lowercase without a prefix unless stated otherwise, and block heights refer to the Zcash test network unless labeled as mainnet. Prior familiarity with shielded transactions at the level of How It Works is assumed; Orchard internals are not.