[PROPOSAL] RFP-003 — LEZ Atomic Swap Suite (BTC + XMR + ZEC)

[mandrigin]

[PROPOSAL] RFP-003 — LEZ Atomic Swap Suite (BTC + XMR + ZEC)

Note: this issue supersedes #61 (Gateway's original RFP-003 submission of 21 May 2026, subsequently revised on 1 July 2026). It is filed as a new issue because the original author no longer has edit access. It incorporates: (1) the final scope agreed with Logos in July 2026 — ETH removed, Zcash transparent added; final scope BTC + XMR + ZEC ↔ LEZ; (2) the formal-review requirements added to the RFP on 30 June (Supportability 12 and 13, commit a749e99); (3) the price-feed update merged in PR #108 (external price feed sourced from a Logos module via its C API); (4) the revised commercials agreed with Logos ($296,000 all-in including the third-party audit — below the $300K target); and (5) a team update: Igor Mandrigin (CTO) is now the primary contact for this engagement.

RFP ID

RFP-003

Your Project Name

LEZ Atomic Swap Suite: BTC, XMR, ZEC (adaptor signatures + HTLC)

Team or Organization Name

Gateway

Primary Contact

Igor Mandrigin, igor@gateway.fm, GitHub @mandrigin
Commercial and contract matters: Vuk Radoicic, vuk.radoicic@gateway.fm

Team Members

Igor Mandrigin, CTO and applied-cryptography lead

• GitHub: @mandrigin
• Role on this project: Engagement lead, principal architect, and applied-cryptography lead. Owns: the LEZ escrow program design; the cross-chain atomicity argument (stated in Aumayr et al. terms); the design sign-off on the Zcash transparent HTLC leg; the Schnorr/secp256k1 adaptor construction with Taproot key-path spends (BIP-340 / BIP-341) on the BTC leg; the Ed25519 adaptor signature with cross-curve DLEQ proofs (h4sh3d / COMIT) on the XMR leg; the formal security argument across all three legs; and the security review of every milestone before delivery. Also the commercial counterpart for Logos on delivery matters, with milestone accountability and sign-off on every public artefact before publication.
• Status: Full-time across milestones 3 and 4 (the cryptography-heavy BTC and XMR legs, around 9 weeks of concurrent crypto work). Part-time across M1, M2, M5, M7 in his CTO/architect role.
• Background relevant to RFP-003: Ex-Erigon co-author, with 421+ commits on erigontech/erigon and 545+ commits on cdk-erigon. Daily-driver execution-client work covers state DB, EVM interpreter, sync, RPC, gas semantics, and secp256k1 / ECDSA / keccak256 precompile engineering, which is the direct execution-client-precompile background from which the BTC adaptor-signature work extends. The cross-VM correctness reasoning Gateway has shipped in the Miden agglayer proxy is the same shape as the LEZ-side atomicity argument. Cryptography milestones are delivered by implementing the published constructions (DLC-specs AdaptorSignature.md test vectors, the h4sh3d / COMIT cross-curve DLEQ construction, secp256k1-zkp and secp256kfun reference libraries), with all formal-security claims stated in Aumayr et al. (2021) terms and audited at M7.

Elliot Hallam, Senior Developer

• GitHub: @elliothllm
• Role on this project: LEZ-side and ZEC-leg implementation lead. Ships the LEZ Risc0 escrow program, lifts the LEZ-side SHA-256 HTLC preimage path from the eth-lez-atomic-swaps reference into the production Zcash transparent leg (BIP-199 HTLCs), owns the Zcash node integration and test coverage on Zcash testnet, and shares SDK design with Ivan. Pairs with Igor through milestone 4 on the LEZ side of the XMR leg.
• Status: Full-time on the engagement.
• Background: Senior Gateway developer. cdk-erigon contributor with 145+ commits (porting battle-tested execution-environment logic across exec environments is the daily job; the HTLC-script-to-Rust-plus-Risc0 lift on the LEZ escrow side is the same shape of work). Contributor to Gateway's privacy stack (Open Privacy Suite), which informs the SDK ergonomics around the shield/deshield patterns ZEC and LEZ users will expect. Miden agglayer contributor, where Risc0 guest programs that verify cross-chain claims is structurally adjacent work.

Ivan Beliakov, Senior Developer

• GitHub: @IvanBelyakoff
• Role on this project: Distributed-systems and SDK lead. Ships the maker daemon, the swap-coordinator state machine (state persistence, crash recovery, concurrent-swap isolation), the maker and taker CLIs, the IPC/RPC layer, the price-source plugin trait and its two reference impls (local configuration, and a Logos-module C API adapter per PR RFP-003: source external price feed from a Logos module C API #108), and the per-pair SDK trait surface. Pairs with Igor through milestones 3 and 4 to ship the BTC and XMR SDKs.
• Status: Full-time on the engagement.
• Background: Senior Gateway developer. cdk-erigon contributor with 230+ commits, contributor to Gateway's privacy stack (Open Privacy Suite), Miden agglayer contributor. The combination of execution-client production experience and crash-recovery state-machine instinct is the right profile for a swap coordinator that has to be correct under fault injection.

Coverage note. The three named Gateway engineers cover the three capabilities Gateway leads with: execution-client depth (920+ combined commits on cdk-erigon plus Igor's 421+ on Erigon), proof-aware cross-VM bridging (Miden agglayer in production, SP1 full-execution proofs on agglayer-connected chains), and privacy-application instinct (Open Privacy Suite — directly relevant now that a Zcash leg with an explicit shield-after-swap user pattern is in scope). The fourth capability, BTC/XMR applied cryptography (adaptor signatures over secp256k1 and cross-curve DLEQ proofs between secp256k1 and Ed25519), is delivered internally: Igor doubles as the applied-cryptography lead through the BTC and XMR milestones, leveraging his secp256k1 / ECDSA / keccak256 precompile work on Erigon and cdk-erigon as the execution-client-precompile base from which the adaptor-signature implementations extend. The reference cryptography is the published COMIT / h4sh3d / DLC-specs construction; Gateway is implementing well-specified primitives, not researching new ones, and Igor's depth as an ex-Erigon co-author is the right backstop for that kind of careful applied-cryptography work.

Senior engineering bench. Beyond the named engineers above, Gateway maintains a wider senior bench across cdk-erigon / Reth / Rust execution-client work. Additional engineers from that bench are available to be allocated to this engagement as scope requires, without external recruitment. The named team is the headline; the bench is depth.

Team composition: Leadership on this engagement is fixed: Igor Mandrigin (CTO, principal architect, and applied-cryptography lead) remains unchanged and continues to own the cross-chain atomicity argument, the cryptographic constructions across all three legs, and security review sign-off on every milestone. Gateway further commits to retaining at least half of the named engineers above for the duration of the engagement. Any remaining changes in individual allocation will be equivalent-seniority substitutions from Gateway's wider senior bench (cdk-erigon / Erigon / Reth / Rust execution-client and applied-cryptography experience). Milestone scope, delivery accountability, review sign-off, and the quality bar committed to in this proposal remain unchanged regardless of individual allocation.

Project Summary

The atomic-swap primitive is the prerequisite for everything else on LEZ. Without it, every dollar of liquidity into LEZ flows through a wrapped-token bridge, a centralised exchange listing, or both, each in direct conflict with the trust-minimisation thesis the LEZ ecosystem is built on. The RFP's Why This Matters section makes the point well; we agree with it; we want to be the team that ships against it.

This revision reflects the final scope agreed with Logos in July 2026: BTC + XMR + ZEC ↔ LEZ, with the ETH pair removed (per Logos's determination that zkBridges are the more UX-friendly path for ETH bridging, with minimal downside relative to atomic swaps). The work spans three distinct on-chain regimes: Schnorr/Taproot adaptor signatures over secp256k1 for Bitcoin, Ed25519 adaptor signatures with cross-curve DLEQ proofs for Monero, and BIP-199 HTLCs on the Zcash transparent pool for ZEC — coordinated by a Risc0 guest program on the LEZ side and orchestrated maker-side over Logos Delivery and Logos Chat. The reference ETH ↔ LEZ implementation (eth-lez-atomic-swaps) remains directly useful even with ETH out of scope: its LEZ-side SHA-256 HTLC preimage path carries over to the ZEC leg nearly unchanged, since the LEZ escrow logic for an HTLC leg is chain-agnostic. The BTC and XMR legs are net-new and constitute the bulk of the cryptography work; the ZEC leg's net-new work is Zcash node-side plumbing and transaction construction on the transparent pool.

Gateway's edge on this RFP is unusual stack alignment, not headline brand. Igor's ex-Erigon depth and the team's cdk-erigon authorship give the team daily-driver fluency in execution-client internals, and Igor's secp256k1 / ECDSA / keccak256 precompile work on Erigon is the execution-client-precompile background from which he extends to the BTC and XMR adaptor-signature work as the named cryptography lead. Elliot's and Ivan's Miden agglayer work (bridging a STARK-based zkVM into Polygon's agglayer in production) is structurally the same shape as a Risc0 guest program that locks funds against off-chain adaptor-witness reveals from a foreign chain. Open Privacy Suite gives us the privacy-application instinct to design SDK ergonomics around the shield-after-swap pattern ZEC users will follow, and the deshield-shape patterns LEZ users will use, even where the swap protocol itself is public-execution. PR #48 (LEZ Primitive Status, opened 2026-05-06) is the reason the bid lands now rather than holding: the dev-block on LEZ timelock support is closed, and the inventory of present primitives is now a public artefact applicants can reason about without auditing the source themselves.

The bid commits to every hard requirement in the current RFP-003 specification, including the two formal-review requirements added on 30 June (Supportability 12: third-party review of all smart contracts and on-chain scripts — the LEZ escrow program, the Bitcoin Taproot scripts and pre-signed transactions, and the Zcash transparent HTLC scripts; Supportability 13: third-party review of the cross-chain swap protocol implementation — atomicity guarantees, taker-first ordering, timelock handling, and the per-chain adaptor-signature / HTLC constructions, with review reports and remediations included in the submission) and the price-feed update merged in PR #108 (external price feed sourced from another Logos module via its C API). Concretely: all Functionality requirements for the three in-scope pairs; all Usability requirements (per-pair SDKs for LEZ–BTC, LEZ–XMR, LEZ–ZEC; maker daemon + systemd unit; maker CLI; taker CLI; maker mini-app GUI; taker mini-app GUI; SPEL IDL; full node-setup documentation for bitcoind testnet, monerod stagenet, and a Zcash node on testnet; interactive HTML prototypes for both mini-app GUIs per the "Figma designs or equivalent" requirement); all Reliability requirements (taker-first ordering, on-chain-only execution after lock, graceful degradation across chains, swap state persistence, concurrent swap isolation, documented timelock parameter rationale, graceful handling of Logos Delivery / Chat unavailability); the Performance requirement (per-op CU usage documented per LEZ testnet version); all Supportability requirements including the third-party formal reviews under milestone 7; and all three Demo requirements per chain (happy path, refund/timeout, concurrent) for BTC, XMR, and ZEC.

Technical Approach

Architecture overview

Five components, in dependency order:

1. LEZ escrow program. Rust + Risc0, deployed on LEZ testnet 0.2, built on the SPEL framework. One claim mechanism per pair (SHA-256 hash preimage for the ZEC leg, Schnorr adaptor-witness reveal via WitnessSet for the BTC leg, Schnorr adaptor-witness reveal with cross-curve DLEQ binding to the XMR spend key for the XMR leg), and one refund path per pair (timelock expiry via BlockValidityWindow / TimestampValidityWindow). Native LEZ token and custom-token-via-ATAs both supported per F7.
2. Per-pair SDKs (LEZ/BTC, LEZ/XMR, LEZ/ZEC). Rust crates exposing the full lifecycle (offer discovery, negotiation, escrow creation, claim, refund) for each pair. The SDK trait surface is the integration contract for downstream Logos modules; it is the first thing other RFP holders will read. Designed as one shared trait + per-pair impls, so a future pair (an ETH leg via the Logos Ethereum module, further EVM chains, a ZEC adaptor-signature variant) drops in without an SDK redesign.
3. Swap coordinator. Local state machine driving a single swap from offer-discovery through claim or refund. Persists state to local embedded KV store; resumes after crash; isolates concurrent swaps under independent state, escrow, and timelock tracking; tolerates Logos Delivery and Logos Chat unavailability gracefully (retry, buffering, degraded mode, all documented per R7).
4. Maker daemon + CLIs. Long-running Tokio-backed Rust daemon designed to run under Logos core daemon mode so the maker mini-app can remote-control it, with a standalone systemd-managed fallback for the period before that Logos capability ships, a maker CLI for operator control over a Unix-domain-socket JSON-RPC interface, a taker CLI for the end-user lifecycle. Pricing layer is a pluggable trait with two reference impls per F9 as amended by PR RFP-003: source external price feed from a Logos module C API #108: a local-config source (mode 1), and an external-feed adapter that sources prices from another Logos module via its C API (mode 2), with the specific module integration kept behind the plugin trait so alternative sources drop in without daemon changes.
5. Logos mini-app GUIs (maker, taker). Basecamp-loadable. We deliver clickable, interactive HTML prototypes first per S11 (the RFP asks for "Figma designs or equivalent") rather than static design mockups. The prototype is navigable and converges directly into the production mini-app, which is faster to produce and review than Figma. Downloadable assets and a git repo with local build instructions to follow.

How we read the LEZ side

PR #48 makes the LEZ-side picture clean. The escrow side is buildable today against logos-execution-zone main without protocol changes:

• BIP-340 Schnorr verification at the witness/auth layer (nssa/src/signature/, WitnessSet in nssa/src/public_transaction/witness_set.rs). The swap-claim state transition is gated on a WitnessSet carrying the completed adaptor signature; LEZ's existing protocol-level Schnorr check enforces that the signature is valid for the expected pubkey. The guest program inspects which pubkeys appeared in the validated witness and applies its own policy. Sufficient for both BTC ↔ LEZ adaptor swaps and the LEZ side of XMR ↔ LEZ. We do not need a secp256k1_schnorr_verify host syscall to do these swaps and we are not going to ask for one.
• BlockValidityWindow / TimestampValidityWindow (nssa/core/src/program.rs, exposed via ProgramOutput::with_block_validity_window() / …with_timestamp_validity_window()). The refund path's temporal-ordering argument lives here. We document the chosen Δ_lez parameters per pair and the inclusive/exclusive enforcement semantics they rely on.
• On-chain clock program (program_methods/guest/src/bin/clock.rs). Read for any in-program timing decision that cannot be expressed via the validity-window mechanism directly.
• SHA-256 in-guest (risc0_zkvm::sha::Impl::hash_bytes exposed through nssa/core/src/program.rs). Used for the ZEC-leg HTLC preimage path, kept consistent with the existing eth-lez-atomic-swaps reference impl, whose LEZ-side preimage logic carries over to the ZEC leg nearly unchanged.
• 2-of-2 AND-multisig at WitnessSet: handles the swap-claim signature-pair case natively. Threshold n-of-m is implementable in the guest on top of WitnessSet if any future RFP wants it, no syscall needed; this RFP does not need it.
• Validity-window enforcement on private transactions (nssa/src/privacy_preserving_transaction/message.rs). Important for any future privacy-mode swap variant; not needed for the Functionality requirements as written, but on our radar for the post-delivery roadmap.

The two open questions PR #48 calls out are both load-bearing for the protocol design. We resolve both in milestone 1, in writing, with reproducer tests, before any cryptography work starts:

• s-malleability of accepted signatures. Adaptor extraction relies on t = s − s' where s is the on-chain completed signature; if any layer (mempool, sequencer, witness normalisation) mutates s between submission and inclusion, the counterparty cannot recover the witness. Plan: source-trace the LEZ acceptance path from nssa/src/signature/ through to inclusion, then write a regression test that submits both s and −s mod n (or whichever malleation form is plausible from the trace) and asserts identical inclusion bytes. If LEZ does normalise s, the protocol falls back to a witness-form that does not depend on s-stability and the proposal write-up explains the choice.
• Validity-window enforcement timing. The refund-deadline ordering Δ_btc > Δ_lez + ε (and equivalently for XMR and ZEC) requires a clean answer to "is the upper bound enforced at sequencer admission, or only at validation". Same plan: source trace, then a regression test that pins the inclusive/exclusive semantics our timelock parameters depend on. Whichever semantics LEZ enforces, the timelock parameters absorb the slack rather than the protocol.

Both answers go into the public design write-up (S7) so future LEZ-application teams do not repeat the work.

Per-leg approach

ZEC leg (transparent-pool BIP-199 HTLC; ECDSA adaptor variant as a follow-on). Scoped to the Zcash transparent pool (t1... addresses), per the current RFP (Supportability 12 names "Zcash transparent HTLC scripts" as the reviewed artefact). The ZEC side is a BIP-199 hash time-locked contract; the LEZ side is the SHA-256 preimage claim path carried over from the eth-lez-atomic-swaps reference, since the LEZ escrow logic for an HTLC leg is chain-agnostic. The net-new work is Zcash node-side: transaction construction against the transparent pool via librustzcash / zcash_primitives, node orchestration, and testnet integration. The node choice (zcashd vs zebrad, factoring in the zcashd deprecation timeline and the current wallet-functionality split between the two) is decided and documented in milestone 1. The privacy posture is documented explicitly: a transparent-pool swap is fully public on-chain; the expected user pattern is shielding immediately after the swap completes, and the taker mini-app and documentation make that pattern first-class rather than a footnote. Shielded ZEC (Sapling / Orchard) stays out of scope: the cryptographic state of the art does not provide a drop-in adaptor-signature design for RedJubjub / RedPallas with per-spend re-randomisation, and treating shielded-pool atomic swaps as research-grade matches what every production Zcash swap path does today. An ECDSA adaptor-signature variant for the ZEC leg (a cross-chain-unlinkability upgrade over the HTLC) is held back as a paid follow-on rather than committed in headline scope.

BTC leg (Schnorr adaptor sigs + Taproot key-path). Schnorr adaptor signatures over secp256k1 with Taproot key-path spends (BIP-340 / BIP-341). The BTC-side keypair is jointly held; the LEZ side commits the adaptor witness as part of the WitnessSet validation. Reference libraries: secp256k1-zkp (adaptor support), secp256kfun / ecdsa-fun, rust-bitcoin for transaction construction. We follow the DLC-specs AdaptorSignature.md test vectors verbatim, extending with our own where the swap protocol introduces new scenarios (refund-path under partial counterparty action, concurrent-swap interleavings). The formal-security argument is stated in Aumayr et al. (2021) terms (aEUF-CMA, witness-extractability, pre-signature adaptability), so a security reviewer can audit against named definitions rather than ad-hoc claims. Lloyd Fournier's one-time-VES is read carefully and cited where it shapes a design choice.

XMR leg (Ed25519 adaptor sigs + cross-curve DLEQ). Ed25519 adaptor signatures with cross-curve DLEQ proofs between secp256k1 and Ed25519, following the h4sh3d / COMIT construction from the eprint paper. Atomicity is achieved by transferring a Monero spend-key share, with no on-chain script. Reference is comit-network/xmr-btc-swap (production) and comit-network/cross-curve-dleq for the DLEQ. monerod on stagenet, monero-wallet-rpc for orchestration. The genuinely subtle part of this protocol is the spend-key reconstruction failure-mode under partial information loss: what the protocol does when one party has the adaptor witness but the other has gone dark. We document the recovery path explicitly in the write-up (S7) and demonstrate it in the refund-timeout demo per D1.

Common cross-leg invariants. Taker-first on-chain ordering enforced at the protocol layer (R1). On-chain-only execution after lock: once the first on-chain action is submitted, the protocol does not depend on Logos Delivery or Logos Chat to complete (R2). Graceful degradation across chains (R3): the application starts and enables swaps for the available chains, reporting unavailable ones clearly. Independent state, escrow, and timelock per swap (R5). Timelock parameter rationale documented per chain (R6), including Zcash's ~75-second target block time and reorg characteristics in the Δ_zec derivation.

Maker daemon, CLIs, mini-apps. Tokio-backed Rust daemon, persistent state via sled or equivalent embedded KV store (final choice in milestone 1), CLI ↔ daemon over a Unix-domain socket with a small JSON-RPC surface, systemd unit shipped with installation steps (U2). Maker CLI configures pairs and prices, starts/stops the daemon, queries swap history, manually triggers claims or refunds (U3). Taker CLI covers the full taker lifecycle (U4). Mini-apps are TypeScript on the Basecamp toolchain; clickable HTML prototypes delivered before the production mini-app build (S11). Pricing-source plugin trait with two reference impls per F9 as amended by PR #108: local configuration, and a Logos-module C API feed adapter.

Anticipated challenges

1. Igor's M3 and M4 load as the applied-cryptography lead. M3 (around 1.13 ew per calendar week) and M4 (around 1.1 ew per calendar week) put Igor at full-time pace for nine consecutive weeks while his CTO and architect responsibilities remain in place. Mitigation: Igor's part-time M1, M2, M5, and M7 allocations are deliberately light so the M3-M4 window sits in a clear calendar; design review and code review on the other milestones is bounded to specific deliverable hand-offs rather than running concurrently with the cryptography work. If Igor's other CTO commitments shift unexpectedly during the engagement, Elliot's adjacent secp256k1 / precompile fluency lets him take review and pair-implementation hand-offs without breaking the milestone schedule.
2. Validity-window semantics. Resolved in milestone 1 in writing. If the answer comes back inconvenient (e.g. enforced only at validation rather than admission), our timelock parameters absorb the slack and the proposal write-up explains the trade-off.
3. s-malleability of accepted signatures. Same milestone 1 framing. If LEZ normalises s, the protocol falls back to a witness-form independent of s-stability. The write-up documents whichever path we take.
4. Zcash node landscape. zcashd is on a deprecation path in favour of zebrad, and wallet functionality currently sits unevenly between the two. We decide and document the node/wallet split in milestone 1 (deliverable, not a runtime surprise), and the node-setup documentation covers the chosen configuration plus the public-node alternative.
5. Transparent-pool privacy expectations. A ZEC leg added for privacy reasons but executed on the transparent pool needs its privacy posture stated plainly, or users will assume properties the swap does not have. We document the on-chain visibility of the swap and make the shield-after-swap pattern first-class in the taker flow and documentation. The current RFP scopes the reviewed artefacts to transparent HTLC scripts (Supportability 12), which we read as confirmation that transparent-pool execution is the intended scope; we will restate this understanding in the milestone 1 design write-up for the record.
6. Monero stagenet flakiness. Stagenet faucet outages historically eat days of integration-test time. We run a self-hosted stagenet monerod for CI and document the public-faucet path for users with a "your mileage may vary" caveat.
7. Concurrent-swap isolation under partial state loss. Crash-recovery semantics are easier to specify than to test. We fuzz the swap-coordinator state machine against simulated fault injection from milestone 5 onward, and the audit milestone (M7) covers the resulting state machine specifically.
8. SDK API ergonomics across three quite different protocols. A common trait surface across LEZ/BTC, LEZ/XMR, LEZ/ZEC that hides the cryptographic differences without hiding the failure modes is a real design call. We publish the SDK trait sketch as part of milestone 1 deliverables, in Logos-visible form, before committing to the implementation.
9. Compute-unit budget shifts during testnet. Per P1, "LEZ's per-transaction compute budget may change during testnet". The bid commits to documenting per-op CU cost against a stated testnet version, and to re-running the measurement at any LEZ testnet milestone where the budget changes.
10. Logos core daemon mode is not yet delivered. Per Logos review feedback the maker daemon should run under Logos core daemon mode so the maker mini-app can remote-control it, and that platform capability is not yet shipped. We design the daemon's control surface to that target from milestone 1, ship the standalone systemd path first (which satisfies every Usability and Reliability requirement on its own), and switch the mini-app to remote control over core daemon mode as soon as Logos delivers it, the same dependency-managed approach we take with the PR RFP-003: unblock atomic swaps, add LEZ primitive status #48 LEZ primitives.

Out-of-scope items we have noted

• ETH ↔ LEZ pair is out of scope per the July 2026 scope revision agreed with Logos (zkBridges preferred for ETH bridging). The eth-lez-atomic-swaps reference remains in use as the LEZ-side HTLC starting point for the ZEC leg. Because the SDK is one shared SwapProtocol trait plus per-pair impls, an ETH leg (HTLC via the Logos Ethereum module, or an adaptor-signature variant) can be added later as a paid follow-on without an SDK redesign, should Logos revisit.
• Zcash shielded (Sapling / Orchard) is out of scope. The swap runs on the transparent pool; rationale above.
• ECDSA adaptor-signature variant for the ZEC leg is held back as a paid follow-on rather than committed in headline scope (rationale above).
• Sandwich-attack mitigation is RFP-004 framing, not RFP-003; not applicable here regardless.
• Threshold n-of-m multisig as an LEZ protocol primitive is not needed for these swaps; implementable in-guest on WitnessSet if a future RFP wants it.
• In-guest secp256k1_schnorr_verify as a host syscall is explicitly not requested by this bid; the WitnessSet approach covers the requirements.

Milestones, Payout and Timeline

Proposed start date: Week of July 14th, or the first Monday following execution of the Grant Agreement, whichever is later.

Pricing methodology: engineer-week allocations below are concrete. Per-milestone USD payouts reflect named senior Gateway engineer time at blended rate (Igor's CTO and applied-cryptography-lead rate, Elliot and Ivan at senior-developer rate), frontend-contractor rate for M6, and an itemised third-party auditor fee in M7. Wall-clock duration assumes a partly-parallel schedule per the dependency graph below. Total Requested Budget = sum of milestone payouts = $296,000 all-in, including the third-party audit — below the $300K target agreed with Logos.

Wall-clock dependency graph:

M1 (3w, Igor lead)
   ├──→ M2 ZEC leg (4w, Elliot lead) ──┐
   ├──→ M3 BTC leg (4w, crypto lead)   ├──→ M4 XMR leg (5w, crypto lead) ──┐
   ├──→ M5 daemon/CLI (3w, Ivan)       │                                    │
   └──→ M6 mini-apps (3w, frontend)    └────────────────────────────────────┴──→ M7 audit + remediation (4w)

M2 and M3 run partly in parallel from week 2 of M2 onward (Elliot owns M2; the crypto lead and Ivan own M3). M4 is sequential after M3 because it shares the crypto lead. M5 and M6 can overlap each other and the tail of M4. Total wall-clock: around 19 weeks (within the RFP's 16 to 24-week window). Total Gateway engineer-weeks: around 46, plus auditor weeks in M7.

Milestone 1: Design, threat model, LEZ-primitive verification, SDK trait surface
Engineer-weeks: 6 (Igor 2.5 / Elliot 2 / Ivan 1.5)
Duration: 3 weeks
Payout: $24,500
Deliverables:

• Per-leg protocol design write-up covering BTC (Schnorr adaptor + Taproot), XMR (Ed25519 adaptor + cross-curve DLEQ), and ZEC (transparent-pool BIP-199 HTLC; ECDSA adaptor variant noted as follow-on), with cross-chain atomicity argument stated in Aumayr et al. terms (aEUF-CMA, witness-extractability, pre-signature adaptability) for the adaptor legs and a standard HTLC atomicity argument for the ZEC leg.
• LEZ escrow program design including SPEL IDL sketch and the chosen claim/refund path encoding for each pair.
• Threat model covering the adaptor-witness extraction path, the s-malleability path, the timelock-ordering path under each chain's worst-case confirmation latency (including Zcash block-time and reorg characteristics), the spend-key-share recovery path on XMR, and the transparent-pool visibility posture on ZEC.
• Written answer to the two PR RFP-003: unblock atomic swaps, add LEZ primitive status #48 open questions, with reproducer tests committed to the repo: s-malleability of accepted signatures; validity-window enforcement timing (admission vs. validation, inclusive/exclusive semantics).
• Zcash node/wallet decision (zebrad vs zcashd, factoring the deprecation timeline) documented with rationale.
• SDK trait surface published for Logos review (the common SwapProtocol trait + per-pair impl sketches) before implementation commits.
• Embedded KV store choice (sled vs. alternative) decided and justified.
• Maker-daemon integration design for Logos core daemon mode: the remote-control contract the maker mini-app uses to drive the daemon, with a standalone-daemon fallback specified for the period before that Logos capability is delivered (per Logos review feedback).

Milestone 2: ZEC-LEZ leg (transparent-pool HTLC)
Engineer-weeks: 6 (Elliot 4 / Igor 1 / Ivan 1)
Duration: 4 weeks (overlaps M3 from week 2 of M2)
Payout: $33,500
Deliverables:

• LEZ escrow program v1 deployed on testnet 0.2, supporting the ZEC leg's SHA-256 HTLC preimage path (carried over from the eth-lez-atomic-swaps reference) with BlockValidityWindow / TimestampValidityWindow for the refund.
• BIP-199 HTLC scripts and transaction construction on the Zcash transparent pool (librustzcash / zcash_primitives), with integration tests against Zcash testnet in CI.
• LEZ/ZEC SDK with full lifecycle coverage (offer discovery, negotiation, escrow creation, claim, refund).
• Step-by-step Zcash node setup documentation (chosen node per the M1 decision, plus the public-node option): configuration, wallet setup, obtaining testnet funds.
• Documented privacy posture: transparent-pool visibility and the shield-after-swap user pattern.
• ZEC demo set per D1: happy-path, refund/timeout, concurrent-swaps.

Milestone 3: BTC-LEZ leg
Engineer-weeks: 8 (Igor 4.5 cryptography lead / Ivan 3 / Elliot 0.5 review)
Duration: 4 weeks (overlaps M2 from week 2 of M2)
Payout: $45,500
Deliverables:

• LEZ escrow program update for the BTC adaptor-witness path (Schnorr + Taproot key-path spend, witness-set-gated claim).
• LEZ/BTC SDK with full lifecycle coverage.
• DLC-specs AdaptorSignature.md test-vector conformance, with extended vectors for the swap-specific scenarios.
• bitcoind testnet setup documentation per U8 (self-hosted + public-node options, configuration, wallet creation, obtaining testnet funds).
• BTC demo set per D1.
• Inline reference to Aumayr et al. and Fournier one-time-VES in the write-up.

Milestone 4: XMR-LEZ leg
Engineer-weeks: 10 (Igor 5.5 cryptography lead / Elliot 4 / Ivan 0.5 review)
Duration: 5 weeks (sequential after M3, same cryptography lead)
Payout: $58,000
Deliverables:

• LEZ escrow program update for the XMR cross-curve DLEQ claim path (Ed25519 adaptor + secp256k1 ↔ Ed25519 DLEQ).
• LEZ/XMR SDK with full lifecycle coverage including the Monero spend-key-share recovery path under partial information loss.
• DLEQ test-vector conformance against comit-network/cross-curve-dleq.
• monerod + monero-wallet-rpc stagenet setup documentation per U9.
• XMR demo set per D1.
• Self-hosted stagenet monerod running in CI.

Milestone 5: Maker daemon, CLIs, swap coordinator, fuzz harness
Engineer-weeks: 6 (Ivan 4 / Elliot 1.5 / Igor 0.5 review)
Duration: 3 weeks (overlaps M4 from week 3 of M4)
Payout: $30,500
Deliverables:

• Maker daemon (Tokio + Rust) runnable under Logos core daemon mode (remote-controllable from the maker mini-app), with a standalone systemd-managed fallback until that Logos capability is delivered, plus installation docs (U2).
• Maker CLI per U3 (configure pairs/prices, start/stop, query history, manual claims/refunds).
• Taker CLI per U4 (offer discovery, swap initiation, progress monitoring, claim/refund).
• Swap-coordinator state machine: persistence, crash recovery, concurrent-swap isolation per R4 / R5.
• Pluggable price-source trait per F9 as amended by PR RFP-003: source external price feed from a Logos module C API #108, with two reference impls: local configuration, and an external-feed adapter sourcing prices from another Logos module via its C API.
• Graceful Logos Delivery / Chat unavailability handling per R7, behaviour documented.
• Fuzz harness against the swap-coordinator state machine using cargo-fuzz or equivalent.

Milestone 6: Logos mini-app GUIs (maker + taker)
Engineer-weeks: 6 (frontend contractor 5 / Elliot 0.5 / Ivan 0.5)
Duration: 3 weeks (overlaps M5 from the design phase)
Payout: $18,000
Deliverables:

• Interactive HTML prototypes for both GUIs per S11 (the RFP's "Figma designs or equivalent"), signed off before the production build; delivered as clickable HTML that doubles as the mini-app's starting implementation.
• Maker mini-app per U5: pair / price configuration, active-swap monitoring, swap history.
• Taker mini-app per U6: offer browsing, swap initiation, progress monitoring, with the ZEC shield-after-swap pattern surfaced in the flow.
• Basecamp-loadable git repo for both, with downloadable assets and local-build instructions.

Milestone 7: Formal third-party review (S12 + S13), remediation, mainnet-readiness write-up
Engineer-weeks: 4 Gateway-side (Igor 1 / Elliot 1.5 / Ivan 1.5) plus around 3 auditor weeks
Duration: 4 weeks
Payout: $15,000 Gateway delivery plus $71,000 itemised auditor fee (3 auditor weeks at a representative adaptor-signature / cross-curve-DLEQ audit firm rate)
Auditor: TBD, mutually agreed with Logos. Gateway proposes Trail of Bits, Zellic, NCC Group, or another firm with documented adaptor-signature and cross-curve-DLEQ audit experience.
Deliverables:

• Per Supportability 12 — formal third-party review of all smart contracts and on-chain scripts: the LEZ escrow program (Rust, Risc0); the Bitcoin Taproot scripts and pre-signed transactions; the Zcash transparent HTLC scripts; and all other on-chain locking logic. Review report and resulting remediations included in the submission.
• Per Supportability 13 — formal third-party review of the cross-chain swap protocol implementation: the atomicity guarantees, taker-first ordering, timelock handling, and the per-chain adaptor-signature and HTLC constructions. Review report and resulting remediations included in the submission.
• Beyond the required scope, the review also covers the swap-coordinator state machine and the maker daemon's authentication and IPC surface.
• Remediation of all critical and high findings; documented decisions on medium and low.
• Mainnet-readiness write-up per S7 covering protocol design per chain, LEZ escrow design, cross-chain atomicity argument, timelock handling, security assumptions, known limitations, ops runbook.
• All hard-requirement tests green in CI on the default branch (S3 / S4).
• Doc packets per S9 (per-pair SDKs) and S10 (maker CLI, taker CLI), submitted via the logos-co/logos-docs template.

Total Requested Budget (USD)

All-in: $296,000, including the third-party audit — below the $300K target agreed with Logos.

Gateway delivery: $225,000

M1 $24,500 + M2 $33,500 + M3 $45,500 + M4 $58,000 + M5 $30,500 + M6 $18,000 + M7 $15,000.

Third-party formal review (S12 + S13): $71,000 (separate, itemised)

Can be contracted by Gateway as pass-through, or by Logos directly.

Based on internal discussions at Gateway, we are applying a cumulative discount of approximately 39% across all Gateway delivery milestones compared to the original offer. The third-party auditor fee is unchanged and remains pass-through.

The $71,000 auditor figure reflects 3 auditor weeks at a representative crypto-audit firm rate (the named shortlist sits in the $25,000 to $50,000 per-week range for engagements covering adaptor-signature constructions and cross-curve DLEQ proofs). Logos may prefer to contract the auditor directly, which is also fine. In that case the bid is $225,000 Gateway-side and Logos picks up the auditor fee separately.

On the scope change: the ZEC transparent leg replaces the ETH leg at the same milestone value. The two legs are comparable in effort — the ETH leg was a hardening pass over an existing reference plus Logos Ethereum module integration; the ZEC leg reuses that reference's LEZ-side HTLC path but adds net-new Zcash node-side plumbing and transaction construction on a chain with no prior reference in the repo. The remaining scope (BTC and XMR cryptography, coordinator, daemon, CLIs, mini-apps, formal review) is unchanged, so the total is unchanged.

The number reflects the scope and risk profile honestly: an XL-tier multi-chain cryptography deliverable with three live on-chain regimes (Schnorr/Taproot adaptor signatures on secp256k1, Ed25519 adaptor signatures with cross-curve DLEQ for XMR, BIP-199 HTLCs on the Zcash transparent pool), a Risc0 guest program, a fuzz-tested swap coordinator, a maker daemon, two mini-app GUIs, and a formal third-party review per Supportability 12 and 13.

Relevant Experience

• cdk-erigon: Polygon zkEVM execution client. Gateway is a major upstream contributor: Igor Mandrigin 545+ commits, Ivan Beliakov 230+ commits, Elliot Hallam 145+ commits. Direct evidence of porting battle-tested execution-environment logic into a constrained proof system, which is the same shape as the LEZ Risc0 escrow work.
• Erigon: Ethereum execution client. Igor Mandrigin is a co-author with 421+ commits to the canonical repo; daily-driver state DB, EVM interpreter, sync, RPC, gas-semantics, precompile work.
• Miden agglayer: proof-aware cross-VM bridging in production. Polygon Miden (STARK-based zkVM) bridged into Polygon's agglayer. Structurally adjacent to a Risc0 guest program that locks funds against off-chain witness reveals from a foreign chain.
• Full execution proofs with SP1 on agglayer-connected chains (Reth + Rust + SP1, including the SP1 prover): Gateway has shipped production Rust against SP1 (Succinct's RISC-V zkVM), including the prover side, to produce full block-level execution proofs for agglayer-connected chains running on Reth. Structurally the same shape as the Risc0 guest program required for the LEZ escrow side of this RFP: a RISC-V program proving foreign-VM state inside a proof boundary. This is the credential most directly transferable to the Risc0 guest-program work in M2 to M4.
• Open Privacy Suite: Gateway's privacy stack. Grounds credibility on the SDK-ergonomics layer where the swap protocol meets the shield/deshield patterns ZEC and LEZ users will use.
• Production L2 operations under Presto: sequencer ops, observability, oncall coverage at L2 scale. Grounds credibility on the maker-daemon supportability story.
• eth-lez-atomic-swaps reference familiarity: Gateway has read the reference implementation; the architecture and naming choices in this proposal reflect that, and its LEZ-side HTLC preimage path is the starting point for the ZEC leg.

Post-Delivery Plan

Maintenance for 12 months post-mainnet, in two tiers:

• Bug-fix tier (free). Gateway commits to fixing critical and high-severity bugs in the delivered code for 12 months at no cost. CVE-class findings are triaged within 48 hours and patched within an SLA agreed at delivery. Includes the LEZ escrow program, all three SDKs, the swap coordinator, the maker daemon, the CLIs, and the mini-apps.
• Feature / extension tier (paid). Additional pairs and variants — an ETH leg (HTLC via the Logos Ethereum module or an adaptor-signature variant) should Logos revisit the July 2026 scope decision; further EVM chains; the ECDSA adaptor-signature variant for the ZEC leg; a shielded-ZEC research track if the state of the art moves — plus SDK extensions and mini-app feature requests, scoped on a time-and-materials basis. Because the SDK is one shared SwapProtocol trait plus per-pair impls, each of these drops in without an SDK redesign.

The repository is owned by Logos from day one. Gateway is the named maintainer until the bug-fix tier expires; Logos may accept other maintainers at any time. A longer-term maintainer-of-record arrangement covering the swap protocol as a standard primitive on LEZ is a natural follow-on conversation; the bid does not assume it.

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.

[hackyguru]

This is a reiteration of #61 - proposal from Gateway

[hackyguru]

Thanks for the proposal @mandrigin and team, we are happy to accept the RFP proposal and move forward. Please have an eye on the indicated primary contact's email for the next steps :)