From ae19e429515395b4abef9fb8bab5068c717751fc Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Mon, 15 Jun 2026 14:40:28 +1000 Subject: [PATCH] RFP-003: rescope atomic swaps to BTC/XMR/ZEC with appendices Extend RFP-003 from the BTC/XMR/ETH scope to Bitcoin, Monero, and Zcash transparent. Drop the Ethereum pair (ETH reaches LEZ via wrapping, which needs no swap counterparty) and add the Zcash transparent pool via BIP-199-style HTLCs, with shielded swaps out of scope. Allow either Bitcoin refund construction (pre-signed timelocked tx or Taproot script-path tapleaf). Set funding to $100k and note the LEZ-side primitives are present today. Add two ecosystem-survey appendices with sources: - btc-xmr-adaptor-swap-primitives.md - zcash-atomic-swap-primitives.md Co-Authored-By: Claude Opus 4.8 --- README.md | 2 +- RFPs/RFP-003-atomic-swaps.md | 260 +++++++++++--------- appendix/btc-xmr-adaptor-swap-primitives.md | 192 +++++++++++++++ appendix/zcash-atomic-swap-primitives.md | 223 +++++++++++++++++ 4 files changed, 566 insertions(+), 111 deletions(-) create mode 100644 appendix/btc-xmr-adaptor-swap-primitives.md create mode 100644 appendix/zcash-atomic-swap-primitives.md diff --git a/README.md b/README.md index 67ca894..56a8c92 100644 --- a/README.md +++ b/README.md @@ -78,7 +78,7 @@ Click an RFP to view details. Use the Submit Proposal button to apply. | ------- | ------------------------------------------------------------------------------------ | ---- | ------- | ------ | ---------------------------------- | ----------------------------------------------------------------------------------- | | RFP-001 | [Admin Authority Library](RFPs/RFP-001-admin-authority-lib.md) | XS | $XXXXX | open | Developer Tooling & Infrastructure | Closed | | RFP-002 | [Freeze Authority Library](RFPs/RFP-002-freeze-authority-lib.md) | XS | $XXXXX | open | Developer Tooling & Infrastructure | Closed | -| RFP-003 | [Atomic Swaps with LEZ](RFPs/RFP-003-atomic-swaps.md) | XL | $TBD | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-003 | [Atomic Swaps with LEZ](RFPs/RFP-003-atomic-swaps.md) | XL | $100k | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | | RFP-004 | [Privacy-Preserving DEX](RFPs/RFP-004-privacy-preserving-dex.md) | XL | $XXXXX | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | | RFP-008 | [Lending & Borrowing Protocol](RFPs/RFP-008-lending-borrowing-protocol.md) | XL | $XXXXX | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | | RFP-012 | [Curated Lending Vaults](RFPs/RFP-012-curated-lending-vaults.md) | L | $XXXXX | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | diff --git a/RFPs/RFP-003-atomic-swaps.md b/RFPs/RFP-003-atomic-swaps.md index b814e8d..62a79e6 100644 --- a/RFPs/RFP-003-atomic-swaps.md +++ b/RFPs/RFP-003-atomic-swaps.md @@ -2,7 +2,7 @@ id: RFP-003 title: Atomic Swaps with LEZ tier: XL -funding: $TBD +funding: $100k status: open category: Applications & Integrations dependencies: @@ -12,31 +12,42 @@ dependencies: # RFP-003 — Atomic Swaps with LEZ -> **Note:** This RFP is open for proposal submission. **LEZ timelock support** -> is now available: the LEZ clock program exposes on-chain block timestamps, and -> a program can gate release or refund on a deadline. +> **Status:** Open for proposal submission and ready to start. The LEZ-side +> primitives required for adaptor-signature-based swaps (BIP-340 Schnorr over +> secp256k1, block-height and timestamp validity windows, AND-multisig witness +> sets, SHA-256 in guest programs) are present in the +> [Logos Execution Zone](https://github.com/logos-blockchain/logos-execution-zone/) +> today. Applicants should verify the relevant signing, witness, and +> validity-window APIs against the current tip before submission. ## 🧭 Overview Build a unified atomic swap application that enables trustless, non-custodial -exchanges between LEZ and three major chains: **Bitcoin**, **Monero**, and -**Ethereum**. The LEZ side is implemented as a Risc0 guest program that locks -funds contingent on the appropriate cryptographic proof for each chain. A -reference implementation for ETH–LEZ swaps already exists -([eth-lez-atomic-swaps](https://github.com/logos-co/eth-lez-atomic-swaps)); this -RFP extends the work to Bitcoin and Monero, and delivers a complete, -production-ready swap application. +exchanges between LEZ and three external chains: **Bitcoin**, **Monero**, and +**Zcash** (transparent pool). The LEZ side is implemented as a Risc0 guest +program that locks funds contingent on the appropriate cryptographic proof for +each chain. An HTLC-based reference implementation for ETH and LEZ already +exists +([eth-lez-atomic-swaps](https://github.com/logos-co/eth-lez-atomic-swaps)) and +demonstrates the LEZ escrow structure; this RFP applies that foundation to +Bitcoin, Monero, and Zcash, and delivers a complete, production-ready swap +application. An Ethereum pair is out of scope: ETH is expected to reach LEZ via +wrapping, which requires no swap counterparty and is a much simpler +construction. Zcash shielded-pool (Sapling / Orchard) swaps are explicitly out +of scope: the cryptographic state of the art does not yet provide a drop-in +design (see +[Appendix: Zcash Atomic Swap Primitives](../appendix/zcash-atomic-swap-primitives.md)). The application uses a **maker/taker model**: the maker acts as a liquidity provider, advertising offers over **Logos Delivery** and coordinating swaps over -**Logos Chat** — no central infrastructure required. Teams with experience in -applied cryptography (adaptor signatures, DLEQ proofs), cross-chain protocol +**Logos Chat**, with no central infrastructure required. Teams with experience +in applied cryptography (adaptor signatures, DLEQ proofs), cross-chain protocol design, and Rust/Risc0 development are best positioned to succeed. ## 🔥 Why This Matters -Trustless swaps between LEZ and widely-held digital assets — without bridges, -custodians, or wrapped tokens — are a prerequisite for meaningful DeFi liquidity +Trustless swaps between LEZ and widely-held digital assets, without bridges, +custodians, or wrapped tokens, are a prerequisite for meaningful DeFi liquidity in the Logos ecosystem. Without this primitive, users cannot move value in or out of LEZ without trusting an intermediary, which directly conflicts with the ecosystem's trust-minimisation principles. @@ -45,16 +56,20 @@ Each target chain presents distinct cryptographic challenges that make this non-trivial. Bitcoin HTLCs are identifiable on-chain and link the two swap legs; adaptor signatures with Taproot key-path spends solve this, making swaps indistinguishable from normal payments. Monero has no scripting system at all, -requiring cross-curve DLEQ proofs to achieve atomicity. Ethereum provides the -most flexibility and an existing reference, but the implementation must -integrate with the Logos Ethereum module and meet the same trustlessness -guarantees as the other chains. - -Delivering this application — with its fully decentralised coordination via -Logos Delivery and Logos Chat — demonstrates that the Logos stack can support -real-world, multi-chain financial applications without any centralised -infrastructure. This is a forcing function for the maturity of those modules and -a high-visibility proof point for ecosystem adoption. +requiring cross-curve DLEQ proofs to achieve atomicity. Zcash transparent +inherits Bitcoin script unchanged and supports HTLC-based swaps via +[BIP-199](https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki); +adaptor-signature variants are a stretch goal for cross-chain unlinkability. The +Bitcoin and Monero constructions are surveyed with sources in +[Appendix: Bitcoin and Monero Adaptor-Signature Swap Primitives](../appendix/btc-xmr-adaptor-swap-primitives.md); +the Zcash analysis is in +[Appendix: Zcash Atomic Swap Primitives](../appendix/zcash-atomic-swap-primitives.md). + +Delivering this application, with its fully decentralised coordination via Logos +Delivery and Logos Chat, shows that the Logos stack can support multi-chain +financial applications without any centralised infrastructure. It exercises +those modules under a real workload and gives the ecosystem a concrete swap +application to build on. ## ✅ Scope of Work @@ -62,48 +77,60 @@ a high-visibility proof point for ecosystem adoption. #### Functionality -01. The application must not depend on any centralised server or service. All - maker advertisement and maker-taker coordination uses Logos Delivery and - Logos Chat respectively. -02. Trustless swaps between LEZ and **Bitcoin** are supported using Schnorr - adaptor signatures (BIP-340) and Taproot key-path spends (BIP-341). No - custom Bitcoin scripts are used; swap transactions are indistinguishable - from normal Taproot payments. -03. Trustless swaps between LEZ and **Monero** are supported using Ed25519 - adaptor signatures with cross-curve Discrete Log Equality (DLEQ) proofs (the - h4sh3d/COMIT protocol). Atomicity is achieved by transferring a Monero spend - key share, without on-chain scripting. -04. Trustless swaps between LEZ and **Ethereum** are supported using HTLCs or - adaptor signatures. Ethereum interactions must use the **Logos Ethereum - module**. -05. The LEZ escrow program (Rust, Risc0) locks funds contingent on the - appropriate cryptographic proof for each chain (adaptor secret, DLEQ proof, - or hash preimage) and releases them upon valid proof submission. Funds are - refunded to the depositor after the timelock expires. -06. The two legs of each swap are atomic: either both complete or both refund. - No state exists where one party receives funds and the other does not. -07. Swaps on LEZ support both the native LEZ token and custom tokens issued via - the LEZ token program, using Associated Token Accounts (ATAs). -08. Swaps on Ethereum must support both **native ETH** and **ERC-20 tokens**. - Both asset types must be fully supported in the Ethereum escrow contract — - partial support (e.g., ETH only) is not acceptable. -09. The maker software supports two pricing modes: (1) **local configuration** — - static prices set via config file or CLI, suitable for testing; (2) - **external price feed** — prices fetched from an external source (e.g., a - REST API). The architecture must support pluggable price sources; the - specific external integration is left to the developer. -10. The maker is deployable as a **headless daemon** covering pair and price - configuration, external price feed integration, liquidity advertisement, - swap execution, and monitoring — the daemon must be fully operable via the - maker CLI without a GUI. +1. The application must not depend on any centralised server or service. All + maker advertisement and maker-taker coordination uses Logos Delivery and + Logos Chat respectively. +2. Trustless swaps between LEZ and **Bitcoin** are supported using Schnorr + adaptor signatures (BIP-340) and Taproot (BIP-341). The cooperative claim + path must be a key-path spend, indistinguishable from a normal Taproot + payment. The **refund branch** may be implemented either as a pre-signed + timelocked transaction (key-path, refund also indistinguishable) or as a + Taproot script-path tapleaf (`OP_CHECKSEQUENCEVERIFY`, refund spend + identifiable but enforced by consensus); both are acceptable. The two + constructions and their trade-offs are described in + [Appendix: Bitcoin and Monero Adaptor-Signature Swap Primitives](../appendix/btc-xmr-adaptor-swap-primitives.md). + Absent a measured reason to prefer otherwise (see Reliability), the simpler + script-path refund is the recommended default. +3. Trustless swaps between LEZ and **Monero** are supported using Ed25519 + adaptor signatures with cross-curve Discrete Log Equality (DLEQ) proofs (the + h4sh3d/COMIT protocol). Atomicity is achieved by transferring a Monero spend + key share, without on-chain scripting. +4. Trustless swaps between LEZ and **Zcash transparent (`t1...`) addresses** are + supported using BIP-199-style HTLCs + (`OP_IF / OP_SHA256 / OP_CLTV / OP_CHECKSIG` on the Zcash side, mirrored on + the LEZ side). The Zcash refund deadline must strictly succeed the LEZ refund + deadline by a margin documented to cover worst-case Zcash confirmation + latency. ECDSA adaptor signatures (Lloyd Fournier construction) are an + acceptable alternative to HTLCs and are encouraged for cross-chain + unlinkability. Zcash shielded-pool (Sapling / Orchard) swaps are **out of + scope** for this RFP; see + [Appendix: Zcash Atomic Swap Primitives](../appendix/zcash-atomic-swap-primitives.md) + for the rationale. +5. The LEZ escrow program (Rust, Risc0) locks funds contingent on the + appropriate cryptographic proof for each chain (adaptor secret, DLEQ proof, + or hash preimage) and releases them upon valid proof submission. Funds are + refunded to the depositor after the timelock expires. +6. The two legs of each swap are atomic: either both complete or both refund. No + state exists where one party receives funds and the other does not. +7. Swaps on LEZ support both the native LEZ token and custom tokens issued via + the LEZ token program, using Associated Token Accounts (ATAs). +8. The maker software supports two pricing modes: (1) **local configuration**: + static prices set via config file or CLI, suitable for testing; (2) + **external price feed**: prices fetched from an external source (e.g., a REST + API). The architecture must support pluggable price sources; the specific + external integration is left to the developer. +9. The maker is deployable as a **headless daemon** covering pair and price + configuration, external price feed integration, liquidity advertisement, swap + execution, and monitoring; the daemon must be fully operable via the maker + CLI without a GUI. #### Usability -01. Provide a dedicated SDK per trading pair (LEZ–BTC, LEZ–XMR, LEZ–ETH) that +01. Provide a dedicated SDK per trading pair (LEZ–BTC, LEZ–XMR, LEZ–ZEC) that can be used to build Logos modules for interacting with that pair's swap protocol. Each SDK must expose the full swap lifecycle (offer discovery, negotiation, escrow creation, claim, and refund) for its respective chain. -02. Provide a **maker daemon** — a long-running headless process that manages +02. Provide a **maker daemon**: a long-running headless process that manages liquidity advertisement, price feeds, incoming swap requests, and swap execution without human interaction. A systemd unit file must be provided for running the daemon as a system service, including documented @@ -133,17 +160,16 @@ a high-visibility proof point for ecosystem adoption. (`monerod`) on stagenet, including wallet RPC configuration (`monero-wallet-rpc`) and obtaining stagenet funds. Documentation must cover both self-hosted and public stagenet node options. -10. Provide step-by-step documentation for configuring an **Ethereum Web3 RPC - provider** for Sepolia testnet. All Ethereum interactions in the application - must use the existing Logos Ethereum module; the documentation must explain - how to point the module at a chosen RPC endpoint (self-hosted or third-party - provider). +10. Provide step-by-step documentation for setting up a **Zcash node** (`zcashd` + or `zebrad`) on testnet, including transparent wallet creation and obtaining + testnet funds. Documentation must cover both self-hosted and public testnet + node options. #### Reliability 1. **Taker-first on-chain ordering**: The taker must perform their on-chain action before the maker performs theirs. The protocol must enforce this - ordering — the maker must not lock funds on their side until the taker's + ordering: the maker must not lock funds on their side until the taker's on-chain transaction is confirmed. This ensures the maker is never exposed to loss from a non-responsive taker. 2. **On-chain-only execution after lock**: Once the first on-chain action of a @@ -154,7 +180,7 @@ a high-visibility proof point for ecosystem adoption. reclaim funds via timelock) using only their local state and the relevant chain nodes. 3. **Graceful degradation**: If a chain-specific dependency is unavailable - (e.g., no Monero node configured, no Ethereum RPC reachable), the application + (e.g., no Monero node configured, no Zcash node reachable), the application must still start and enable swaps for the remaining chains. Unavailable chains are clearly reported to the user. 4. **Swap state persistence**: The swap coordinator must persist swap state @@ -167,7 +193,17 @@ a high-visibility proof point for ecosystem adoption. 6. Timelock parameters must account for block time variance, network congestion, and clock drift on each chain. The implementation must document timelock parameter choices and the rationale. -7. When Logos Delivery or Logos Chat is temporarily unreachable, the application +7. **Bitcoin refund construction must be justified.** The write-up must state + which refund branch construction was chosen for the Bitcoin pair (pre-signed + timelocked key-path transaction, or Taproot script-path tapleaf) and justify + it against the trade-off in the appendix. If the pre-signed approach is + chosen for its refund-path privacy, the submission must enumerate the + additional failure modes it introduces (lost or corrupted refund transaction, + malformed timelock, refund-tx fee rate fixed at setup becoming + unbroadcastable, dependence on timelock ordering rather than consensus) and + describe how each is mitigated, so the privacy benefit can be weighed against + the measured increase in fragility. +8. When Logos Delivery or Logos Chat is temporarily unreachable, the application must handle this gracefully (e.g., retry, buffering, degraded mode) and document the expected behaviour. @@ -195,13 +231,13 @@ a high-visibility proof point for ecosystem adoption. 07. The write-up covers: protocol design for each chain, LEZ escrow design, cross-chain atomicity argument, timelock handling, security assumptions, and known limitations. -08. Each per-pair SDK (LEZ–BTC, LEZ–XMR, LEZ–ETH) must include full API +08. Each per-pair SDK (LEZ–BTC, LEZ–XMR, LEZ–ZEC) must include full API documentation: all public types, functions, and error types, with usage examples covering the complete swap lifecycle (offer discovery, negotiation, escrow creation, claim, and refund). 09. Submit a [doc packet](https://github.com/logos-co/logos-docs/issues/new?template=doc-packet.yml) - for each per-pair SDK (LEZ–BTC, LEZ–XMR, LEZ–ETH), covering the developer + for each per-pair SDK (LEZ–BTC, LEZ–XMR, LEZ–ZEC), covering the developer integration journey for that swap protocol. 10. Submit a [doc packet](https://github.com/logos-co/logos-docs/issues/new?template=doc-packet.yml) @@ -212,7 +248,7 @@ a high-visibility proof point for ecosystem adoption. #### + (Demos) -1. For **each supported chain** (Bitcoin, Monero, Ethereum), three recorded demo +1. For **each supported chain** (Bitcoin, Monero, Zcash), three recorded demo videos must be submitted: - **Happy path**: both parties complete the swap successfully end-to-end. - **Refund/timeout path**: one party abandons the protocol and the other @@ -222,34 +258,9 @@ a high-visibility proof point for ecosystem adoption. ### Soft Requirements -- Support for the **Logos Ethereum module** could be extended to additional - EVM-compatible chains in a single submission. - -## ⚠ Platform Dependencies - -### Resolved dependencies - -These were once blockers but are now delivered on LEZ, so they no longer gate -this RFP. They remain in the frontmatter `dependencies` index with - -#### LEZ timelock support - -Refunds after timelock expiry (F5) require a program-readable time source. The -LEZ clock program now maintains on-chain timestamp accounts, and a program can -gate release or refund on a deadline, so this is **delivered**. - -### Soft blockers - -Desirable but the RFP can open without them. - -#### Use Basecamp to manage remote node - -Swaps require counterpart chain infrastructure (a Bitcoin Core node, a Monero -node, an Ethereum RPC) and a long-running maker daemon. The R&D item -[Use Basecamp to manage remote node](https://github.com/logos-co/journeys.logos.co/issues/62) -would let users manage such remote nodes from Basecamp, improving the operator -journey for the maker daemon and node setup (U8, U9). The RFP can be delivered -without it using the documented CLI and self-hosted node setup. +- An **adaptor-signature variant of the LEZ–ZEC pair** (replacing BIP-199 HTLCs) + for cross-chain unlinkability, as described in + [Appendix: Zcash Atomic Swap Primitives](../appendix/zcash-atomic-swap-primitives.md). ## 👤 Recommended Team Profile @@ -259,7 +270,8 @@ without it using the documented CLI and self-hosted node setup. - Rust development and the Risc0 zkVM toolchain - Bitcoin: Taproot/P2TR transaction construction, BIP-340/BIP-341 - Monero: key structure (spend/view keys), transaction construction, stagenet -- Ethereum: Solidity smart contracts, Foundry or Hardhat, ERC-20 interactions +- Zcash: transparent transaction construction, BIP-199 HTLCs, `zcashd`/`zebrad` + testnet - Distributed systems: swap state machines, crash recovery, concurrent coordination @@ -275,33 +287,61 @@ All code must be released under the **MIT+Apache2.0 dual License**. ### General -- [eth-lez-atomic-swaps](https://github.com/logos-co/eth-lez-atomic-swaps) — - ETH–LEZ HTLC-based swap (reference implementation and LEZ program structure) +- [eth-lez-atomic-swaps](https://github.com/logos-co/eth-lez-atomic-swaps): + ETH–LEZ HTLC-based swap (prior art for the LEZ program structure; an ETH pair + is itself out of scope) - [Logos Execution Zone](https://github.com/logos-blockchain/logos-execution-zone/) - [Risc0 proving system](https://dev.risczero.com/) ### Bitcoin +- [Appendix: Bitcoin and Monero Adaptor-Signature Swap Primitives](../appendix/btc-xmr-adaptor-swap-primitives.md): + sourced survey of the constructions required by this RFP - [BIP-340: Schnorr signatures for secp256k1](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) - [BIP-341: Taproot](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) -- [Adaptor signatures — Lloyd Fournier](https://github.com/LLFourn/one-time-vrf/blob/master/main.pdf) +- [DLC specs, Adaptor Signatures](https://github.com/discreetlogcontracts/dlcspecs/blob/master/AdaptorSignature.md): + production-grade spec for both Schnorr and ECDSA adaptor signatures with test + vectors +- [Aumayr et al. (2021), *Generalized Channels from Limited Blockchain Scripts and Adaptor Signatures*](https://eprint.iacr.org/2020/476): + formal security definitions (aEUF-CMA, witness-extractability, pre-signature + adaptability) +- [Adaptor signatures, Lloyd Fournier](https://github.com/LLFourn/one-time-VES): + reference ECDSA adaptor construction with DLEQ proof - [Scriptless Scripts — Andrew Poelstra](https://github.com/apoelstra/scriptless-scripts) - [rust-bitcoin](https://github.com/rust-bitcoin/rust-bitcoin) - [secp256k1-zkp (adaptor signature support)](https://github.com/BlockstreamResearch/secp256k1-zkp) +- [secp256kfun / ecdsa-fun](https://github.com/LLFourn/secp256kfun): Rust + libraries with clean reference implementations of Schnorr and ECDSA adaptor + signatures ### Monero +- [Appendix: Bitcoin and Monero Adaptor-Signature Swap Primitives](../appendix/btc-xmr-adaptor-swap-primitives.md): + sourced survey of the constructions required by this RFP - [Bitcoin–Monero Cross-chain Atomic Swap — h4sh3d paper](https://eprint.iacr.org/2020/1126.pdf) -- [comit-network/xmr-btc-swap](https://github.com/comit-network/xmr-btc-swap) — +- [comit-network/xmr-btc-swap](https://github.com/comit-network/xmr-btc-swap): production Monero-Bitcoin implementation -- [comit-network/cross-curve-dleq](https://github.com/comit-network/cross-curve-dleq) - — cross-group DLEQ proof library (secp256k1 ↔ Ed25519) +- [comit-network/cross-curve-dleq](https://github.com/comit-network/cross-curve-dleq): + cross-group DLEQ proof library (secp256k1 ↔ Ed25519) - [curve25519-dalek](https://github.com/dalek-cryptography/curve25519-dalek) - [secp256kFUN!](https://github.com/LLFourn/secp256kfun) -### Ethereum - -- Logos Ethereum module — use for all Ethereum interactions +### Zcash + +- [Appendix: Zcash Atomic Swap Primitives](../appendix/zcash-atomic-swap-primitives.md): + feasibility matrix, why shielded is out of scope, prior-art comparison +- [BIP-199: Hashed Time-Locked Contract transactions](https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki): + canonical HTLC layout used for transparent ZEC swaps +- [ZIP-203: Transaction Expiry](https://zips.z.cash/zip-0203): `nExpiryHeight` + semantics +- [ZIP-202: Version 3 Transaction Format for Overwinter](https://zips.z.cash/zip-0202) +- [`zcash/zcash` (`zcashd`)](https://github.com/zcash/zcash) and + [`ZcashFoundation/zebra` (`zebrad`)](https://github.com/ZcashFoundation/zebra): + full nodes +- [`librustzcash`](https://github.com/zcash/librustzcash): Rust + transaction-construction crates +- [Zwap forum thread](https://forum.zcashcommunity.com/t/zwap-unlinkable-cross-chain-atomic-swaps/55104): + most active 2025 prior-art for transparent ZEC atomic swaps ## ✏️ How to Apply diff --git a/appendix/btc-xmr-adaptor-swap-primitives.md b/appendix/btc-xmr-adaptor-swap-primitives.md new file mode 100644 index 0000000..563ed52 --- /dev/null +++ b/appendix/btc-xmr-adaptor-swap-primitives.md @@ -0,0 +1,192 @@ +# Bitcoin and Monero Adaptor-Signature Swap Primitives + +What an adaptor-signature atomic swap is, why RFP-003 mandates adaptor +signatures rather than HTLCs for the Bitcoin pair, why Monero permits no other +construction, and the prior art each claim rests on. + +## Adaptor signatures in one page + +An adaptor signature (also called a pre-signature or verifiably encrypted +signature) is a signature that is deliberately incomplete: it verifies against a +message and public key only once a secret scalar `t` (the adaptor witness, with +public point `T = t·G`) is folded in. + +The swap-relevant properties, formalised by +[Aumayr et al.](https://eprint.iacr.org/2020/476) as pre-signature adaptability, +witness extractability, and aEUF-CMA security: + +1. **Adaptability**: anyone holding the pre-signature `(R, s')` and the witness + `t` can complete it to a valid signature `s = s' + t`. +2. **Extractability**: anyone holding the pre-signature who later sees the + completed signature on-chain can recover the witness as `t = s − s'`. + +Property 2 is what makes the swap atomic: claiming funds on one chain requires +publishing `s`, and publishing `s` unavoidably reveals `t` to the counterparty, +who uses it to claim (or co-sign) on the other chain. The hash preimage of an +HTLC is replaced by an off-chain scalar reveal, so no swap-identifying data +appears in any script. The construction originates in Andrew Poelstra's +[Scriptless Scripts](https://github.com/apoelstra/scriptless-scripts) work; a +production-grade ECDSA adaptor specification with test vectors exists in the +[DLC specs](https://github.com/discreetlogcontracts/dlcspecs/blob/master/ECDSA-adaptor.md). +For chains that only verify ECDSA, Lloyd Fournier's +[one-time verifiably encrypted signatures](https://github.com/LLFourn/one-time-VES) +construction provides the ECDSA variant, carrying a DLEQ proof that the +encryption is well-formed. + +## Bitcoin: why not HTLCs + +Two distinct claims in RFP-003 need support here. + +**HTLCs link the two swap legs.** A BIP-199 style HTLC gates spending on +revealing a preimage whose hash is embedded in the script. Both chains embed the +same hash, and the claim transactions on both chains reveal the same preimage, +so any observer can pair the two legs across chains and identify the +transactions as a swap. This linkability is the stated motivation of the +scriptless-scripts programme and of the +[h4sh3d Bitcoin-Monero swap paper](https://eprint.iacr.org/2020/1126.pdf), which +both replace the preimage with an adaptor witness precisely to remove the +cross-chain identifier. + +**Taproot key-path spends are indistinguishable from ordinary payments.** Under +[BIP-341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki), a +key-path spend publishes only a single BIP-340 Schnorr signature; no script is +revealed at all. A 2-of-2 swap escrow becomes an aggregated key (for example via +[MuSig2, BIP-327](https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki)) +whose key-path spend looks identical to any single-signer Taproot payment. This +indistinguishability applies to the **cooperative (claim) path**: both parties +co-sign the key-path spend and nothing about the swap is revealed on-chain. + +### Two ways to build the refund branch + +[Taproot (BIP-341)](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) +gives a single output two independent spending conditions: a key-path spend +against the output key, and a script-path spend that reveals one leaf of a +committed script tree (BIP-341, "Script validation rules"). The refund branch +can be built with either. The cooperative claim path is the key-path spend in +both cases; the choice is only about how a party reclaims funds when the +counterparty stops responding. + +**Option A: pre-signed timelocked refund (key-path).** At setup, the parties +co-sign a refund transaction carrying an absolute +([`nLockTime` / BIP-65 `OP_CHECKLOCKTIMEVERIFY`](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki)) +or relative +([`nSequence` / BIP-68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki)) +timelock and hold it off-chain, broadcasting it only if the swap stalls. The +refund spend is itself an ordinary key-path spend, so it is indistinguishable +from any other payment. This is the technique used by Lightning, whose +commitment and HTLC outputs are spent by transactions pre-signed during channel +operation rather than by revealing on-chain script branches +([BOLT 3, "Commitment Transaction"](https://github.com/lightning/bolts/blob/master/03-transactions.md)), +and by the swap protocols cited below. The cost is moved off-chain: the refund +is enforced not by consensus but by each party correctly constructing and +*retaining* the pre-signed transaction, and by the cross-chain timelock ordering +(see "Timelock ordering" below) holding. + +**Option B: script-path refund (tapleaf).** A timelocked refund clause (for +example ` OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKSIG`, +using the relative timelock opcode from +[BIP-112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki)) is +committed as a leaf in the Taproot tree. The refunder spends that leaf after the +delay, with no pre-agreed transaction to construct or store. The refund is +enforced directly by Bitcoin consensus. The cost is on-chain: a script-path +spend must reveal the leaf script and a control block proving its inclusion in +the tree +([BIP-341, "Script validation rules"](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)), +so the refund spend is publicly identifiable as the refund branch of a swap +escrow. The cooperative path is unaffected and stays indistinguishable. + +The trade-off is **privacy-on-refund vs. fragility / state burden**: + +| | Pre-signed (A) | Script-path (B) | +| ------------------------- | -------------------------------------------------------------------------------------------------------- | ---------------------------------------------- | +| Refund spend on-chain | Indistinguishable key-path spend | Reveals tapleaf; identifiable as a swap refund | +| Refund enforcement | Off-chain: holds only if the pre-signed tx was built correctly and retained, and timelock ordering holds | On-chain: enforced by consensus | +| Failure modes added | Lost/corrupted refund tx, malformed timelock, fee-rate set at setup time may be unbroadcastable later | None beyond standard CSV semantics | +| Implementation complexity | Higher: refund-tx lifecycle, persistence, fee management | Lower: one extra tapleaf, standard CSV | + +A privacy leak on the refund branch is occasional by nature (a refund only +happens when a swap fails), whereas the fragility of Option A is borne on every +swap. Which side that balance favours is an engineering question worth measuring +rather than assuming; RFP-003 asks applicants to do so. + +## Monero: no scripting, key-share transfer + +Monero has no script system: outputs are spendable solely by producing a ring +signature with the output's spend key. There is no opcode for hashes, timelocks, +or branches, so neither HTLCs nor on-chain multisig escrows in the Bitcoin sense +are expressible. The [h4sh3d protocol](https://eprint.iacr.org/2020/1126.pdf) +(independently developed and shipped by COMIT) achieves atomicity anyway: + +1. The swap funds are sent to a Monero address whose spend key is the sum of two + shares, one held by each party. +2. The Bitcoin side is locked under an adaptor signature whose witness *is* the + counterparty's Monero key share. +3. Claiming the Bitcoin leg publishes the completed signature, which leaks the + witness (extractability, above), handing the counterparty the full Monero + spend key. + +Because the two key shares live on different curves (secp256k1 on the Bitcoin +side, Ed25519 on the Monero side), the protocol requires a **cross-curve DLEQ +proof** that the same scalar underlies both public points. COMIT published a +dedicated library for this: +[cross-curve-dleq](https://github.com/comit-network/cross-curve-dleq). Refunds +on the Monero side are likewise handled by pre-agreed transactions and timelock +asymmetry, since Monero cannot express a refund branch on-chain. + +## Timelock ordering across chains + +All of the cited protocols share the same refund-safety argument: the refund +deadline on the counterparty chain must strictly succeed the refund deadline on +the home chain, with a margin covering worst-case confirmation latency, so that +one party can never claim on one chain after the other party has already +refunded on the other. RFP-003 carries this requirement for every pair (see the +Zcash functional requirement and LEZ open question 2). The argument and +parameter discussion appear in section 4 of the +[h4sh3d paper](https://eprint.iacr.org/2020/1126.pdf). + +## Production status + +| Project | Pairs | Construction | Status | +| --------------------------------------------------------------------------- | ------------------------------- | ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | +| [comit-network/xmr-btc-swap](https://github.com/comit-network/xmr-btc-swap) | BTC ↔ XMR | Schnorr adaptor + cross-curve DLEQ, key-share transfer | Production; mainnet swaps since 2021, GUI via [UnstoppableSwap](https://unstoppableswap.net/) | +| [Farcaster](https://github.com/farcaster-project) | BTC ↔ XMR | Same family, Monero CCS-funded reimplementation | Alpha / development | +| [BasicSwap (Particl)](https://github.com/basicswap/basicswap) | BTC, XMR, and other UTXO chains | Adaptor-signature protocol for the XMR pairs | Live DEX | +| Lightning Network | BTC | Pre-signed timelocked refund transactions (the off-chain refund technique referenced above) | Production since 2018 | + +## Relevance to RFP-003 + +RFP-003 requires the Bitcoin pair to use BIP-340 adaptor signatures with Taproot +key-path spends (no custom scripts), and the Monero pair to use the h4sh3d/COMIT +key-share construction with cross-curve DLEQ proofs. Both constructions are +published, formally analysed, and have shipped in production software listed +above; the engineering risk for those pairs is integration work, not novel +cryptography. The Zcash transparent pair is analysed separately in +[Appendix: Zcash Atomic Swap Primitives](zcash-atomic-swap-primitives.md). + +## References + +- [Aumayr, Ersoy, Erwig, Faust, Hostáková, Maffei, Moreno-Sánchez, Riahi, *Generalized Channels from Limited Blockchain Scripts and Adaptor Signatures*](https://eprint.iacr.org/2020/476): + formal adaptor-signature security definitions +- [h4sh3d, *Bitcoin-Monero Cross-chain Atomic Swap*](https://eprint.iacr.org/2020/1126.pdf): + the BTC ↔ XMR protocol mandated for the Monero pair +- [Andrew Poelstra, Scriptless Scripts](https://github.com/apoelstra/scriptless-scripts): + origin of the adaptor-signature swap idea +- [DLC specs, ECDSA Adaptor Signatures](https://github.com/discreetlogcontracts/dlcspecs/blob/master/ECDSA-adaptor.md): + ECDSA adaptor spec with test vectors +- [Lloyd Fournier, one-time VES](https://github.com/LLFourn/one-time-VES): ECDSA + adaptor construction with DLEQ proof +- [BIP-340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki), + [BIP-341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki), + [BIP-327 (MuSig2)](https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki) +- [BIP-199: Hashed Time-Locked Contract transactions](https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki): + the HTLC baseline being avoided on the Bitcoin pair +- [BIP-65 (`OP_CHECKLOCKTIMEVERIFY`)](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki), + [BIP-68 (relative lock-time via `nSequence`)](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki), + [BIP-112 (`OP_CHECKSEQUENCEVERIFY`)](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki): + the timelock primitives behind both refund constructions +- [BOLT 3: Bitcoin Transaction and Script Formats](https://github.com/lightning/bolts/blob/master/03-transactions.md): + Lightning's pre-signed commitment/HTLC transactions, prior art for the + pre-signed refund construction +- [comit-network/xmr-btc-swap](https://github.com/comit-network/xmr-btc-swap) + and + [comit-network/cross-curve-dleq](https://github.com/comit-network/cross-curve-dleq) diff --git a/appendix/zcash-atomic-swap-primitives.md b/appendix/zcash-atomic-swap-primitives.md new file mode 100644 index 0000000..8e9d026 --- /dev/null +++ b/appendix/zcash-atomic-swap-primitives.md @@ -0,0 +1,223 @@ +# Zcash Atomic Swap Primitives + +What's needed for a non-custodial atomic swap between LEZ and Zcash, what Zcash +exposes today, and why the answer differs sharply between Zcash's transparent +and shielded pools. + +## Two pools, two answers + +Zcash has three on-chain pools. Their swap-relevant capabilities differ: + +| Pool | Address prefix | Scripting | Spend authorization | Curve | +| ----------- | ----------------- | ---------------------------- | ------------------------------- | --------- | +| Transparent | `t1...` | Bitcoin script (full subset) | secp256k1 ECDSA | secp256k1 | +| Sapling | `zs1...` | None | RedJubjub (Schnorr-like RedDSA) | Jubjub | +| Orchard | `u1...` / `o1...` | None | RedPallas (Schnorr-like RedDSA) | Pallas | + +The transparent pool is a near-clone of Bitcoin and supports HTLC-based atomic +swaps today via +[BIP-199](https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki). The +shielded pools (Sapling, Orchard) have no on-chain scripting at all, and as of +May 2026 there is no production-ready atomic swap to or from either of them. + +## Transparent pool: implementable today + +Zcash transparent inputs, outputs, and scripts behave as in Bitcoin. The opcodes +relevant to swaps (`OP_IF / OP_ELSE / OP_ENDIF`, `OP_SHA256`, `OP_HASH160`, +`OP_CHECKLOCKTIMEVERIFY`, `OP_CHECKSEQUENCEVERIFY`, `OP_CHECKSIG`, P2SH) all +work. The canonical HTLC layout from BIP-199 applies verbatim: + +``` +OP_IF + [HASHOP] OP_EQUALVERIFY OP_DUP OP_HASH160 +OP_ELSE + [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 +OP_ENDIF +OP_EQUALVERIFY +OP_CHECKSIG +``` + +### No Taproot on Zcash transparent + +The transparent pool tracks Bitcoin's script system as of a point that predates +SegWit, and Zcash has not adopted SegWit: the +[ZIP-48 multisig specification](https://zips.z.cash/zip-0048) states that the +SegWit `script_type` values (Native SegWit / P2WSH and Nested SegWit / +P2SH-P2WSH) "MUST NOT be used in a Zcash context." Because Taproot +([BIP-341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)) is +defined as SegWit version 1, it is **not available on Zcash transparent** +either. The transparent layer supports only P2PKH and P2SH outputs, signed with +**ECDSA** (not BIP-340 Schnorr). + +Two consequences for this RFP: + +- The key-path-indistinguishability approach used for the Bitcoin pair (a + Taproot 2-of-2 whose cooperative spend reveals no script) is not expressible + on Zcash transparent. The swap branch must live in an explicit P2SH script, + which is why the HTLC route reveals a hash preimage on-chain and is publicly + linkable. +- Unlinkability on the Zcash side therefore comes not from Taproot but from an + **ECDSA adaptor signature** (the Fournier construction below), which moves the + swap secret off-chain while leaving an ordinary P2SH spend on-chain. This is + the transparent-pool analogue of what Taproot key-path spends provide for + Bitcoin. + +Both legs of an HTLC swap reveal the same hash preimage on-chain. This makes the +two legs publicly linkable across chains: a privacy limitation that +adaptor-signature constructions explicitly fix (see +[Appendix: Bitcoin and Monero Adaptor-Signature Swap Primitives](btc-xmr-adaptor-swap-primitives.md)). +Zcash transparent supports both: + +- **HTLC**: standard, well-trodden, mirrors the existing ETH-LEZ reference + implementation. +- **ECDSA adaptor signature**: Lloyd Fournier's construction with a DLEQ proof. + The on-chain footprint becomes an ordinary 2-of-2 spend with no hash preimage + broadcast. +- **ECDH multiplicative key aggregation**: a third route used by + [Zwap](https://forum.zcashcommunity.com/t/zwap-unlinkable-cross-chain-atomic-swaps/55104), + the most active 2025 Zcash atomic-swap project. Trades adaptor-sig math for + ECDH + a hash-preimage half-HTLC. Less private than full adaptor-sig (still + embeds a hash on both chains) but easier to implement on chains that only + verify standard ECDSA. + +For LEZ as the counterparty side, the LEZ-side primitives required (SHA-256, +BIP-340 Schnorr verification at the witness layer, block-height and timestamp +validity windows, AND-multisig witness sets) are all present today. See the +inline LEZ primitive status section in RFP-003 for file citations. + +## Shielded pools: research-grade + +Sapling and Orchard expose no scripting. The only cryptographic hooks a swap +protocol can touch are: + +1. The **spendAuthSig**: a Schnorr-like signature over each spend. Sapling uses + RedJubjub on the Jubjub curve; Orchard uses RedPallas on the Pallas curve. + Both are instantiations of RedDSA. +2. The **transaction-level `nExpiryHeight`** field + ([ZIP-203](https://zips.z.cash/zip-0203)). Consensus rule: "the transaction + must be included in block N or earlier. Block N+1 will be too late, and the + transaction will be removed from the mempool." The maximum is 499,999,999 + (~1185 years). + +The critical limitation: **`nExpiryHeight` invalidates the *broadcast attempt*, +not the *funds*.** There is no shielded equivalent of `OP_CHECKLOCKTIMEVERIFY` +that creates a chain-enforced refund branch on a deposited note. Refund must +therefore be embedded in the swap-protocol's signed messages (e.g. a pre-signed +refund transaction exchanged before funding), the same approach taken by +adaptor-signature swaps on Bitcoin Taproot. + +### The re-randomization wrinkle + +RedDSA's per-spend re-randomization makes shielded adaptor sigs harder than the +BIP-340 case. Every Sapling / Orchard spend signs with a freshly randomized +validating key: + +``` +rk = ak + [α]·G (α sampled by the spender, per spend) +spendAuthSig = RedDSA.Sign(rsk, sighash) where rsk = ask + α +``` + +A standard Schnorr adaptor pre-signature `(R', s')` works only if both +pre-signer and completer agree on `α` ahead of time, since `rk` enters the +sighash and must match between pre-sig and completion. The completer also needs +`α` to verify the standard Schnorr equation against the on-chain `rk`. This is +not a fundamental obstacle (the FROST/RedDSA production stack already exposes a +`RandomizePrivate(α, ask)` API for working with randomized keys), but no +published paper or code specifically constructs an adaptor pre-signature against +Sapling or Orchard spend authorization. + +### Cross-curve binding + +A swap between LEZ (secp256k1) and Zcash shielded (Jubjub or Pallas) needs the +adaptor witness scalar to be valid on both curves. Group orders differ. The +standard mitigation, used by COMIT for XMR-BTC swaps, is to attach a cross-curve +DLEQ proof binding the same scalar across both groups. For Pallas the +pairing-friendly properties differ from Ed25519, so the COMIT cross-curve DLEQ +implementation is not a drop-in port; additional cryptographic work would be +required. + +### Best generic framework available + +The closest published framework is +[Universal Atomic Swaps](https://eprint.iacr.org/2021/1612) (Thyagarajan, +Malavolta, Moreno-Sánchez, IEEE S&P 2022), which proves a generic protocol over +"any chain that can verify signatures on transactions" using adaptor signatures +plus time-lock puzzles, with no custom scripting required. The paper does not +provide a Zcash-specific instantiation. Adapting it to RedJubjub / RedPallas +with re-randomization is the open work. + +## What Maya Protocol is, and isn't + +[Maya Protocol](https://docs.mayaprotocol.com/mayachain-dev-docs/protocol-development/chain-clients/zcash) +went live with native ZEC support in May 2025 and is the most visible production +"Zcash swap" path. It is worth being precise about the trust model: Maya is +**not** an atomic swap. It is a vault network with threshold-signed outbound +transactions. Funds are custodied by the TSS quorum of Maya node operators +between the inbound and outbound legs. Zcash side: transparent addresses +(`t1...`) only, ECDSA, OP_RETURN memos. + +Both atomic swaps and TSS vaults are valid product categories: vaults give +better UX and broader asset coverage; atomic swaps give stronger trust +guarantees. They should not be conflated when scoping a non-custodial swap RFP. + +## Feasibility matrix + +| Pool | Construction | Required Zcash primitive | Trust model | Production status (2026-05) | +| ----------------- | ---------------------------------- | ---------------------------------------------------------------------------------------------------------- | -------------------- | ------------------------------------------------------------------- | +| Transparent | BIP-199 HTLC | OP_IF/ELSE, OP_SHA256/HASH160, OP_CLTV, OP_CHECKSIG, P2SH | Non-custodial atomic | Reference (ZBXCAT 2017); active in Zwap 2025 | +| Transparent | ECDSA adaptor signature (Fournier) | secp256k1 ECDSA + non-malleable `s`, refund via OP_CLTV | Non-custodial atomic | None Zcash-specific; well-tested for Bitcoin | +| Transparent | ECDH key aggregation (Zwap) | ECDSA + hash-preimage spend + OP_CLTV refund | Non-custodial atomic | Zwap alpha (Zcash + Ethereum) | +| Transparent | Vault / TSS routing | OP_RETURN memo + ECDSA | Custodial-via-TSS | Maya Protocol live since 2025-05 | +| Sapling | RedJubjub adaptor signature | Pre-sig on randomized `rk` over Jubjub; α-aware adaptor protocol; nExpiryHeight as broadcast-deadline only | Non-custodial atomic | None | +| Orchard | RedPallas adaptor signature | Same as Sapling on Pallas curve | Non-custodial atomic | None | +| Sapling / Orchard | HTLC | n/a | n/a | Not implementable: no on-chain scripting | +| Sapling / Orchard | Vault / TSS | RedDSA-FROST (production-grade) | Custodial-via-TSS | Possible in principle; no production deployment to a shielded vault | + +## Recommendation for LEZ ↔ ZEC scope + +- **Phase 1 (deliverable):** LEZ ↔ Zcash transparent via the same pattern used + by the ETH-LEZ HTLC reference, with adaptor-signature variant as a stretch + goal for unlinkability. +- **Phase 2 (research, separate work):** LEZ ↔ Zcash shielded using a + Universal-Atomic-Swaps-style construction adapted to RedJubjub / RedPallas. + Treat this as a research deliverable, not a delivery deliverable. Funding and + timeline are open questions; the upstream cryptographic state of the art does + not yet provide a drop-in design. + +## References + +### Zcash protocol + +- [BIP-199: Hashed Time-Locked Contract transactions](https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki) +- [ZIP-48: Transparent Multisig Wallets](https://zips.z.cash/zip-0048): confirms + Zcash does not use SegWit `script_type` values, hence no Taproot on the + transparent pool +- [ZIP-202: Version 3 Transaction Format for Overwinter](https://zips.z.cash/zip-0202) +- [ZIP-203: Transaction Expiry](https://zips.z.cash/zip-0203) +- [ZIP-224: Orchard Shielded Protocol](https://zips.z.cash/zip-0224) +- [ZIP-304: Sapling Address Signatures](https://zips.z.cash/zip-0304) +- [Zcash Protocol Specification (NU6.1)](https://zips.z.cash/protocol/protocol.pdf) + +### Cryptographic libraries + +- [ZcashFoundation/redjubjub](https://github.com/ZcashFoundation/redjubjub): + RedJubjub (Sapling) +- [ZcashFoundation/reddsa](https://github.com/ZcashFoundation/reddsa): generic + RedDSA (Sapling + Orchard) +- [ZcashFoundation/frost-tools](https://github.com/ZcashFoundation/frost-tools): + FROST threshold signing for Zcash, including rerandomized variant +- [zcash/orchard](https://github.com/zcash/orchard): Orchard reference + implementation + +### Atomic swap research and prior art + +- [Universal Atomic Swaps (Thyagarajan, Malavolta, Moreno-Sánchez, 2022)](https://eprint.iacr.org/2021/1612): + generic scriptless atomic swap framework +- [Multi-Party, Multi-Blockchain Atomic Swap Protocol with Universal Adaptor Secret (2024)](https://arxiv.org/pdf/2406.16822) +- [Zswap: zk-SNARK Based Non-Interactive Multi-Asset Swaps](https://eprint.iacr.org/2022/1002.pdf) +- [Zwap forum thread](https://forum.zcashcommunity.com/t/zwap-unlinkable-cross-chain-atomic-swaps/55104): + Zcash transparent + Ethereum, ECDH-based +- [Maya Protocol Zcash docs](https://docs.mayaprotocol.com/mayachain-dev-docs/protocol-development/chain-clients/zcash): + vault/TSS model (for contrast) +- [comit-network/xmr-btc-swap](https://github.com/comit-network/xmr-btc-swap): + closest production analogue for adaptor swaps to a non-scriptable chain