Zwap: Trustless Shielded Atomic Swaps for Zcash (Early Access)

Zwap: Trustless Shielded Atomic Swaps for Zcash (Early Access)

Hey everyone,

Early this year, we spent time talking to ZEC holders about how they move assets in and out of Zcash. The same thing kept coming up: every option meant trusting some group of parties to hold keys and behave.
It comes down to one question: what are you being asked to trust?

Most designs answer it the same way:

  • A bridge validator set
  • An MPC committee
  • A custodian or some group of parties holds keys or signs on your behalf

Different designs, same shape underneath, a group holds keys or signs on your behalf, and the safety of your swap rests on enough of them staying honest and online. This works, and it’s how most ZEC cross-chain volume moves today. But it adds a trust assumption that the rest of your Zcash activity doesn’t carry.

Every cross-chain design ends up at the same fork. You can ask the user to trust someone, and the rest gets easy. Or you refuse to, and the engineering gets hard. Zcash exists because that fork matters.

So for the last few months we’ve been building the harder version. Zwap. Today we’re sharing it as an early access deployment, live at app.zwap.exchange.

When we set out to build Zwap, two things were non-negotiable, faster and cheaper aside:

  • Orchard-native: Every swap funds from and settles into the Orchard pool. Your ZEC never leaves the shielded set.
  • Fully Trustless: No validator set, no MPC committee, no custodian; just cryptography and the two chains’ consensus.

Watch how Zwap works end to end:

How it works

Zwap moves funds directly in and out of the Orchard shielded pool without trusting an intermediary. No MPC committee, no multisig, no custodian, no wrapped assets. The first deployment routes between Zcash and Ethereum / Base mainnet (ETH and USDC).

Under the hood it is an atomic swap, but not the HTLC kind. Each swap is composed of four pieces:

  1. A lock on Zcash. The Zcash leg is enforced by a script funded from and settling back into Orchard and the settlement is indistinguishable on-chain from any other shielded transfer.
  2. A lock on the counterparty chain. The EVM leg is enforced by the ZwapHtlc contract. Funds are locked into a slot keyed to the swap; release is gated by a witness only the counterparty can produce once the Zcash side has committed.
  3. A cross-curve key exchange. The two parties run a Diffie-Hellman-style exchange across Pallas (the curve Orchard uses for spend authorisation) and secp256k1 (the curve the EVM signer uses). A DLEQ proof certifies that the same discrete log underlies both curve points without revealing the log itself. The output of the exchange is a shared secret each side commits to in their respective lock. Completing one lock cryptographically forces the secret on the other chain, which unlocks the other side.
  4. A zero-knowledge proof that binds the two legs. A client-side hashbind circuit, proven with ProveKit, certifies that the on-chain commitment on the EVM side is consistent with the Orchard note the user is about to spend. The proof is generated locally by the ZEC-side initiator; the verifier checks it in milliseconds. This binding is what makes the swap atomic without requiring a shared hash preimage on both chains.

The construction is chain-agnostic. It works for any chain pair where each side can enforce the required lock type and is not limited to Zcash and EVM chains.

The full construction, security analysis, edge cases, and the formal proof of atomicity of the base protocol it is built on is in the whitepaper: zwap.atheon.xyz

What’s live today @ zwap

  • Trustless, shielded swaps between Zcash and Ethereum/Base (USDC, ETH)
  • Swap directly from Orchard

What’s in progress

We’re expanding on two fronts:

  1. Coverage: Bitcoin support, more chains, and additional pairs, including native shielded-to-shielded swaps.
  2. Privacy: private activity retrieval via PIR and a private relay, so even how you interact with Zwap stays shielded.

Zwap is built as general cross-chain infrastructure, not a single-pair bridge and we’ll be expanding steadily.

This is early

This is an early access release. A few things to know before you try it:

  • Swap size is capped. Minimum $1, maximum $100 per swap.
  • Pair coverage is limited. It will grow over time.
  • Expect rough edges. There may be bugs. If you hit one, please report it to @Aditya, @immabeyeet or mail us at hello@atheon.xyz (it genuinely helps!).

Acknowledgment

NEAR Intents has done real work bringing swap volume to ZEC, and we don’t want to take anything away from that. It relies on an MPC committee holding keys across chains. We think there should also be a fully trustless option for the ZEC holders who want one, even if it serves a different segment of users.

We’d love your feedback

If you have a few minutes, try a swap and tell us what breaks, what’s confusing, or what you’d want to see next. We’re especially interested in feedback from wallet teams, solvers, and anyone who has thought hard about Zcash’s cross-chain story.

Happy to take technical questions in the thread.

Taking the hard road, on purpose.
Atheon

7 Likes

On fees: running an MPC network has ongoing cost with a whole signing infrastructure that has to be sustained, and that gets recovered through the fees users pay. Zwap doesn’t carry that overhead, so there’s less cost to pass on in fees.

1 Like

Do peers need to be online at the same time to match ?

No a user can post an order and can go offline; matching engine is always-on and works async. But a user has to be online for a brief moment during settlement. We are also working on a sdk version that doesn’t require liveliness under same trustless assumptions.

Yeah, someone can put an open order and go away, but they need to be online when it gets matched and filled. Orders can be in the system, but aren’t tradable because whoever posted them isn’t there. That’s the issue with OTC swaps, and AtomicDEX faces the same challenge.

Not entirely true, a user can place and initiate the order and go offline. Zwap’s solver can complete the order if it agrees on the price within the trade window, the user doesn’t need to be online for the order completion and the solver would fulfill the order. Post the order completion, a user has a time period to sweep their funds and realize them, if they don’t, the order is reverted.

The solver holds funds?

No, user’s funds are locked in a script until the user claims solver’s funds which will give the solver enough cryptographic material to sweep the script. If the solver never funds, the user gets their assets back from the script.

Have audits been performed to verify claims?

Security review so far has been two internal rounds. An independent external audit is planned, and we won’t raise the swap caps until it’s done, the $1–$100 limits exist precisely to bound exposure in the meantime.

On verifying claims today: the formal proof of atomicity in the whitepaper covers the base protocol the system is built on, and the ZwapHtlc contract is deployed and inspectable on-chain. On the client side, the user’s half of the cross-curve exchange is generated and held locally, you can watch network requests and local storage during a swap to confirm it never leaves the browser.