Milestone 1: The Reverse Direction
Milestone 1 makes Skyhook bidirectional. The public beta moves value in one direction only, from ETH into shielded ZEC. This milestone adds the reverse: converting shielded TAZ (testnet ZEC) into ETH, with the same atomicity guarantees, inside an ordinary browser wallet session. One direction demonstrates the mechanism; two directions make a bridge, letting users enter and leave the shielded pool through the same trustless path. The milestone delivers a WebAssembly library that puts the necessary cryptography in the browser, and a swap interface for the new direction.
Context
The existing direction already shows that the settlement machinery works: requests lock funds, intents bind action data, and inclusion proofs release escrow, all without trusting the counterparty. The reverse direction exercises the same machinery with the roles exchanged. That exchange is why this is a milestone rather than a feature, because any asymmetry between the two directions, in trust assumptions, depth of verification or failure handling, would show that the mechanism works for one flow by accident rather than by construction.
In the reverse direction, the shielded side has to go first. The user’s wallet builds the Zcash transaction, the EVM verifies its inclusion, and only then is the ETH released. This inversion touches every stage of the swap lifecycle, including how requests are formed and how claims are authorized, and the milestone covers the complete inverted flow.
Deliverables
WebAssembly library
The first deliverable moves note-building cryptography into client software, compiled to WebAssembly with Rust bindings. Key generation, trial-decryption, note opening with full randomness derivation, and commitment computation all run in the page, so no server is needed for any operation that involves secrets. The aim is integration rather than novelty: to show that the bridge’s cryptography fits inside wallet-shaped applications, in browsers and other constrained environments.
The library exposes exactly the operations a wallet needs and nothing more. Seeds come from the platform’s random source and chain data from a lightwalletd proxy, and openings leave as structured data ready for building an intent. The module holds no network handles, no filesystem access and no entropy source of its own. It is built against the constraints of in-browser use: threading requirements for proving in the browser, and careful handling of wallet birthdays during synchronization.
Swap interface
The second deliverable is a usable interface for the new direction. Its requirements are deliberately minimal, so that evaluation needs only a browser wallet and testnet funds and non-technical committee members can perform the acceptance test themselves. The interface guides the user through forming a request, shows the state of quotes and intents, submits the lock transaction, and follows the request to its conclusion, mirroring the beta with the assets’ roles swapped.
Synchronizing a mainnet wallet is deliberately out of scope. It would require birthday management, extended scanning ranges and production key custody, all of which belong to later hardening rather than to proving that the mechanism works both ways.
Place in the program
Every later milestone assumes bidirectional transfer. Programmability (Milestone 2) means little over a one-way rail, recipient privacy (Milestone 3) must cover both directions, and the liquidity standard (Milestone 5) can’t describe a market with one side missing. Building the reverse leg first turns each of those from a demo feature into a bridge feature. The short three-week schedule reflects that the settlement machinery already exists: only the inverted flow, the client library packaging and the interface remain.
The milestone also reuses the beta’s evaluation method. Independent forum participants operated the ETH-to-TAZ beta and reported their results publicly; the reverse direction will be evaluated the same way, by the same kind of reviewer, under the same testnet conditions and the same standard of unassisted completion. Comparing the two directions directly would expose any difference in behavior, which would need to be investigated before later milestones build on it.
Status
Done
The client-side cryptography exists and is tested. A WebAssembly crate provides key generation, note opening with trial-decryption, full randomness derivation including nullifiers, and commitment computation, compiled from the same pipeline sources the server uses. Native golden tests pass 8 out of 8, including the commitment vector verified on the EVM; a Node smoke test reproduces the golden commitment byte for byte through the compiled module; and both the Node.js and browser targets build cleanly.
The server-side note operations are also proven. The pipeline binaries for scanning, opening, witnessing, filling and broadcasting executed a live 50 TAZ testnet transfer, verified by byte-identical comparison and by decrypting the value and memo with the outgoing key. The ETH-to-TAZ interface runs live against this stack.
Remaining
The reverse-direction interface and its end-to-end integration with a browser wallet remain. With the cryptography and the pipeline built, what is left is to assemble the TAZ-to-ETH user flow from them: the interface first, then the wallet wiring, and finally the acceptance demonstration of a complete swap executed in a browser.