Grant Proposal

Terms and Conditions

• I agree to the Grant Agreement terms if funded
• I agree to Provide KYC information if funded above $50,000 USD
• I agree to disclose conflicts of interest
• I agree to adhere to the Code of Conduct and Communication Guidelines
• I understand all milestone deliverables will be validated and accepted by their intended users or their representatives, who will confirm that the deliverables meet the required quality, functionality, and usability for each user story.
• I agree that for any new open-source software, I will create a CONTRIBUTING.md file that reflects the high standards of Zcash development, using the librustzcash style guides as a primary reference.
• I understand when contributing to existing Zcash code, I am required to adhere to the project specific contribution guidelines, paying close attention to any merge, branch, pull request, and commit guidelines as exemplified in the librustzcash repository.
• I agree to post request details on the Community Forum
• I understand it is my responsibility to post a link to this issue on the Zcash Community Forums after this application has been submitted so the community can give input. I understand this is required in order for ZCG to discuss and vote on this grant application.

Application Owners (@Octocat, @Octocat1)

@strahnio, @viabhinav, @ItsViolet

Organization Name

Strahn Cryptography Pte. Ltd.

How did you learn about Zcash Community Grants

Forum.

Requested Grant Amount (USD)

255,000

Category

Infrastructure

Project Lead

Name: Abhinav Vishnu
Role: Lead Researcher and Protocol Developer
Background: Member of the Zcash Community Advisory Panel (ZCAP). Long-term history of development in the Zcash ecosystem, published several papers including the Skyhook paper (IACR ePrint 2026/2210), and commissioned for a paid security audit by a Zcash community startup.
Responsibilities: Major protocol development, conducting and coordinating research, reviewing and publishing papers

Additional Team Members

- Name: Samriddha Kumar
  Role: UI/UX developer
  Background: University grad with major UI/UX design experience
  Responsibilities: Reviewing and designing UI/UX for the main bridge and app, as well as conducting UX research
- Further graduate researchers and PhDs to be hired as required on stipend

Project Summary

Our research on the Skyhook Bridge enables programmable payment recognition and expectation in Turing-complete correspondent chains for cross-chain value transfer directly in the shielded pool trustlessly, enabling atomic swaps, decentralised liquidity bridging, and countless extensions.

Project Description

Skyhook is a Zcash-to-Ethereum (and vice-versa) bridge that allows trustlessly transmitting value and messages from the Zcash shielded pool (Orchard/Ironwood) to Ethereum (and any Turing-complete chain, such as Solana), via the use of new mechanisms recently discovered.

It allows Ethereum (or any other Turing-complete chain's) contracts to mint NFTs or tokens or perform any given action based on the guaranteed completion of an action on the Zcash shielded side, such as minting an NFT after a payment is confirmed to be made to the public key of the previous owner without revealing who sent the payment on the Zcash side, or minting wrapped tokens after verifying that payment was made to a given fixed public key without revealing who the sender is on the shielded pool.

Further, by extending this primitive, the Skyhook Bridge (separate from the Skyhook mechanism) allows any party to coordinate locking Ethereum and therefore facilitating a secure, bidirectional swap, such as a LP providing their public keys to send shielded ZEC to in exchange for unlocking Ethereum, or you providing Ethereum in a lock with your shielded Zcash public key to receive ZEC securely and atomically.

For finality, we rely on the FlyClient mechanism adopted in Zcash, using full multi-sample FlyClient by default (about 30 sampled blocks for a 100-block gap, growing logarithmically to about 250 for 100,000 blocks), plus the main block and 3 head blocks, which stays secure even if no participant checks anything off-chain. This is made cheap by crowdsourcing blocks from oracles and/or other users, which are very cheap to run (an oracle only costs ~$40/day to run to publish every single block, and gets to collect transaction fees if needed in the protocol to recoup costs; the Zcash Foundation or ZCG can also run public-good oracles). With oracle-stored blocks, initiating a rollup costs about 1.1-1.6M gas (1.1M for the main block's Equihash plus 2,100 gas per sampled block). A user can always choose to bypass this process and verify all finality blocks themselves, over several transactions if no oracle has stored them, ensuring the system always remains trustless. Parties who check the chain themselves can instead agree on a trusted block root at quote time (online-offline finality), which skips proof-of-work for blocks under that root and always completes in a single transaction (about 5-13M gas), even if no oracle has submitted a block for three months.

Proposed Problem

To date, no major and fully trustless bridge in or out of shielded Zcash has been seen. Almost all bridges either require manual shielding and use central pools with low liquidity (THORChain), or provide shielded services but with incredible centralisation (NEAR Intents reserves the right to freeze withdrawals or deposits and put them on hold; FROST-based red.bridge relies on validator consent to recognise a deposit).

Proposed Solution

We use the ZIP-244 (and extended ZIPs, which further define transaction identifier unmalleability) to essentially use the unmalleability property as a way to generate unique, resilient intent identifiers which natively protect the source of funds as well as the sender details. Further details are provided in the reading material section as a paper which is already submitted to IFCA Financial Cryptography 2027.

Our research and proven mechanism allows users to break out of the proposed problem, as well as contracts on other Turing-complete chain, to establish their own, independent bridges into the Zcash ecosystem, to power anything the Turing-complete chain can. This greatly extends the programmability of Zcash tokens, including using the correspondent chain as a virtual Layer-2 while maintaining the transfer in shielded Zcash as a Layer-1.

Essentially, once the decentralised Skyhook Bridge is fully online, ANYONE can simply put up their shielded ZEC on the order book as a liquidity provider, and respond to requests of ZEC on Ethereum by charging a fee. The transfer they do is fully private even without NIZKs (since only the recipient public key, i.e. their address, is revealed, never a viewing key, their sender key is fully private), and they receive yield in form of the exchanged token (such as ETH, in form of original order amount + fee), without ever locking up their ZEC for an extended period, and vice versa.

A demonstration of this bridge in action (only ETH -> TAZ for now, with UI taken from Li.Fi, to save on development time), was publicly posted to the forum (https://forum.zcashcommunity.com/t/its-here-a-beta-fully-automated-sepeth-taz-atomic-shielded-swap-bridge/57931), where multiple forum users tested it and were incredibly happy with the results. Please note that the demonstration does not yet use NIZKs, and therefore will reveal the recipient public key (the recipient's address, never a viewing key; an address cannot decrypt any transaction), however, in most use cases, this is equivalent to NEAR Intents and viable on its own.

Further, this grant covers research for ESMASTe (Extended Sandboxed Merkleized Script Tree Evaluator), an application-layer engine designed to transmit private logic from Zcash memos that can be parsed by Ethereum side bridges at the time of execution to execute arbitrary logic. Essentially, the user can set a 32 byte ciphertext as a Merkle root, complete a swap, and leave the money dormant in a newly created executor contract. When they want to execute the script, they provide a private leaf preimage for whatever leaf they choose to execute via a relayer, allowing private execution on Ethereum similar to Taproot. A prototype for ESMASTe is also under active development and committee members, feel free to request a demonstration by notifying us.

Solution Format

• A usable bridge as a website and a self-hostable repository of code, that allows hosting a completely new copy of the bridge and all smart contracts on Ethereum. A Solana version may be done in a further grant extension.
• Research papers (other than the one already published; detailing finality, feasibility and proofs of any new primitives we may introduce in the course of further research)

Dependencies

There are no dependencies.

Technical Approach

We use Solidity and Yul to author the core smart contract code for Ethereum, use Sepolia and Zcash Testnet to test it.

We use Apache 2.0 since we expect the code to be reused by other projects, even as-is, but the unique names or trademarks for the bridge must not be reused or advertised as affiliated. Apache 2.0 provides the sweet spot for this. You may notice the key paper this is based on has a CC-BY-NC license, but we are the authors of the paper and therefore provide a full copyright waiver.

Upstream Merge Opportunities

It does not modify any upstream repositories. All code that may be adapted later will be crates and/or packages independent of upstream.

Open Source License

Apache 2.0

Hardware/Software Costs (USD)

25,500

Hardware/Software Justification

Paying for dedicated server slots to run builds and prototype infrastructure for all 9 months, as well as paying for miscellaneous costs during the entire 9-month research run.

Service Costs (USD)

9,500

Service Costs Justification

Paying for provider RPCs such as Alchemy for multiple chains to run continuous fuzzing and simulations. These costs add up quickly: we ran out of our $5,000 Alchemy grant in 1.5 months of research.

It's lower here because we'll use the hardware costs provided to set up our own RPC nodes, and phase out of Alchemy completely within maximum 2 months.

Compensation Costs (USD)

220,000

Compensation Costs Justification

• Lead Researcher is being paid $134,750 for 9 months (~$180,000 per year rate), well below industry standard rates for a major researcher in this field (source: Paradigm lead track researchers are paid $390,000 per year)
• The rest of the funds go as follows:
• • Samriddha (UI/UX developer) is paid $41,250 (~$55,000 per year rate) as a part-time UI/UX developer, for our bridges and integrations
• • $44,000 is reserved for hiring graduate students if required to assist in research.

Total Budget (USD)

255,000

Previous Funding

No

Previous Funding Details

No response

Other Funding Sources

Yes

Other Funding Sources Details

We ran a donations campaign along with our prototypes, during which we received donations totalling $54.85 from community members in good faith, which we used to pay for the server for the following months. Further, community member dismad also donated 512 TAZ to our test liquidity pool, which we are very grateful for!

Implementation Risks

As with any grant, there are implementation risks to this project, namely, the Zcash Network Upgrades (NU7) scheduled to be deployed soon which would reduce block times and require additional testing and research to make sure the transition is seamless to a ZSA-compatible format. We already tackled the Ironwood transition to v6, so we are confident we can tackle this change too.

Further, an implementation risk would be that the NIZK would become too unviable for mainnet, which is why we are proactively choosing Base as the home network for the bridge due to its relaxed limits even for future additions, and users can always choose to not use NIZKs (we prioritise user autonomy).

The project depends heavily on its lead researcher, but the risk to ZCG is limited. The mechanism is already demonstrated in a public beta, only the $25,000 startup funding is paid in advance, and every milestone is paid on delivery and is independently usable, so completed work keeps its value even if development stops partway.

Security audits are out of scope for this grant. An audit cannot be priced until development concludes and the final size and complexity of the code are known, so audits will be funded separately once development is complete.

Potential Side Effects

There are no potential side effects as this primitive does not interact with any existing tools or libraries in the ecosystem, nor donates anything upstream. The Zkool2 integration (Milestone 4) and protocol integrations (Milestone 5) are demonstrated in local forks, so the upstream projects are left unchanged.

Success Metrics

We consider the project a success when:

• An operational decentralised liquidity bridging operation can be performed on both sides (bidirectionally) while obscuring at least the sender.
• ZEC holders can demonstrably earn yield on such a bridge without locking or unshielding funds while maintaining complete privacy.
• A private program can be executed on Ethereum as a script lock without revealing unexecuted logic, similar to Taproot.

Startup Funding (USD)

$25,000

Startup Funding Justification

To purchase the hardware, as well as Alchemy credits to begin the runway. Since this is a project we are resuming rather than beginning, the need for Alchemy and other RPC provider credits, as well as build credits, is now, not after milestones start.

Milestone Details

- Milestone: 1
  Amount (USD): 20000
  Expected Completion Date: 5 weeks from approval
  User Stories:
    - "As a user, I should be able to swap shielded TAZ to ETH atomically, not just ETH to ZEC as shown in beta"
  Deliverables: 
    - A TAZ to ETH WASM library (with Rust bindings) to demonstrate that it is possible to integrate the bridge into wallets which use Rust or WASM out of the box
    - A usable UI for ZEC -> ETH swap, but not necessarily support syncing a mainnet wallet or accepting external funds
  Acceptance Criteria: Must be able to perform a TAZ to ETH swap using a browser loaded wallet
- Milestone: 2
  Amount (USD): 40000
  Expected Completion Date: 11 weeks from approval
  User Stories:           
    - "As a TAZ to ETH swapper, I should be able to program what my swap does or lock what the relayer can do with the swapped funds"
  Deliverables:
    - A JavaScript ESMASL (Extended Sandboxed Merkleized Script Language) constructor, as well as evaluator contracts
    - A UI in the bridge prototype to construct and program basic ESMASL programs for swaps, to achieve swaps similar to @GGuy's vision in https://forum.zcashcommunity.com/t/the-future-of-atomic-swaps/42861/1
  Acceptance Criteria: The deliverables must be functional and testable by community/committee members
- Milestone: 3
  Amount (USD): 55000
  Expected Completion Date: 18 weeks from approval
  User Stories:
    - "I want the recipient public keys to be secure during swaps, so both sides are shielded"
  Deliverables:
    - A full NIZK circuit evaluated on-chain to hide recipient addresses.
    - Alternatively, an online-offline NIZK that does the same thing but with off-chain interaction.
  Acceptance Criteria: Can do an atomic swap where the recipient public key appears nowhere in the transaction data.
- Milestone: 4
  Amount (USD): 45000
  Expected Completion Date: 24 weeks from approval
  User Stories:
    - "As a wallet developer, I want to be able to use a standard swap bridge on a mobile device or in my existing wallets"
  Deliverables:
    - A prototype Android app, as well as bindings for Rust, Kotlin and Swift
  Acceptance Criteria: We will demonstrate that the libraries work in a fork of Zkool2 (developed by @Hanh)
- Milestone: 5
  Amount (USD): 35000
  Expected Completion Date: 30 weeks from approval
  User Stories:
    - "As a user, I want to be able to coherently put up my ZEC for swaps"
    - "As a user, I want to be able to coherently manage who or what I swap with"
    - "As a major protocol such as Maya Protocol or NEAR Intents, I want to be able to integrate into the decentralised bridge ecosystem"
  Deliverables:
    - Building a liquidity router, as well as a liquidity server standard and binary for users and wallets to host their own decentralised liquidity nodes to connect to.
    - Reference libraries for the above.
  Acceptance Criteria: Publication of the standard, as well as demonstration of library integration capability via the aforementioned Zkool2 fork.
- Milestone: 6
  Amount (USD): 35000
  Expected Completion Date: 39 weeks from approval
  User Stories:
    - "As a user, developer or auditor, I must be able to coherently understand the entire infrastructure"
  Deliverables:
    - Finalised documentation for the entire ecosystem.
    - Ensuring publication of any produced research papers as preprints (IACR ePrint) by this deadline.
  Acceptance Criteria: Being able to view and verify the aforementioned deliverables.

Supporting Documents

Main paper: https://eprint.iacr.org/2026/2210
Proposal site: https://skyhook-proposal.strahn.dev/