[PROPOSAL] RFP-003 — Atomic Swaps between LEZ and BTC, XMR, ETH

[Nithin-Varma]

RFP ID

RFP-003 — Atomic Swaps with LEZ

Your Project Name

Logos Swap : Atomic Swaps between LEZ and BTC, XMR, ETH

Team or Organization Name

ModulusLabs

Primary Contact

hello@moduluslabs.dev, @xnithin telegram

Team Members

Arman (Aurobindo) — Cryptography Lead & Technical Lead

• GitHub: @aurobindo_arman
• Twitter/X: @aurobindo_arman

Owns the end-to-end cryptographic design and security model, with primary responsibility for the Monero leg (cross-curve DLEQ proofs and additive spend-key splitting) and hardening of the Bitcoin Schnorr adaptor signature path. Provides technical oversight across all layers to ensure uniform abstractions and attack-surface minimisation.

Extensive experience in zero-knowledge systems, TEE, and privacy primitives. Worked as Solutions Architect at Horizen Labs on ZK and TEE infrastructure. Founded Verisync Labs, a ZKML startup. Participated as an Aztec Fellow during the launch of their privacy-focused L2, gaining direct exposure to advanced privacy L2 architectures and execution environments. Built multiple privacy projects involving selective disclosure and private data handling:

• Link
• Link

---

Nithin Mengani — Project Lead (Monero and btc leg, Architecture & Integrations)

• GitHub: Nithin-Varma
• Linkedin: Nithin_Mengani
• Responsible for overall project coordination, architecture decisions across the three cryptographic regimes, and integration of the per-pair SDKs, C FFI bridge, maker daemon, and Basecamp components with the existing eth-lez-atomic-swaps plumbing (nssa_core, alloy, QML).

Technical background centres on cross-chain protocol design and production integrations. Recently built ParleySwap, a cross-chain sealed-bid intent protocol on Solana that uses MPC nodes for private intent execution (analogous to intent-based systems but native to Solana’s execution model). Research paper published on Springer, Designed and implemented Access Fi, an internet-verifiable markets platform where sellers prove data ownership via zero-knowledge proofs while raw content remains private. Contributed to Trust Protocol, a programmable on-chain trust primitive, including secure smart-contract architecture and trust-score formulation. Prior work includes multichain capability development across Solana, Tron and EVM chains, with focus on user-facing tools and production-grade integrations.

---

Dipanshu Singh — Protocol Engineer (Ethereum and Bitcoin Leg & Uniform Abstractions)

• GitHub: @dipanshuhappy

Responsible for the Bitcoin leg implementation (Schnorr adaptor signatures with Taproot key-path spends, BIP-340/341, adaptor extraction, and integration with the Risc0 escrow claim path) and the common SwapProtocol trait that unifies the three distinct cryptographic regimes.

Deep experience in Ethereum infrastructure and cross-chain interoperability. Contributed to Web3 engineering at Juspay. Core contributor at Normie Tech, shipping production systems from 0-to-1. Conducted implementation work on zkTLS and Groth16 WASM verification for wallet recovery in the ICP ecosystem. Strong practical background in protocol-level primitives, PTLC, HTLC architectures and Rust/EVM, interoperability layers, pecifically research paper published on Springer

---

Swaraj Bachu — Founding Engineer

• GitHub: @swarajbachu

Owns the per-pair Rust SDKs (lez-btc-sdk, lez-xmr-sdk, lez-eth-sdk), C FFI bridge to Qt6/QML, maker/taker CLIs, Basecamp mini-apps, and overall client-side usability and integration surface.

Founding Engineer at Legion, a merit-based crypto fundraising platform on Solana and Ethereum (backed by Coinbase Ventures and Kraken). Shipped production Solana programs, mobile applications, frontend, and CI/CD infrastructure end-to-end in a 0-to-1 startup environment after winning a competitive engineering trial. Additional portfolio of independently shipped Solana-native and full-stack systems:

• Delulu Social
• MorningPage
• UserBubble
• CacheZero

---

Kiran Kumar — Senior Rust Engineer (Ethereum Leg & Core Systems)

• GitHub: @TheGKRK

Owns the Ethereum leg hardening (extension of the existing Logos Ethereum module HTLC path and Risc0 guest program), the Tokio-backed swap coordinator + maker daemon, sled persistence, state machine, and all performance-critical Rust paths.

Independently designed and implemented HyperNova, the first trustless cross-chain bridge with MoveVM as destination execution environment. Full ownership of the Rust codebase covering core bridge logic, networking, cryptography integration (BLS keys for Supra native), alloy modules in Move, novel safe-block mechanism for stronger finality, complete fee model with on-chain Move verification, pre-concurrent block fetching, parallel submission, and live configuration updates. Performed security review and auditing of Move smart contracts. Designed and executed unit, invariant, fuzz, and adversarial E2E testing strategy. Lead dev and Cryptography at Modulus Labs and security research at Blockchain Security Academy. Deep expertise in EVM execution internals, Ethereum light clients, and sync-committee cryptography.

This demonstrates strong Rust client engineering and rapid production delivery capability.

Project Summary

Atomic swaps are the only trust-minimised path for foreign liquidity to enter LEZ. Every alternative like centralised exchange listings, wrapped-token bridges reintroduces a custodian, directly contradicting the trust-minimisation thesis LEZ is built on. Without this primitive, private accounts are a liquidity dead end: assets can be held privately but cannot move cross-chain without breaking the privacy guarantee. The DEX, lending, and every subsequent DeFi primitive on LEZ depends on this being solved first.

The work spans three distinct cryptographic regimes, each requiring a fundamentally different construction:

Bitcoin : no smart contract layer. Privacy requires Schnorr adaptor signatures with Taproot key-path spends (BIP-340/341), making each swap leg indistinguishable from a normal P2TR payment on-chain. So that we make sure, no script fingerprint, no HTLC, no cross-chain linkability via hash preimage.
LEZ claim uses scalar [t] submitted directly, guest verifies [t·G == T], closing the fake-signature attack vector entirely

Monero : no scripting at all. Atomicity is achieved by additively splitting the Monero spend key across two parties, with cross-curve DLEQ proofs binding a secp256k1 commitment to an Ed25519 key share across two entirely different elliptic curves. No on-chain lock, atomicity comes entirely from the cryptographic key construction.

Cooperative refund transaction is co-signed by both parties after XMR confirms (not before), because Monero one-time stealth addresses make pre-broadcast signing impossible

Ethereum : HTLC via the Logos Ethereum module. SHA-256 hashlock on both sides. Bob reveals preimage r on LEZ to claim, Alice reads r from LEZ proof journal to claim ETH

LEZ escrow : single Risc0 program, three claim paths:
BTC and XMR : scalar t submitted as witness, guest verifies t·G == T ETH : preimage r submitted as witness, guest verifies sha256(r) == H
WitnessSet handles authorization at the witness/auth layer. Guest handles cryptographic binding. Both checks required, neither sufficient alone
Starting point is eth-lez-atomic-swaps - we extend its proven LEZ plumbing (nssa_core, alloy, C FFI bridge, QML plugin architecture) to cover BTC and XMR, harden the ETH leg, and deliver a production-grade maker daemon, per-pair SDKs, and Basecamp mini-apps on top.

We commit to delivering all hard requirements across Functionality, Usability, Reliability, Performance and Supportability:

• Three fully working swap pairs – BTC, XMR, ETH
• Per-pair SDKs (lez-btc-sdk, lez-xmr-sdk, lez-eth-sdk)
• Maker daemon with systemd unit, maker and taker CLIs
• Maker and taker Basecamp mini-apps
• SPEL IDL
• Full node setup documentation for bitcoind testnet, monerod stagenet and Sepolia
• 9 demo videos – happy path, refund and concurrent swaps per chain

Both open questions from PR #48 – s-malleability and ValidityWindow enforcement timing answered with source traces and regression tests before M1 ends. If PR #49 merges before M1 ends, Zcash transparent leg scoped in as a fixed-fee addendum.

Technical Approach

System Architecture

Five layers, top to bottom:

1. Basecamp mini-apps (QML) – maker app (pairs, prices, active swaps), taker app (browse offers, initiate, monitor), maker and taker CLIs for headless operation

2. C FFI bridge – Rust library compiled as cdylib, exposed to Qt6/QML via C-compatible API. CLI talks to daemon over Unix-domain socket JSON-RPC.

3. Per-pair SDKs (Rust) – [lez-btc-sdk, lez-xmr-sdk, lez-eth-sdk]. Common SwapProtocol trait across all three — coordinator treats every pair uniformly. Trait sketch published for Logos review before any implementation commits

4. Swap coordinator + maker daemon – Tokio-backed Rust daemon with systemd unit. Drives every swap through its full lifecycle. Every state transition written to sled KV store before any external action crash at any point, restart resumes correctly. Logos Delivery for offer broadcast, Logos Chat for one-to-one negotiation

5. LEZ escrow program (Risc0) – single program, three claim paths. Claims go through WitnessSet – LEZ validates signatures natively at the witness/auth layer before the guest runs. No secp256k1_schnorr_verify inside the circuit

Starting point is eth-lez-atomic-swaps — we extend its existing plumbing (nssa_core, alloy, C FFI bridge, QML plugin) to cover BTC and XMR, harden the ETH leg, and build everything above it.

---
config:
  layout: fixed
---
flowchart TB
 subgraph L1["L1 — Basecamp Mini-Apps (QML / Qt6)"]
        MA["Maker Mini-App\npairs · prices · active swaps"]
        TA["Taker Mini-App\nbrowse offers · initiate · monitor"]
        MC["Maker CLI"]
        TC["Taker CLI"]
  end
 subgraph L2["L2 — Per-Pair SDKs (Rust crates)"]
        BTC_SDK["lez-btc-sdk\nSchnorr adaptor + Taproot"]
        XMR_SDK["lez-xmr-sdk\nEd25519 adaptor + DLEQ"]
        ETH_SDK["lez-eth-sdk\nHTLC + Logos ETH"]
  end
 subgraph L3["L3 — Swap Coordinator + Maker Daemon"]
        SM["State Machine\noffer → lock → claim → refund"]
        KV["KV Persistence\nsled · crash recovery · concurrent isolation"]
        MD["Maker Daemon\nprice feed · Logos Delivery · Logos Chat · systemd"]
  end
 subgraph L4["L4 — LEZ Escrow Program (Rust · Risc0)"]
        BTC_ESC["BTC escrow\nscalar t · t·G == T verify\nBlockValidityWindow"]
        XMR_ESC["XMR escrow\nscalar t · t·G == T verify\nTimestampValidityWindow"]
        ETH_ESC["ETH escrow\npreimage r · sha256(r) == H verify\nBlockValidityWindow"]
  end
 subgraph L5["L5 — External Chain Nodes"]
        BTC_NODE["Bitcoin\nbitcoind testnet\nsecp256k1-zkp · rust-bitcoin"]
        XMR_NODE["Monero\nmonerod stagenet\ncross-curve-dleq · monero-rs"]
        ETH_NODE["Ethereum\nLogos ETH module\nalloy · Sepolia"]
  end
    MA -- C FFI bridge cdylib --> BTC_SDK & XMR_SDK & ETH_SDK
    TA -- C FFI bridge cdylib --> BTC_SDK & XMR_SDK & ETH_SDK
    MC -- Unix socket IPC --> MD
    BTC_SDK --> SM
    XMR_SDK --> SM
    ETH_SDK --> SM
    SM --> KV & MD & BTC_ESC & XMR_ESC & ETH_ESC
    BTC_ESC --> BTC_NODE
    XMR_ESC --> XMR_NODE
    ETH_ESC --> ETH_NODE
    TC L_TC_SM_0@-- Unix socket IPC --> SM
    ```@{ label: "```" }


    L_TC_SM_0@{ curve: linear }

Loading

LEZ Escrow

Simple Three instructions, basically 3 paths.

> initialize_escrow(swap_id, claim_pubkey, T_or_H, validity_window, proof_type)
> claim(swap_id, witness)   // scalar t (BTC/XMR) or preimage r (ETH)
> refund(swap_id)           // callable after validity_window expires

Claim paths...

BTC : Alice claims BTC on Bitcoin, completing s = ŝ + t. Bob extracts t = s - ŝ from the completed signature visible on Bitcoin. Bob submits scalar t to LEZ escrow. Guest verifies t·G == T against stored commitment. LEZ released

XMR : Bob submits scalar t to LEZ escrow. Guest verifies t·G == T against stored commitment. LEZ released

ETH : Bob submits preimage r to LEZ escrow. Guest verifies sha256(r) == H against stored hashlock using risc0_zkvm::sha. LEZ released. r visible in proof journal — Alice reads it to claim ETH

Why scalar t, not the full signature (BTC)
If the guest only checked that a valid signature from claim_pubkey appeared in WitnessSet, Bob could submit any fresh Schnorr signature unrelated to the swap. WitnessSet would pass, guest would release LEZ, but t is never revealed and Alice cannot claim BTC. Submitting t directly and verifying t·G == T in-guest closes this attack entirely. BTC and XMR claim paths are now identical in the guest.

Timelock safety invariant

> BTC, XMR:  Δ_foreign > Δ_lez + ε
> ETH:       Δ_lez > Δ_eth
> 
> ε_btc ~ 6 blocks  (~60min block time variance)
> ε_xmr ~ 20 blocks (~40min block time variance)
> ε_eth ~ 50 blocks (~10min block time variance)

BTC/XMR: Alice claims foreign funds first, revealing t. Bob must claim LEZ before Δ_lez expires. Foreign chain timeout must be longer so maker can refund if taker never claims

ETH: Bob reveals r on LEZ first. Alice must claim ETH before Δ_eth expires. LEZ timeout must be longer so Alice has time to act after Bob reveals

Cryptographic Construction

Schnorr Adaptor Signatures — BTC

Normal Schnorr: s = r + e·x
Adaptor sig: ŝ = r + t + e·x

Adaptor verify: ŝ·G == R + T + e·X (well-formed, t unknown)
Normal verify: ŝ·G ≠ R + e·X (invalid as-is)
Complete: s = ŝ + t → s·G == R + e·X
Extract: t = s - ŝ

t is a fresh random scalar per swap (OsRng). T = t·G published before any funds move
Formal security: aEUF-CMA, witness-extractability, pre-signature adaptability (Aumayr et al. 2021)
Test vector conformance against DLC-specs AdaptorSignature.md
Libraries: secp256k1-zkp, secp256kfun, rust-bitcoin

HTLC — ETH

H = sha256(r) (hashlock, published at setup)
r (preimage, revealed on LEZ claim)

Bob picks random preimage r, computes H = sha256(r), shares H with Alice
Both sides locked behind the same H – Alice locks LEZ with H, Bob locks ETH with H
Bob reveals r to claim LEZ first. Alice reads r from LEZ proof journal to claim ETH
In-guest SHA-256 via risc0_zkvm::sha – consistent with eth-lez-atomic-swaps reference impl

Cross-Curve DLEQ Proof — XMR

T  = t·G  (secp256k1 — for LEZ WitnessSet)
T' = t·H  (Ed25519  — for XMR joint wallet)

DLEQ proof π: log_G(T) == log_H(T')
Same scalar t, two different curves, t never revealed

Without DLEQ, taker could use different secrets on each curve — breaks atomicity entirely
Library: comit-network/cross-curve-dleq

Monero Spend Key Splitting — XMR

full_spend_key    = maker_share + t
joint_addr pubkey = MakerPublicShare + T'

• Neither party can spend alone — maker lacks t, taker lacks maker_share
• No on-chain scripting — atomicity comes entirely from the key construction
• Why pre-broadcast signing is impossible on Monero: one-time stealth addresses use P = Hs(rA)·G + B where r is chosen at broadcast time. The output key P and global output index (needed to construct a spending tx) are unknown until after the funding tx confirms. Ring signature decoys must also exist at spend time. All three are unknowable before broadcast
• Cooperative refund: immediately after XMR confirms, both parties co-sign a Monero refund tx using the now-known output key and global output index. This co-signed refund is the maker's recovery path if the protocol is abandoned after this point
• Economic protection: taker locks LEZ first. Going dark after XMR is sent loses taker's own LEZ with no gain — zero economic incentive to abandon.

Swap Flows

Alice = taker (has LEZ, wants BTC/XMR/ETH). Bob = maker (has BTC/XMR/ETH, wants LEZ). Alice always locks first on LEZ.

BTC ↔ LEZ

Setup via Logos Chat:

Alice: t ← OsRng, T = t·G, ŝ = r + t + e·x → sends (T, ŝ) to Bob
Bob: verifies ŝ·G == R + T + e·X ✓, builds P2TR output via MuSig2 (BIP-327)

On-chain — Alice locks first:

• Alice: initialize_escrow(swap_id, Bob_pubkey, T, Δ_lez) — LEZ locked
• Bob: verifies LEZ lock, locks BTC in P2TR output (Δ_btc > Δ_lez + ε)
• Alice: s = ŝ + t → Taproot key-path spend → claims BTC. t visible on Bitcoin embedded in completed sig
• Bob: extracts t = s - ŝ from Bitcoin. Submits t to LEZ escrow → guest verifies t·G == T → claims LEZ ✓
• Privacy: BTC tx is OP_1 <32-byte-key> with 64-byte witness — identical to any normal Taproot payment. No script revealed, no hash linking both legs
• Refund: Bob never locks → Alice calls refund() after Δ_lez expires

XMR ↔ LEZ

Setup via Logos Chat:

Alice: t ← OsRng, T = t·G (secp256k1), T' = t·H (Ed25519), π = DLEQ_prove(t,G,H) → sends (T, T', π) to Bob
Bob: verifies DLEQ_verify(T, T', π) ✓, computes joint_addr = MakerPublicShare + T'

On-chain — Alice locks first:

• Alice: initialize_escrow(swap_id, Bob_pubkey, T, Δ_lez) — LEZ locked
• Bob: sends XMR to joint_addr (Δ_xmr > Δ_lez + ε) — neither can spend alone
• Both: XMR confirms → both parties immediately co-sign Monero refund tx using now-known output key and global output index
• Alice: full_spend_key = maker_share + t → sweeps XMR to own wallet. t revealed on Monero via spend
• Bob: extracts t from Monero spend. Submits t to LEZ escrow → guest verifies t·G == T → claims LEZ ✓
• Refund: Alice dark after XMR locked → Bob broadcasts co-signed refund tx after Δ_xmr. Alice calls refund() after Δ_lez expires
• Stuck scenario: if taker goes dark between XMR confirming (step 2) and co-signing refund (step 3), XMR may be stuck in the joint wallet. Economic disincentive is the primary protection. Cooperative refund window is kept as small as possible — handled automatically by daemon within seconds of XMR confirmation

ETH ↔ LEZ

Setup via Logos Chat:

Bob: picks r ← OsRng, computes H = sha256(r) → sends H to Alice
Alice: receives H, agrees on amounts and timelock parameters

On-chain — Alice locks first:

• Alice: initialize_escrow(swap_id, Bob_pubkey, H, Δ_lez) — LEZ locked with hashlock H
• Bob: verifies LEZ lock, locks ETH/ERC-20 via Logos ETH module on Sepolia with same H (Δ_eth < Δ_lez)
• Bob: submits r to LEZ escrow → guest verifies sha256(r) == H → claims LEZ. r now visible in proof journal
• Alice: reads r from LEZ proof journal → calls claim(swapId, r) on Logos ETH module → claims ETH ✓
• Timelock ordering: Δ_lez > Δ_eth — LEZ timelock is longer so Alice always has time to claim ETH after Bob reveals r on LEZ
• Refund: Bob never locks ETH → Alice calls refund() after Δ_lez expires

sequenceDiagram
    participant Alice as Alice (Taker)
    participant LEZ as LEZ Escrow
    participant Bob as Bob (Maker)
    participant BTC as Bitcoin
    participant XMR as Monero
    participant ETH as Ethereum

    Note over Alice,BTC: BTC ↔ LEZ — Setup via Logos Chat
    Alice->>Alice: t ← random scalar
    Alice->>Alice: T = t·G
    Alice->>Alice: ŝ = r + t + e·x
    Alice->>Bob: sends (T, ŝ)
    Bob->>Bob: verifies ŝ·G == R + T + e·X ✓
    Bob->>Bob: agg_key = MuSig2(Alice_key, Bob_key)
    Bob->>Bob: P2TR = Taproot(agg_key, refund_script)

    Note over Alice,BTC: On-chain — Alice locks first
    Alice->>LEZ: initialize_escrow(swap_id, Bob_pubkey, T, Δ_lez)
    Bob->>BTC: locks BTC in P2TR output (Δ_btc > Δ_lez + ε)
    Alice->>BTC: s = ŝ + t → Taproot key-path spend → claims BTC
    Note right of BTC: t now visible on Bitcoin embedded in s
    Bob->>Bob: extracts t = s - ŝ from Bitcoin tx
    Bob->>LEZ: submits t → guest verifies t·G == T → claims LEZ ✓

    Note over Alice,BTC: Refund — Bob never locks BTC
    Alice->>LEZ: refund() after Δ_lez expires → reclaims LEZ

    Note over Alice,XMR: XMR ↔ LEZ — Setup via Logos Chat
    Alice->>Alice: t ← random scalar
    Alice->>Alice: T = t·G (secp256k1) · T' = t·H (Ed25519)
    Alice->>Alice: π = DLEQ_prove(t, G, H)
    Alice->>Bob: sends (T, T', π)
    Bob->>Bob: verifies DLEQ_verify(T, T', π) ✓
    Bob->>Bob: joint_addr = MakerPublicShare + T'

    Note over Alice,XMR: On-chain — Alice locks first
    Alice->>LEZ: initialize_escrow(swap_id, Bob_pubkey, T, Δ_lez)
    Bob->>XMR: sends XMR to joint_addr (Δ_xmr > Δ_lez + ε)
    Note right of XMR: Neither can spend alone yet
    Bob->>Alice: XMR confirmed — both co-sign Monero refund tx now
    Note right of XMR: Output key + global index now known
    Alice->>XMR: full_spend_key = maker_share + t → sweeps XMR
    Note right of XMR: t revealed on Monero via spend
    Bob->>Bob: extracts t from Monero spend
    Bob->>LEZ: submits t → guest verifies t·G == T → claims LEZ ✓

    Note over Alice,XMR: Refund — Alice dark after XMR locked
    Bob->>XMR: broadcasts co-signed refund tx after Δ_xmr
    Alice->>LEZ: refund() after Δ_lez expires → reclaims LEZ

    Note over Alice,ETH: ETH ↔ LEZ — Setup via Logos Chat
    Bob->>Bob: r ← random scalar
    Bob->>Bob: H = sha256(r)
    Bob->>Alice: sends H
    Alice->>Alice: agrees on amounts and timelock parameters

    Note over Alice,ETH: On-chain — Alice locks first
    Alice->>LEZ: initialize_escrow(swap_id, Bob_pubkey, H, Δ_lez)
    Bob->>ETH: locks ETH/ERC-20 via Logos ETH module with H (Δ_eth < Δ_lez)
    Bob->>LEZ: submits r → guest verifies sha256(r) == H → claims LEZ
    Note right of LEZ: r now visible in proof journal
    Alice->>ETH: reads r from LEZ · calls claim(swapId, r) → claims ETH ✓

    Note over Alice,ETH: Refund — Bob never locks ETH
    Alice->>LEZ: refund() after Δ_lez expires → reclaims LEZ

Loading

Swap State Machine

stateDiagram-v2
    direction LR
    [*] --> IDLE
    IDLE --> OFFER_PUBLISHED
    OFFER_PUBLISHED --> NEGOTIATING
    NEGOTIATING --> TAKER_LOCKED
    TAKER_LOCKED --> MAKER_LOCKING
    MAKER_LOCKING --> MAKER_LOCKED
    MAKER_LOCKED --> CLAIMING
    CLAIMING --> COMPLETE
    CLAIMING --> REFUND_PENDING
    MAKER_LOCKED --> REFUND_PENDING
    TAKER_LOCKED --> REFUND_PENDING
    REFUND_PENDING --> REFUNDED
    COMPLETE --> [*]
    REFUNDED --> [*]

Loading

Every transition persisted to sled before any external action
Restart reads state, resumes from last persisted point, no funds lost across crashes
Per-swap isolation, independent state, escrow, timelock per swap_id
Fuzz tested against fault injection from M2 using cargo-fuzz, every scenario resolves to complete or refund, never stuck

Security Considerations

1. Fake-signature attack on BTC claim : mitigated. The BTC claim path submits scalar t directly rather than the completed adaptor signature. Guest verifies t·G == T, Bob cannot claim LEZ without the actual adaptor secret obtainable only from Alice's completed signature on Bitcoin.

2. Cross-curve binding on XMR : mitigated. DLEQ proof π cryptographically binds the LEZ adaptor commitment and the XMR joint wallet to the same scalar t before any funds move.

3. Monero stuck scenario : known limitation, documented. If taker goes dark between XMR confirming and cooperative refund co-signing, XMR may be stuck permanently. Primary protection is economic — taker's LEZ is also at risk. Daemon minimises the co-signing window to seconds of XMR confirmation. Full failure point analysis in the write-up.

Both open questions from PR #48 — s-malleability and ValidityWindow enforcement timing will check the source code and resolve with source traces and regression tests before M1 ends.

Anticipated Challenges

1. Monero pre-broadcast signing : can't pre-sign a refund tx before XMR confirms because output key and global index don't exist yet. Both parties co-sign the refund immediately after XMR confirms. Daemon handles this within seconds of confirmation

2. Monero stagenet CI : public faucets go offline randomly and block CI for days. We run a self-hosted stagenet node with pre-funded wallets so tests always have XMR available, this applicables for testnet.

3. Crash recovery under concurrent swaps : state machine fuzz tested with cargo-fuzz from M2. Every failure scenario resolves to complete or refund, never stuck

4. SDK trait across three different protocols : BTC, XMR and ETH have fundamentally different failure modes. SwapProtocol trait sketch shared with Logos before any implementation starts so the abstraction is agreed before we commit to it.

5. CU budget changes during testnet : per-op costs documented against a specific testnet version and re-benchmarked whenever LEZ ships a testnet update.

Milestones, Payout and Timeline

Our 5-person team runs multiple milestones in parallel, cryptography work on BTC and XMR, ETH and LEZ escrow foundation, and daemon development all progress on separate tracks simultaneously. This structure targets delivery at the lower end of the 16-week estimate, leaving buffer at the tail for integration testing, hardening, and any unexpected testnet-related delays. All timelines are estimates — we will flag any blockers to Logos as early as possible.

---

M1 — Design, LEZ primitive verification, SDK trait surface
Duration: 1.5 weeks | Payout: $20,000

• Per-leg protocol design write-up — BTC (Schnorr adaptor + Taproot), XMR (Ed25519 adaptor + cross-curve DLEQ), ETH (HTLC). Atomicity argument stated in Aumayr et al. 2021 terms (aEUF-CMA, witness-extractability, pre-signature adaptability)
• Written answers to both PR RFP-003: unblock atomic swaps, add LEZ primitive status #48 open questions — s-malleability and ValidityWindow enforcement timing — with source traces and regression tests committed before any cryptography work starts
• LEZ escrow program design — SPEL IDL sketch, claim and refund path per pair
• SwapProtocol trait sketch published for Logos review before any implementation commits
• KV store choice decided and justified

---

M2 — ETH ↔ LEZ leg + LEZ escrow foundation
Duration: 2.5 weeks | Payout: $30,000

• LEZ escrow program deployed on testnet 0.2 — ETH HTLC claim path (sha256(r) == H), BlockValidityWindow / TimestampValidityWindow for refund
• LEZ-ETH SDK — full lifecycle (offer, negotiation, escrow creation, claim, refund)
• Logos ETH module integration tests against Sepolia in CI. Full ERC-20 path coverage
• Sepolia Web3 RPC setup documentation
• ETH demo set — happy path, refund/timeout, concurrent swaps

---

M3 — BTC ↔ LEZ leg
Duration: 4 weeks | Payout: $35,000

• LEZ escrow program updated for BTC claim path — scalar t submitted directly, guest verifies t·G == T
• LEZ-BTC SDK — full lifecycle including Taproot P2TR construction via MuSig2 (BIP-327)
• DLC-specs AdaptorSignature.md test vector conformance, extended for swap-specific scenarios
• bitcoind testnet setup documentation (self-hosted + public node options)
• BTC demo set — happy path, refund/timeout, concurrent swaps

---

M4 — XMR ↔ LEZ leg
Duration: 4 weeks | Payout: $45,000

• LEZ escrow program updated for XMR claim path — scalar t submitted, guest verifies t·G == T
• LEZ-XMR SDK — full lifecycle including DLEQ proof generation, joint wallet construction, cooperative refund co-signing after XMR confirms
• DLEQ test vector conformance against comit-network/cross-curve-dleq
• Self-hosted monerod stagenet node in CI with pre-funded wallets
• monerod + monero-wallet-rpc stagenet setup documentation
• XMR demo set — happy path, refund/timeout, concurrent swaps

---

M5 — Maker daemon, CLIs, swap coordinator
Duration: 3 weeks | Payout: $30,000

• Maker daemon (Tokio + Rust) with systemd unit and installation docs
• Maker CLI — configure pairs/prices, start/stop, query history, manual claim/refund
• Taker CLI — offer discovery, swap initiation, progress monitoring, claim/refund
• Swap coordinator — sled persistence, crash recovery, concurrent swap isolation per swap_id
• Graceful Logos Delivery / Chat unavailability handling documented
• cargo-fuzz harness against the swap coordinator state machine

---

M6 — Basecamp mini-apps, SPEL IDL, final integration
Duration: 2 weeks | Payout: $20,000

• Figma designs for both mini-apps signed off before any UI code
• Maker mini-app (QML) — pair/price configuration, active swap monitoring, swap history. Basecamp-loadable via git repo
• Taker mini-app (QML) — offer browsing, swap initiation, progress monitoring
• SPEL IDL for all program instructions
• End-to-end CI green on default branch. All hard requirement tests passing
• README and per-pair SDK API docs submitted via logos-co/logos-docs template

Total budget: $180,000 across 6 milestones.

Security Audit: Not included in this budget. We plan to scope it after M3 once the core cryptographic constructions are complete. We have existing connections with audit firms and are open to Logos suggesting or directly contracting a preferred auditor.

Total Requested Budget (USD)

180000

Relevant Experience

• Horizen Labs & zkVerify — Arman worked as Solutions Architect at Horizen Labs on ZK and TEE infrastructure. Horizen Labs builds zkVerify, a production ZK proof verification blockchain, and privacy-preserving systems using zk-SNARKs for enterprise and DeFi applications.

• Aztec Fellowship — Arman participated as an Aztec Fellow during the launch of their privacy L2. Aztec's programmable privacy model — private state, ZK-enforced execution, selective disclosure — is architecturally the closest existing production system to LEZ's execution environment. https://aztec.network

• Privacy Projects — Arman has independently built and shipped multiple privacy-preserving systems involving selective disclosure and private data handling.

  • https://x.com/aurobindo_arman/status/1965473390724350028
  • https://x.com/aurobindo_arman/status/1940513543423668618

• HyperNova — Kiran independently designed and shipped the first trustless cross-chain bridge with MoveVM as destination execution environment. Full Rust codebase from scratch — BLS key integration, novel safe-block mechanism, alloy modules in Move, fuzz + invariant + adversarial E2E test coverage. Production deployed. The swap coordinator and LEZ escrow program are structurally the same shape of work. https://supranova.ai

• Legion — Swaraj is founding engineer at Legion, a production Solana and Ethereum fundraising platform backed by Coinbase Ventures and Kraken. Shipped protocol, SDK, mobile, frontend, and CI/CD end-to-end in a 0-to-1 environment. https://legion.cc

• Blockchain Interoperability Research — Nithin and Dipanshu co-authored a peer-reviewed research paper on cross-chain protocol design, published on Springer (SCI). https://link.springer.com/article/10.1007/s12083-025-01941-w

• ParleySwap — Nithin built a sealed-bid intent DEX on Solana using MPC nodes for private intent execution — the direct predecessor to this work in privacy threat model and anti-front-running design. https://parleyswap.vercel.app

Post-Delivery Plan

Post-Delivery Plan

The repository is owned by Logos from day one.

UI and Bug fix maintenance (12 months, free) — critical and high-severity bugs fixed at no cost across all delivered components: LEZ escrow program, all three SDKs, swap coordinator, maker daemon, CLIs, and mini-apps. CVE-class findings triaged within 24 hours.

Extensions (paid, scoped on request)

• Zcash transparent leg if PR #49 merges after delivery
• ETH adaptor signature variant as a follow-on to the HTLC baseline
• Additional EVM-compatible chains via the Logos Ethereum module
• Intent-based solver layer on top of the atomic swap primitive once LEZ has sufficient liquidity — a natural evolution toward a trust-minimised DEX, which is work we have direct prior experience building with ParleySwap

We are open to a longer-term maintainer arrangement as atomic swaps become a standard primitive on LEZ.

Permissions and Consent

• I confirm Logos may contact me using the primary contact information provided above for follow-ups and next steps.
• I consent to Logos using information from this proposal publicly such as blogs case studies social posts or analytical reporting. Redactions can be requested at any time.

Program Requirements

• We understand this project must be open-sourced under the MIT and Apache 2.0 Licenses unless explicitly approved otherwise.
• We are prepared to deliver milestone-based outcomes.