Zwap: Unlinkable Cross-Chain Atomic Swaps

Zcash Apps
1

Hi everyone,

We wanted to share a new cross-chain atomic swap construction called Zwap, and get feedback from the Zcash community. This work is motivated by a fairly fundamental limitation in how cross-chain swaps are implemented today, and why that limitation becomes especially problematic for privacy-preserving systems like Zcash.

The Problem with HTLC-Based Swaps

Most existing cross-chain swaps rely on hashed timelock contracts (HTLCs). While HTLCs give us the atomicity guarantee that either both sides of the swap execute or neither does, they introduce a deterministic linkage between chains.

The same hash preimage condition H(s) is embedded on both chains, and once the preimage is revealed on one chain, it becomes trivial for any observer to correlate the corresponding transaction on the other chain. In effect, HTLCs create a public bridge between two otherwise independent transaction graphs.

For ecosystems where transparency is already the default, this tradeoff is often accepted. But in the context of Zcash, where minimizing linkability and metadata leakage is a core design goal, this becomes a much more serious issue. Even if one leg of the swap is shielded or privacy-enhanced, the shared hash across chains can reintroduce correlation at the cross-chain level.

Zwap’s Core Idea (Zcash ↔ Ethereum Example)

Phase 0 (Off-Chain Order Matching):

  1. Alice generates secret s, computes PS = s · G and H(s)

  2. Alice proves (in zero-knowledge) that s is the preimage of both H(s) and the discrete log of PS

  3. Bob verifies the proof, generates b, sends PB = b · G

  4. Both compute shared point PSB = s · PB = b · PS

Phase 1 (Locking):

  1. Alice locks on Ethereum: funds redeemable by ECDSA signature under PSB (requires key s · b)

  2. Bob locks on Zcash: transparent UTXO with script requiring OP_SHA256 preimage of H(s)

Phase 2 (Redemption):

  1. Alice reveals s on Zcash, claims Bob’s BTC

  2. Bob reads s from Zcash blockchain, computes s · b, signs under PSB, claims Alice’s ETH

This works today with Zcash transparent addresses and the funding transaction could be an unsheilding transaction (z->t). For our future work we are actively exploring trustlessly swapping with shielded (z->z) transactions.

Compatibility and Practical Use

In terms of compatibility, the construction works directly with Zcash’s transparent layer, since it only requires standard UTXO scripting primitives : signature verification, hash preimage checks, and timelocks. This makes it immediately applicable to swaps like Zcash–Bitcoin or Zcash–EVM chains without requiring changes to consensus or signature schemes.

More generally, the protocol is chain-agnostic. It only assumes that one chain can enforce a signature-based lock and the other can enforce a hash-based lock. The exact encoding differs per chain, but the core construction remains the same.

As client-side proving performance continues to improve, the computational overhead of Phase 0 becomes negligible from a user experience perspective.

Implementation Status

We’re are on a road map to ship soon targeting:

  • Ethereum mainnet + L2s

  • Zcash transparent (standard P2SH scripts)

  • ZK proving stack (UltraHonk/Provekit for off-chain proofs)

The protocol is designed for a solver model (professional market makers) rather than peer-to-peer matching. Solvers provide liquidity, manage watchtowers, and handle cross-chain complexity. End users just lock → reveal → claim.

Relation to PTLCs

An important comparison for cross-chain atomic swap protocols is how ECDH-Swap relates to PTLC-based approaches.

When both chains support Schnorr signatures and adaptor signature primitives, PTLCs offer a cleaner and more cryptographically native path to unlinkable atomic swaps. In homogeneous environments with these capabilities, PTLCs are arguably the ideal construction.

ECDH-Swap is not intended to replace that direction. Instead, it addresses the practical gap in heterogeneous cross-chain environments where at least one chain lacks native Schnorr support , most notably EVM-based chains, which rely on Schnorr verification through ecrecover workarounds, which remains non-native and gas-inefficient compared to ECDSA operations.

Open Questions for the Community

  • How much does a trustless atomic bridge matter to a ZEC holder?
  • How much does statistical unlinkability matter vs. cryptographic unlinkability in practice?

Read the Full Paper

:page_facing_up: PDF: Zwap: A Cross-Chain Atomic Swap Protocol Using Multiplicative Key Aggregation

11 Likes
2

Amazing work!

2 Likes
3

Unlinkable atomic swaps fill a real gap. Cross-chain bridges leak metadata even when the source chain is shielded. If Zwap preserves unlinkability through the swap itself, the privacy wins compound at every layer.

1 Like
4

@joshs, would love to get ZODL’s perspective on this. Is trustless cross-chain swap integration something ZODL considers crucial? The protocol works today with transparent P2SH fundable from Orchard, and we’re actively working on native shielded support. Happy to collaborate on wallet-level integration!

5

Hey everyone! We’re planning to submit a ZCG grant application for Zwap and wanted to get early feedback from the community before going formal.

Zwap is a construction for trustless, unlinkable cross-chain atomic swaps between Zcash and EVM chains. We feel this would complement NEAR Intents nicely, users who want speed and convenience use NEAR Intents, users who want a fully trustless and unlinkable option use Zwap. There should always be a trustless choice for ZEC holders.

Two questions:

  • Is trustless, unlinkable cross-chain swap infrastructure something ZCG considers important and would consider funding for the Zcash ecosystem?
  • Would the community want to see this natively integrated into ZODL?

Full paper: zwap.atheon.xyz

Tagging a few people for visibility: @Artkor @GGuy @Hanh @Zerodartz @Decentralistdan @str4d

6

It’s funny I have proposed something like this before: Zwap - Atomic Cross-chain BTC/ZEC swaps (same name too!)
However, mine was shielded (using adaptor signatures). Anyway, there wasn’t much demand but now it could be different.

7

Hey @hanh, the name collision is genuinely a coincidence (simple but intuitive)! We weren’t aware of your earlier proposal until after publishing. Credit where it’s due.

That being said, the two constructions end up in quite different places. Fully shielded swaps are the ideal end state, but your proposed path there, adaptor signatures with DLEQ proofs across curves, had some open issues that surfaced in your thread: the DLog proof gap that @kayabaNerve flagged and the non-native field arithmetic cost of cross-curve DLEQ in Halo2. Those are hard problems, and as far as we can tell they remain open.

Our approach sidesteps them by working within what’s deployable today: transparent P2SH on the Zcash side (fundable from Orchard via z→t), ECDH multiplicative key aggregation instead of adaptor signatures, and a solver model rather than P2P. The tradeoff is that the swap UTXO is visible on the transparent chain, but all keys are ephemeral and the z→t funding doesn’t reveal the source shielded address, so no user identity is leaked. Entry and exit remain shielded. Even with the transparent tradeoff, we think a trustless z→t swap that exists today is more valuable to ZEC holders than a fully shielded one that doesn’t.

Native shielded support is on our roadmap, we have a concrete approach that avoids the cross-curve DLEQ problem entirely. Happy to share more on that as it matures.

8

They are resolved by not using Halo 2 but an arithmetic proof (The code provided by @kayabanerve) . The main problem was the lack of interest, even on XMR there was little liquidity.

9

Worth pointing out something about the construction here ( GitHub - MerosCrypto/asmr: Atomic Swaps for Meros and other cryptocurrencies · GitHub ) that I think matters for evaluating shielded swap proposals generally.In @kayabanerve’s construction , the ZEC holder can never independently refund their own ZEC. In every scenario happy path, refund, abort the ZEC holder depends on the BTC holder performing a specific on-chain action that reveals a key share through an adaptor signature. If the BTC holder simply goes offline, the ZEC holder can eventually claim the BTC through a timelock (so they’re not left with nothing), but their ZEC is locked at the joint shielded address permanently. There’s no script, no timeout, no mechanism in Sapling or Orchard that can force a return of shielded funds without both key shares.
The protocol is also more interactive than it might seem both parties need multiple rounds (DLEq proofs, refund signatures, encrypted adaptor signatures, swap secret). If the communication is delayed mid-protocol, the ZEC holder falls back into that same dependent refund situation.
zwap’s transparent approach avoids this entirely both parties can refund independently via timelocks regardless of what the other party does. The tradeoff is that the swap UTXO is visible on the transparent chain, while ASMR keeps everything inside the shielded pool. But assuming that an unshielding tx funds the address on ZEC the privacy guarantees are still in tact I believe and a construction where neither party ever depends on the other’s liveness or cooperation for refunds is a stronger foundation to build on.

1 Like
10

HTLCs don’t just “leak a bit”, they fundamentally reintroduce linkage at the cross-chain layer, which kind of undermines what Zcash is trying to achieve.

Zwap’s approach is interesting because it shifts the linkage from a deterministic shared hash to something that’s less trivially observable. Even if it’s not perfect cryptographic unlinkability yet, reducing cheap correlation already feels like a meaningful step forward.

One thing I’m curious about is UX under the solver model. If users don’t see the complexity, that’s great, but it also concentrates power and visibility in solvers. How do you see privacy guarantees holding up against well-capitalised solvers who can observe flow patterns over time?

Also, if/when this moves toward shielded (z→z), that’s where it becomes really compelling. Right now it feels like a strong bridge solution, but the real unlock is making the entire swap lifecycle privacy-preservingg, not just parts of it.

Really promising work.

1 Like
11

On the solver privacy question it’s a valid concern. The solver model concentrates observation capability, and flow pattern analysis over time is a real risk. We’re working on an SPV-based approach for EVM that avoids the cross-curve DLEq problem entirely by verifying proofs across chains without requiring the ZEC to leave the shielded pool. This also addresses solver net censorship by making it permissionless through a liquidity pool.

I’m also considering a hybrid construction that combines ASMR’s shielded joint-key model with Zwap’s ZK hash-commitment to close the refund asymmetry that exists in pure adaptor signature based shielded swaps. The idea is to bind the refund path to a parameter s the party on Bitcoin would be required to reveal s to claim the refund, and a ZK proof during setup would verify that H(s) corresponds to the key used for locking on ZEC. This way, even if the BTC funder goes offline, they can return at any point, extract s from the Bitcoin refund transaction the counter party used to refund after T1 + T2 blocks, and use it to reconstruct the spending key and claim their shielded ZEC.

Will push both out as they mature. The transparent path works today and gives symmetric safety guarantees, but fully shielded with symmetric refunds is the end goal.

12

On the interest front, agreed that was the case then, but the timing is different now. Cross-chain ZEC demand has grown significantly since the ZODL/NEAR Intents integration went live, and that validates the need for more infrastructure in this space. We think there’s room for both convenience-first and trustless-first options for ZEC holders.

13

Unfortunately, there have been incidents where users lost funds through cross-chain swaps because of various reasons and no way to recover without third-party support. With atomic swaps none of this is possible. Either the swap completes on both sides or both parties get their funds back. No intermediary, no support ticket, no ambiguity. Zodl should have a trustless swap option to prevent cases like this.

14

At least maybe put a warning message that something like this may happen when you use Near swaps. Users losing funds from doing absolutely nothing wrong (Zodl populates recipient address automatically on swaps) is not a “swiss bank in your wallet” experience. Even if automic swaps solves nothing beats a proper user experience

1 Like
15

Hey @Aditya - we’re scoping something similar but for a bitcoin sidechain that does shielded transactions. I’ll have my team read the paper and will provide some thoughts if relevant.

Will also DM to connect directly.

1 Like