zswap by stalllion labs

1. Executive summary and decision snapshot

Stallion Labs requests $50,000 for ZSwap, a formal specification, feasibility verification, and testnet demonstration of privacy-preserving atomic swaps involving shielded ZEC—not a production service. The request is under review. Funding comprises $5,000 startup, $17,000 for milestone 1, and $28,000 for milestone 2.[1][8]

The strongest capability signals are self-reported blockchain engineering experience and a specific claim to have verified an Orchard signing interface against source code.[1][4] Inference: the decisive issue is whether this team can resolve the protocol’s fund-locking and recovery problems, rather than merely demonstrate signature integration; community scrutiny exposed a vulnerability the applicant acknowledged.[5]

2. Applicant and team track record

The application assigns:

• Prince Eniola Egbedele: protocol specification, cross-curve research, and external cryptography-review coordination; reports developer-relations and Stellar infrastructure experience.
• Robert Abimbola: Orchard feasibility work and testnet implementation; reports full-stack, blockchain, and payment-application experience.
• Similoluwa Abidoye: documentation and reviewer outreach; reports three years in Web3.[1]

The team explicitly says it has no completed prior ZCG grant to demonstrate delivery.[4] For independently verified cryptographic research credentials, shipped-project outcomes, or accepted prior grant deliverables: No grounded evidence found. The supplied backgrounds establish claimed experience, not demonstrated capacity to deliver a new cryptographic construction.[1]

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

The proposed mechanism uses RedPallas adaptor signatures: completing a spend-authorization signature would reveal a secret enabling the counterparty’s claim. The applicant says orchard::pczt::Action::apply_signature in Orchard v0.12.0 accepts externally produced signatures without an Orchard fork.[4]

Two acknowledged research dependencies are cross-curve secret compatibility with Bitcoin or Solana and a formal lock/reveal ordering proof. External cryptographic review is an assigned responsibility, but the supplied evidence contains no reviewer commitment.[1][4]

The applicant confirms that milestones contain user stories, deliverables, and acceptance criteria.[8] However, for their actual milestone-by-milestone contents, deadlines, labor allocation, review costs, and treatment of unsuccessful feasibility research: No grounded evidence found. Consequently, payment arithmetic is established, but cost reasonableness and enforceable acceptance gates cannot yet be assessed.

4. Community discussion, arguments, responses, and resolution

• Strongest argument for: the applicant deliberately limits the request to specification and feasibility before production investment, identifies unresolved technical questions, and invites scrutiny. It presents signature-level operation as a potential privacy advantage over transaction-linking approaches.[4]
• Strongest objection: Strahn Cryptography argues that adaptor signatures alone do not lock funds, allowing a competing spend or refund to defeat atomicity. The applicant agrees the draft permits unilateral spending and proposes a two-party FROST key plus presigned recovery transactions as a possible remedy—not a demonstrated fix.[5]
• Novelty and differentiation: the applicant argues an alternative ZEC–EVM design leaks transaction-linking information. Strahn responds that a NIZK-based privacy fix is underway and cites recent adaptor-signature literature contradicting the applicant’s broad novelty claim. The applicant says it is checking that research; no revised comparison is supplied.[6][7]
• Capability dispute: Strahn questions whether AI-assisted discussion reflects independent technical understanding and recommends against funding. The applicant says AI combined the team’s own thoughts. Strahn later apologizes for its attitude toward AI-generated proposals.[6][7]

Resolution: the vulnerability was acknowledged, not resolved. The apology addresses tone, not protocol correctness. Swap directionality, safe recovery, and comparative privacy remain unsettled in the supplied discussion.[5][6][7]

5. Relevant precedents and documented outcomes

• ZeWiF — $121,200, approved. Relevant as specification-first interoperability work followed by Rust libraries and implementation tooling. Committee rationale included clear deliverables, an identified migration need, and supportive expert review. All five milestones and the grant are recorded complete; no adoption or asset-recovery results are supplied, so those labels do not establish impact. Inference: its strongest lesson for ZSwap is the value of identifiable users and committed technical reviewers, not a comparable price benchmark.[12]
• ZKFIED — $45,000, declined. Relevant because it combined shielded Zcash, threshold signatures, and cross-chain cryptography at a similar funding scale. Documented reasons included poor fit with current funding priorities, insufficient user demand, and concern that the concept was generated rather than grounded in an applied need. Inference: this supports testing ZSwap’s concrete ecosystem value; it does not establish that ZSwap shares those shortcomings.[14]

6. Material risks and execution considerations

Inferences from the supplied technical discussion:

• Research uncertainty: the grant could produce a useful negative feasibility result rather than a working swap. Acceptance terms should distinguish those outcomes.[4][5]
• Scope expansion: the proposed joint-key remedy introduces additional design and recovery work beyond simply applying external signatures; effort estimates may need revision.[5]
• Differentiation risk: evolving competing designs and newly cited research could narrow the claimed privacy or novelty advantage during delivery.[6]
• Future deployment risk: even successful testnet delivery would not establish production safety or user adoption; those are outside the stated deliverable.[1]

7. Material gaps and questions for the applicant

• Protocol safety: what revised state machine prevents unilateral spending, premature secret extraction, and loss when either party aborts? Which swap directions does it support?
• Bounded scope: which counterparty chain and curve are committed deliverables, rather than exploratory options?
• Independent assurance: who will review the construction, what expertise and availability have they committed, and who has authority to accept the proofs?
• Payment conditions: what artifacts, deadlines, and adversarial tests unlock each payment? What happens to later funding if feasibility fails?
• Budget and capacity: how are engineering time, cryptographic research, and external review priced, and which prior artifacts demonstrate relevant competence?
• Incremental value: after reviewing the cited literature and alternative designs, what specific unresolved capability remains, and which intended integrators want it?

8. Neutral decision considerations

Committee judgment framework: evaluate this as a bounded research purchase, not a near-term exchange product. The relevant benefit is independently reviewable knowledge that could enable safer shielded interoperability.

Possible funding conditions include a frozen initial chain pair, a named independent reviewer, an accepted revised threat model, and staged release against reproducible artifacts. A committee could also require a preliminary safety review before committing the full scope.

A sound evaluation should distinguish useful research failure from incomplete delivery and weigh the demonstrated technical response more heavily than the discussion’s tone. These are options for committee consideration, not an approve-or-reject recommendation.

9. Numbered source list

• [1] Grant Application - zswap by stalllion labs — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/453
• [8] Comment on #453: Grant Application - zswap by stalllion labs — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/453#issuecomment-5884774668
• [4] ZSwap: A Shielded Atomic Swap Specification for Zcash — Grant Application & Request for Review — posts 1–5, part 1 — https://forum.zcashcommunity.com/t/zswap-a-shielded-atomic-swap-specification-for-zcash-grant-application-request-for-review/57884/1
• [5] ZSwap: A Shielded Atomic Swap Specification for Zcash — Grant Application & Request for Review — posts 1–5, part 2 — https://forum.zcashcommunity.com/t/zswap-a-shielded-atomic-swap-specification-for-zcash-grant-application-request-for-review/57884/3
• [6] ZSwap: A Shielded Atomic Swap Specification for Zcash — Grant Application & Request for Review — posts 6–10 — https://forum.zcashcommunity.com/t/zswap-a-shielded-atomic-swap-specification-for-zcash-grant-application-request-for-review/57884/6
• [7] ZSwap: A Shielded Atomic Swap Specification for Zcash — Grant Application & Request for Review — posts 11–15 — https://forum.zcashcommunity.com/t/zswap-a-shielded-atomic-swap-specification-for-zcash-grant-application-request-for-review/57884/11
• [12] Zcash Extensible Wallet Interchange Format (ZeWiF) — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/3
• [14] Grant Application ZKFIED — comparison summary — https://github.com/ZcashCommunityGrants/zcashcommunitygrants/issues/167