ZSwap: A Shielded Atomic Swap Specification for Zcash — Grant Application & Request for Review

[peejay-git]

ZSwap: A Shielded Atomic Swap Specification for Zcash — Grant Application & Request for Review

Hi all —we’re Stallion Labs, and we’ve submitted a $50,000 Zcash Community Grants application for ZSwap: a formal specification, feasibility verification, and testnet demonstration of a non-custodial, privacy-preserving atomic swap protocol for shielded ZEC.

GitHub application: Grant Application - zswap by stalllion labs · Issue #453 · ZcashCommunityGrants/zcashcommunitygrants · GitHub
Full technical architecture (C4 diagrams, protocol sequence, security model): ZSwap: Shielded Atomic Swap Protocol for Zcash - Google Docs

The short version

Atomic swaps are named directly on ZCG’s own wishlist under Interoperability. No trust-minimized swap exists today that (a) works with shielded ZEC without sacrificing privacy, and (b) is confirmed against Orchard’s actual code rather than an assumed or invented mechanism. This grant is scoped narrowly and honestly: a specification and testnet proof-of-concept, not a production system — because we think the two genuinely open questions here deserve to be resolved and reviewed before anyone asks for implementation funding, not after.

What we’re proposing

Instead of an on-chain hash-timelock (which would correlate both legs of a swap and defeat the point of using the shielded pool), the protocol uses an adaptor signature over RedPallas — Orchard’s Schnorr-variant signature scheme. Completing one party’s spend authorization signature necessarily reveals a secret that unlocks the counterparty’s funds, with nothing observable on-chain tying the two legs together.

The mechanism relies on orchard::pczt::Action::apply_signature, which we’ve independently confirmed against orchard crate v0.12.0 source: it accepts an externally-produced redpallas::Signature<SpendAuth>, verifies it against the action’s stored verification key, and applies it — no fork of orchard-rs required.

Where this sits relative to existing work — we want to be upfront about this

• Zwap (app.zwap.exchange, live since May 2026) claims an Orchard-native trustless shielded swap, but its described mechanism has drawn credible public objections — that it relies on hash-opcode primitives Orchard’s fixed proving circuit doesn’t actually have. Our mechanism is different in kind: it operates purely at the signature level via a hook we’ve confirmed exists, not an invented opcode. We think this distinction holds, but it needs to survive the same level of scrutiny Zwap’s claims received here, not just our own say-so.
• kayabaNerve’s ASMR ( GitHub - MerosCrypto/asmr: Atomic Swaps for Meros and other cryptocurrencies · GitHub ) already implements genuine adaptor-signature swaps for other chains, with a documented limitation (one party’s refund path depends on counterparty cooperation). Our formal ordering proof needs to explicitly account for this, not repeat it.
• A 2023 proposal (also called “Zwap,” by @hanh) first raised adaptor-signature-based shielded swaps for Zcash and hit the same cross-curve compatibility question we’re tackling, but didn’t proceed past discussion.
• A related but different (transparent-only, non-shielded) cross-chain swap proposal was submitted to ZCG in May 2026 and declined in June 2026.

We’re citing all of this because we’d rather have it raised by us than discovered by a reviewer.

The two open questions we most want scrutinized

1. Cross-curve secret compatibility. No published construction exists yet for Pallas paired with either secp256k1 (Bitcoin) or Ed25519 (Solana). This milestone benchmarks directly against Zwap’s own published DLEQ construction and ASMR, rather than starting from a blank page.
2. Lock/reveal ordering. We need a formal proof that no sequence of actions lets one party extract the secret before the other’s claim is already irrevocable — the same subtlety BTC↔XMR adaptor swaps (Farcaster, UnstoppableSwap) had to solve carefully.

@strahncryptography and @kayabaNerve — given your engagement with the Zwap and ASMR threads specifically, we’d genuinely value your early scrutiny here, before rather than after formal review. If either of the two questions above looks wrong on its face, that’s exactly the kind of thing we’d rather hear now.

Team

We’re a small team (Stallion Labs) — full backgrounds are in the GitHub application. We don’t have a completed prior ZCG grant to point to, so we’re especially open to technical pushback as a substitute for track record.

Happy to answer questions here or on the GitHub issue.

[tloriato]

Are you able to compare with this one? We just did a fully trustless shielded ZEC to EVM atomic swap with no new signing primitives! And yes, it is programmable - #29 by strahncryptography

[strahncryptography]

@peejay-git

@strahncryptography and @kayabaNerve — given your engagement with the Zwap and ASMR threads specifically, we’d genuinely value your early scrutiny here, before rather than after formal review. If either of the two questions above looks wrong on its face, that’s exactly the kind of thing we’d rather hear now.

Well, you asked for it. The biggest issue with adaptor signatures are frontrunning. Since the funds are not LOCKED, how can you ensure that when Bob broadcasts his signature (sending funds to Alice), Bob won’t bribe miners to process a refund transaction before Alice can use the revealed witness to broadcast a transaction from Bob’s wallet? After all, Bob owns his wallet!

This means the swap can only ever happen one way safely, which is ZEC->BTC where BTC can be locked, not the other way around, and STILL need a HTLC setup.

[mahdi.abdile]

Hi ZCG team and community,

I’m seeking feedback before submitting a formal grant application for VaihtoFX, a Kenya-based project building open-source infrastructure to enable Zcash (ZEC) payments and settlement through Kenyan mobile-money rails, initially targeting M-Pesa and Airtel Money.

A key question I would like to clarify is whether regulatory enablement and licensing costs can be included in a ZCG grant where the regulatory work is a necessary prerequisite for deploying the proposed Zcash payment infrastructure.

[peejay-git]

You’re right, and I don’t think the direction restriction is where it lands.

As drafted, nothing stops Alice from spending the note back to herself once she’s handed Bob the adaptor sig - Orchard has no scripting, so there’s no way to pull that leg out of her control the way an HTLC output is pulled out of both parties’ control on Bitcoin. That’s the same hole as the frontrunning you’re describing, just on the other side of it.

But Monero has the exact same problem, no scripting at all and Farcaster/UnstoppableSwap didn’t fix it by restricting direction. They put the locked Monero output under a 2-of-2 aggregate key, so neither party can spend it alone, plus a timelocked refund tx both sides sign before anything gets broadcast. Joint custody, not scripting.

RedPallas already has FROST behind it,ZF’s own threshold Schnorr scheme, RFC 9591, with a RedPallas ciphersuite that exists today. A 2-of-2 FROST spend key on the locked note looks like the direct equivalent of what Farcaster did for Monero. Does that close the hole, or is there something about Orchard/RedPallas that breaks the analogy? If it holds, I don’t see why the swap has to be ZEC→BTC only. Genuinely want to know what I’m missing here.

[strahncryptography]

I would respond if your message wasn’t blatantly AI generated. I do not consider AI-generated proposals or technical discussion to be worthy of answering, since there is no actual substance at all. I might as well argue with Google Search AI.

Using AI is not bad, outsourcing your thinking is.

[peejay-git]

Thanks for pointing me to this, this is a lovely implementation i must say, but ours is a fundamental different apporach, and here is the reason;

you’re using ZIP-244’s non-malleable txid plus native expiryHeight and not doing anything with signatures at all. B commits to exact note params, the EVM contract predicts the resulting txid off that, and either the matching tx lands before expiry (release) or it doesn’t (expire, refund). No lock on the ZEC side in the HTLC sense, no adaptor math, no new curve work. That’s a real win — it’s buildable today and apparently already built.

The trade is privacy, not correctness. To predict the txid, the contract has to see rho, rcm, psi, and the nullifier during the off-chain negotiation, before the ZEC tx is even broadcast. So anyone watching the contract can tie a pending ETH lock to the shape of a specific future ZEC output ahead of time. That’s exactly the on-chain linkage adaptor signatures are meant to prevent from ever existing, not patch after the fact.

ZSwap is going after the harder target: neither leg reveals anything beyond an ordinary-looking transaction, at any point, at the cost of needing a cross-curve adaptor construction that doesn’t exist in the literature yet.

[strahncryptography]

@peejay-git

at the cost of needing a cross-curve adaptor construction that doesn’t exist in the literature yet

Ok no I have to intervene now. WHAT? Did you, like, review the literature? I did when I wrote the thing you reviewed just now, and I was scared sh*tless when I thought I lost my novelty to it.

Just last week: Abe et al. (“Practical Adaptor Signatures for NP from Online/Offline NIZK”) published a NIZK construction for adaptor signatures allowing cross-chain atomic swaps in theory (not immune from frontrunning) where one chain is scriptless. They are accepted to Asiacrypt. Did you not do your research?

Further, the psi/rho/rcm privacy leak, we are fixing via a… NIZK.

[peejay-git]

love bro, hehe na bro, this was never ai thinking at all, it took me and my team 5 solid hours to brainstorming project developement today and when we were almost done we saw your comment an decied to see from our angle and we are still on the call even has we speak, we just use ai to join combined our thought together. please we love to hear your feedback that is why we tag on this post.

[strahncryptography]

Why did it take you 5 hours to brainstorm what is readily available on Google? I expect you to use AI to quickly look this stuff up, I just didn’t expect you to copy-paste from AI (“outsourcing your thinking”). That means you’re either extremely inefficient, or lying, and in either case, I would recommend to the committee against this grant.

[peejay-git]

we have done our research couple of times prior to this time. i think this just happened in recent times, we are currently checking.

[peejay-git]

definitely not only on your reply, but other things concerning the project.

and also we specify in our application that we new in the ecosystem, and we decided to ask questions from OGs, tag you and the community, but all you are doing is to downplay us, this is not what i know of a community.

[strahncryptography]

Never mind. I just do not like AI generated proposals and that is a shortcoming on my part, I apologise.