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

General
1

Zwap
Zwap2400Ă—952 32.3 KB

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
2

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.

IMG_8126
IMG_81261290Ă—1259 94.9 KB

IMG_8125
IMG_81251290Ă—918 68.7 KB

1 Like
3

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

4

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.

5

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.

1 Like
6

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.

7

The solver holds funds?

8

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.

9

Have audits been performed to verify claims?

10

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.

11

Hey there @Aditya,

I had problems opening the app and docs website. No response come from your side at all. Are you still up?
Also, are you planning to migrate your shielded transactions into Ironwood?

12

Is this project still active?

13

Even if it was, I had some concerns, namely:

Orchard-native: Every swap funds from and settles into the Orchard pool. Your ZEC never leaves the shielded set.

But the paper only mentions a canonical UTXO-based swap model. Orchard doesn’t have scriptSig, it is nowhere near Turing complete. Their whitepaper mentions OP_SHA256 and other opcodes, which don’t exist in Orchard…

2 Likes
14

Agreed, when I tried looking more into how this would work, that’s where the main bottleneck exists.

15

Exactly. I had the same problem and inconsistency between the whitepaper and what is presented here.
I want to know that if this is not alive, I might pursue to solve the exact same problem, probably with a different method. I had my research done, and I just stopped at the implementation phase.

1 Like
16

I don’t believe there IS a method. There are only a fixed number of circuits that the network itself approves, and any custom circuit will not be network-enforceable. Orchard/Ironwood is not Turing complete, or even barely flexible, this is because the circuits need to be identical on both sides.

1 Like
17

By method I meant an approach to solve it. I know Zcash is not Turing-complete in general. But there can be ways, for example a TEE with access (not saying this is my approach), that can solve the problem of Turing-completeness outside the chain.

18

I still fail to see how a TEE solves atomic swap. An atomic swap relies on the fact that both parties have an incentive to stay honest, as either of them sending a correct payment will reveal a crucial part of the unlock transaction for the other as a function of the payment itself, without any third party mediation. If there is a third party or a counterparty risk, its no longer atomic.

Bitcoin/Monero works because of some VERY clever math, and Bitcoin/Ethereum or tZEC/Ethereum works because Ethereum is Turing-complete and thus can emulate any architecture Bitcoin/tZEC may require.

But Orchard has NO primitives, in fact, the other party can’t even see the broadcasted transaction to know what crucial data is revealed!

It’s more game theory than cryptography.

1 Like
19

I get what you say.
If you are interested in this work, I would be happy to have a private conversation with you on that, and maybe we can brush it up and propose as an application or find it is not possible and leave it be.

20

Well, it is not possible. Other than the fact that I already researched it months prior, it’s common sense: Orchard relies on circuits, and the circuits rely on the fact that they are deterministic for both PK and VK. Meaning the circuit cannot be modified, and the circuit doesn’t allow for a malleable primitive because instead of using the key to validate the transaction, Orchard’s circuits essentialy prove that a key exists that could validate the transaction. Since no actual execution is occurring anywhere, only a proof of authenticity of sender (and primitives like a nullifier inclusion proof), you just can’t do an atomic swap.

1 Like