Skyhook and ESMASTe: Cross-chain Bridging, Messaging and Execution Layer

1. Executive summary and decision snapshot

Strahn Cryptography Pte. Ltd. requests $255,000 over nine months for Skyhook and ESMASTe: shielded Zcash cross-chain bridging, messaging, and programmable execution. Abhinav Vishnu would lead protocol research and development, supported by Samriddha Kumar on UI/UX and integrations and researchers hired as needed. The application is under review. [1][4]

The applicant describes delivery before collecting milestone payments, but the supplied evidence does not establish a complete funding schedule. Its strongest capability signal is a reported automated Sepolia ETH → TAZ beta, alongside an earlier reverse-direction beta and working programmable-payment functionality. These are applicant claims, not independent acceptance results. [4][5]

Decision inference: The central evaluation questions are whether the mechanism withstands independent security review, whether delivery and costs can be made objectively testable, and whether compatible payment terms exist. [1][4][5]

2. Applicant and team track record

• Abhinav Vishnu: Reports ZCAP membership, longstanding Zcash development, published research including the Skyhook paper, and a commissioned security audit for a Zcash community startup. The supplied evidence contains no audit report, client assessment, or independently assessed research results. [1]
• Samriddha Kumar: Described as a university graduate with UI/UX and development experience, responsible for interface design, integrations, documentation, tooling, and UX research. Additional graduate researchers and PhDs would be hired on stipends. [1]
• Prototype continuity: The applicant says the earlier TAZ → ETH beta may now be offline or nonfunctional because of funding constraints and offers to arrange a test. [4]

Prior ZCG delivery and independently documented outcomes: No grounded evidence found. This does not establish that the team has no prior grants.

3. Proposal scope, milestones, budget, technical approach, and dependencies

Scope: The proposal targets bidirectional Zcash–Ethereum value transfer and shielded-payment-triggered actions on programmable chains, including token/NFT minting. ESMASTe supplies programmable payouts; broader chain support is described as possible rather than separately specified funded delivery. [1][4]

Approach: The applicant attributes payment verification to Zcash’s transaction-hash tree structure and Blake2/Blake2b. It proposes full FlyClient sampling for finality, permissionless oracle participation to reduce costs, and a root-anchored rollup fallback if oracles disappear. These are design assertions, not demonstrated security guarantees in the supplied evidence. [1][4]

Milestones and budget: Beyond the total, duration, and a reference to “Milestone 3,” No grounded evidence found for milestone amounts, startup funding, dates, detailed acceptance criteria, staffing allocations, audit costs, or contingency. The applicant does agree to intended-user validation of deliverables. [1][4]

Privacy boundary: The applicant says senders remain private, but recipients’ addresses are visible until Milestone 3; viewing keys are not exposed. [4]

4. Community discussion, arguments, responses, and resolution

Strongest case for: The applicant presents a reusable public good enabling contracts to accept shielded ZEC without an operator, committee, or admin key for the described escrow mechanism. A supporter expresses intent to use it and sees potential liquidity benefits, while acknowledging not having read the full proposal. That supports interest, not demonstrated demand or independent technical validation. [4][6]

Strongest immediate obstacle: The applicant states the grant would not work if paid directly in ZEC, citing researcher payments and regional legal requirements. Financial Privacy Foundation responds that ZCG pays only in shielded ZEC and cannot pay USD. The payment policy is clarified; applicant acceptance or a workable arrangement remains unresolved in the supplied discussion. [5]

Trust-model clarification: Asked about permissionless wrapped ZEC, the applicant says deposits could be trustless but withdrawals would require a validator committee. This narrows the permissionless claim for wrapped assets; it does not establish the same limitation for the separately described atomic swaps. [1][6]

The applicant also argues that a formal business contract and payment after delivery would virtually eliminate risk. Evaluation inference: Those terms could strengthen accountability but would not establish protocol safety or eventual usage. No substantive independent technical rebuttal or resolution is documented. [5][6]

5. Relevant precedents and documented outcomes

• Zcash–Avalanche Elastic Subnet Bridge: The closest functional comparator. ZCG approved $210,433 for an initial phase targeting production-ready bridge software and a GUI deployed to testnets. Members praised communication and expressed delivery confidence, while explicitly accepting uncertain adoption and concerns about cost and priority. Post-award delivery or usage outcomes: No grounded evidence found. Approval alone cannot establish bridge impact. [11]
• VibeQuest: Learn, Build, Prove: Relevant to prototype credibility and adoption evidence, not bridge architecture or budget. ZCG declined the $22,800 request after members reported inability to start lessons, inadequate concrete examples, quality concerns, and weak expected engagement and lasting value. Inference: Its applicable lesson is to test the product and substantiate demand, not transfer its educational-platform judgment to Skyhook. [12]

6. Material risks and execution considerations

• Security and economic feasibility — inference: Novel payment verification, cross-chain finality, oracle-independent fallback, and escrow release warrant reproducible adversarial testing and transaction-cost measurement before production exposure. Independent audit findings, failure-case results, and measured execution costs are absent. [1][4]
• Capacity — inference: Protocol development, research coordination, and publication concentrate on the lead, while additional researchers remain prospective hires. Hiring delays or limited reviewer capacity could constrain the nine-month scope. [1][4]
• Adoption — inference: Permissionless liquidity provision is an enabling feature, not a liquidity commitment. The supplied discussion provides enthusiasm but no committed providers, integrators, volume targets, or sustained usage results. [4][6]
• Privacy communication — inference: Acceptance testing and user disclosures should distinguish sender privacy, recipient visibility, and the trust assumptions of each product rather than treating “trustless” as a universal property. [4][6]

7. Material gaps and questions for the applicant

• Can the company accept shielded-ZEC payments through a legally workable arrangement, and what contractual terms would it require?
• What startup amount and milestone payments sum to $255,000? For each milestone, specify deliverables, dates, acceptance tests, and the intended-user representative who signs off.
• Which swap directions, networks, ESMASTe functions, and privacy improvements are committed within nine months? Is wrapped ZEC included or merely an extension?
• Can independent reviewers reproduce both beta directions and inspect the implementation, threat model, failure tests, finality assumptions, fallback behavior, and measured transaction costs?
• Who will conduct independent security review, what budget covers remediation, and what findings would block production release?
• What named staffing commitments, liquidity-provider interest, integration commitments, and measurable post-launch usage targets support delivery and value?

8. Neutral decision considerations

Committee options, not an approval or rejection recommendation:

• Separate contractual feasibility from technical merit: settle payment compatibility before negotiating an executable funding commitment.
• Distinguish research validation from production readiness. A bounded validation phase could precede wider deployment commitments.
• If considering milestone funding, connect disbursement to reproducible tests, independent review, explicit privacy boundaries, and verified user acceptance—not status labels or demonstrations alone.
• Evaluate value through both reusable infrastructure and credible adoption plans. Neither technical promise nor community enthusiasm should substitute for measurable outcomes.

These are proposed evaluation conditions, not evidence that the applicant has agreed to them.

9. Numbered source list

• [1] Grant Application - Skyhook and ESMASTe: Cross-chain Bridging, Messaging and Execution Layer — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/480
• [4] Skyhook and ESMASTe: Cross-chain Bridging, Messaging and Execution Layer — posts 1–5, part 1 — https://forum.zcashcommunity.com/t/skyhook-and-esmaste-cross-chain-bridging-messaging-and-execution-layer/58167/1
• [5] Skyhook and ESMASTe: Cross-chain Bridging, Messaging and Execution Layer — posts 1–5, part 2 — https://forum.zcashcommunity.com/t/skyhook-and-esmaste-cross-chain-bridging-messaging-and-execution-layer/58167/3
• [6] Skyhook and ESMASTe: Cross-chain Bridging, Messaging and Execution Layer — posts 6–10 — https://forum.zcashcommunity.com/t/skyhook-and-esmaste-cross-chain-bridging-messaging-and-execution-layer/58167/6
• [11] Zcash-Avalanche Elastic Subnet Bridge — comparison summary — https://forum.zcashcommunity.com/t/zcash-community-grants-meeting-minutes-5-1-23/44577
• [12] VibeQuest: Learn, Build, Prove — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/373