ShieldedAtomicSwap

_{spec · config}

A shielded atomic swap: P2P cross-chain settlement with unlinkability. Standard HTLCs have a known privacy flaw — the same hash H appears on both chains, allowing an observer to link the two legs of the swap. Even on privacy chains like Zcash, the HTLC hash pattern leaks cross-chain linkage.

ShieldedAtomicSwap replaces the hash reveal with a ZK proof of preimage knowledge. Each leg uses a different commitment on-chain, but the ZK proof guarantees they correspond to the same secret. An observer sees two independent shielded transactions — unlinkable.

How it differs from ShieldedDEX

Use cases

ShieldedAtomicSwap is not an exchange — it's private settlement between two parties who already agreed on terms. It trades price discovery for trustless cross-chain execution without linkability.

Where ShieldedAtomicSwap wins:

• Cross-chain swaps without bridges — bridges are the #1 hack target in crypto. Atomic swaps eliminate the bridge entirely — no custodian, no multisig, no wrapped tokens. Each party locks on their own chain and claims with a ZK proof.
• OTC trades between known counterparties — two parties who already agreed on a price (e.g., institutional OTC, treasury-to-treasury). They don't need price discovery — they need private, trustless settlement.
• Privacy-preserving cross-chain migration — moving value from one chain to another without leaving a linkable trail. Standard HTLCs leak the link via the shared hash. Shielded swaps break that link.
• Small P2P trades — no minimum batch size, no liquidity pool needed, no fees beyond gas. Two people can swap any amount directly.

Where other mechanisms are better:

Protocol

sequenceDiagram
    participant A as Alice<br/>(has asset A on Chain 1)
    participant C1 as Chain 1
    participant C2 as Chain 2
    participant B as Bob<br/>(has asset B on Chain 2)
    participant O as Observer

    Note over A,B: AGREE (off-chain, P2P)
    A-->>B: negotiate terms

    Note over A,B: LOCK

    A->>C1: lock A with shielded commitment C1
    Note over O: sees: shielded_lock on Chain 1

    B->>C2: lock B with shielded commitment C2
    Note over O: sees: shielded_lock on Chain 2<br/>C1 ≠ C2 — CANNOT link them

    Note over A,B: CLAIM

    A->>C2: claim B with ZK proof (not hash reveal)
    Note over O: sees: shielded_claim on Chain 2<br/>no secret revealed on-chain

    B->>C1: claim A with ZK proof
    Note over O: sees: shielded_claim on Chain 1<br/>still cannot link to Chain 2

    Note over A,B: DONE — swap complete
    Note over O: saw 4 independent shielded txs<br/>cannot determine they are related

Standard HTLC vs Shielded

Zcash protocol changes needed

Verified properties (32 states)

Properties expected to fail

Add as INVARIANT to see counterexamples:

The liveness vs safety tradeoff

The BobCanLose counterexample reveals a fundamental tradeoff in atomic swaps:

• Safety (timeouts) requires liveness (both parties online)
• If Bob goes offline after Alice claims, Alice gets both assets
• This is not a bug — it's the structural cost of no coordinator
• ShieldedDEX doesn't have this problem (batch coordinator ensures both sides clear)

This is a new dimension in the impossibility space: P2P settlement requires mutual liveness.