From 9c45e4a9797eae13d6551b4852e1fd6a0e10cc80 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 21 May 2026 18:34:25 +1000 Subject: [PATCH 01/17] rfp: cross-chain DEX and synthetic-XMR design bundle (decision drafts) Five decision-stage RFP drafts plus two background appendices. Each RFP captures one alternative in the cross-chain DEX design space so the Logos team and the community can compare and pick before specifying further. Scope of Work, FURPS hard requirements, team profile, timeline, and contracting details are deliberately omitted at this stage; the drafts focus on desired properties, high-level flow, and consistent Pros/Cons/Risks so the trade-offs are scan-comparable. New RFPs: - RFP-021: cross-chain privacy DEX (Serai-like federated middle layer). AMM-style liquidity, TSS custody, LEZ privacy primitives layered on top. Honest XMR caveat: view-key-shared TSS custody leaks Monero deposit history to validators. - RFP-022: bonded atomic swaps with two explicit tiers. Tier 1 (LEZ-BTC, LEZ-ETH): symmetric bonding via on-LEZ light-client inclusion proofs; full bilateral free-option mitigation. Tier 2 (LEZ-XMR): asymmetric because Monero has no SPV-style proof primitive without view-key disclosure. Bob bonded; Alice reputation-gated only on pre-XMR-lock free option. Bondless-taker capped-entry mechanic for onboarding without LEZ assets. - RFP-023: reputation as the bonding alternative. Maker reputation is publicly linkable. Taker reputation via either capped-pseudonym path or zk membership proofs (SMT of swap outcomes). Provides the reputation primitive consumed by RFP-022 and RFP-025. - RFP-024: synthetic XMR (sXMR), pure non-custodial design. Goal 1 from the sXMR design-space appendix. Oracle-priced, open LP set, soft peg, redemption via atomic swap to real XMR on Monero L1. - RFP-025: synthetic XMR (sXMR) with redemption SLA. Goals 2a and 2b together; applicants commit to one. Option 2a bonded LP set (consumes RFP-023 reputation for default attribution because atomic-swap state alone cannot adjudicate "LP defaulted"). Option 2b protocol XMR reserve (structurally an oracle-priced sBTC). New appendices: - appendix/cross-chain-trust-model-contrast.md: the federated-signers vs atomic-swaps trust analysis. Three mitigations for the atomic-swap free-option problem (same-asset bridge with the synthetic-token correction; bonded atomic swap with the two-tier framing for BTC/ETH vs XMR; reputation with the taker-linkability privacy tension). Bondless-taker capped-entry mechanic documented as cross-cutting. Primary sources only. - appendix/sxmr-design-space.md: Goal 1 / 2a / 2b property matrix, decision tree, pre-spec validation list, bottom-line table. Adapted from research-synthetics/rfp/appendix/sxmr-atomic-redemption.md with no em dashes and Australian English. Citation policy: primary sources only (Monero docs, FCMP++ research notes, COMIT/Farcaster references, Serai/Thorchain whitepapers, BIP references). No internal R&D documents cited. Co-Authored-By: Claude Opus 4.7 (1M context) --- RFPs/RFP-021-cross-chain-privacy-dex.md | 105 ++++++++ RFPs/RFP-022-bonded-atomic-swaps.md | 138 +++++++++++ RFPs/RFP-023-reputation-atomic-swaps.md | 148 ++++++++++++ RFPs/RFP-024-synthetic-xmr-pure.md | 117 +++++++++ RFPs/RFP-025-synthetic-xmr-sla.md | 183 ++++++++++++++ appendix/cross-chain-trust-model-contrast.md | 220 +++++++++++++++++ appendix/sxmr-design-space.md | 242 +++++++++++++++++++ 7 files changed, 1153 insertions(+) create mode 100644 RFPs/RFP-021-cross-chain-privacy-dex.md create mode 100644 RFPs/RFP-022-bonded-atomic-swaps.md create mode 100644 RFPs/RFP-023-reputation-atomic-swaps.md create mode 100644 RFPs/RFP-024-synthetic-xmr-pure.md create mode 100644 RFPs/RFP-025-synthetic-xmr-sla.md create mode 100644 appendix/cross-chain-trust-model-contrast.md create mode 100644 appendix/sxmr-design-space.md diff --git a/RFPs/RFP-021-cross-chain-privacy-dex.md b/RFPs/RFP-021-cross-chain-privacy-dex.md new file mode 100644 index 0000000..0b2a787 --- /dev/null +++ b/RFPs/RFP-021-cross-chain-privacy-dex.md @@ -0,0 +1,105 @@ +--- +id: RFP-021 +title: Cross-Chain Privacy DEX (Federated Middle Layer) +tier: XL +funding: $TBD +status: draft +category: Applications & Integrations +--- + +# RFP-021 — Cross-Chain Privacy DEX (Federated Middle Layer) + +> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos team and the community compare cross-chain DEX designs across RFP-021 through RFP-025. Hard requirements, team profile, timeline, and contracting details are deliberately omitted; they will be filled in if the design is selected for funding. + +## 🧭 Overview + +Build a cross-chain privacy DEX on LEZ that custodies external assets (BTC, ETH, XMR, and others) via a threshold signature scheme held by the LEZ validator set, executes swaps natively against an AMM, and adds LEZ-specific privacy primitives (shielded swap intents, sealed-bid batch matching, stealth outbound addresses) that the existing comparators (Thorchain, Serai, Maya, Chainflip) do not offer. + +The design follows the **federated-signer middle chain** pattern that Thorchain ($112B cumulative volume since 2021) and Serai (pre-mainnet, post-audit as of 2026-04) have converged on. RFP-021 inherits that pattern's well-understood AMM-style liquidity and one-step user experience, then layers LEZ's privacy execution primitives on top to close the privacy gap that every comparator leaves open: even Serai's middle-chain state is publicly readable, and Thorchain's source-chain memos link source and destination addresses on transparent ledgers before the middle chain even sees them. + +This is the most ambitious option in the cross-chain bundle. It is also the one with the strongest empirical case (volume, user experience, asset coverage) and the strongest custody risk. + +## Desired properties + +- **Native cross-chain swap.** User deposits BTC, ETH, or XMR; receives the destination asset on the destination chain in a single user action. No wrapped tokens linger on LEZ after the swap. +- **AMM-style liquidity.** A single ordered state machine maintains pool invariants (`xy=k` or comparable). Large swaps clear against pooled liquidity, not against a per-trade counterparty. +- **One-step UX.** Deposit-with-memo, await outbound. No counterparty interactivity, no refund flows, no online-availability requirement past broadcast. +- **Bonded validator set with slashable misbehaviour.** Validators stake against the assets they custody; the bond-to-custodied-value ratio is enforced in protocol (Serai uses a 33% custody cap; Thorchain uses 2:1 bonded plus 1:1 pooled). +- **LEZ-native privacy execution.** Shielded swap intents (the user's swap is a commitment, not a public memo); sealed-bid batch matching with threshold decryption (collapses identity-based front-running); stealth outbound addresses on destination chains (breaks destination-chain clustering even for chains with no native privacy). +- **Permissioned-by-stake but censorship-resistant.** Anyone can join the validator set by posting the required stake; validator-set rotation occurs on a known cadence (Thorchain churns every 3 days; Serai per session). +- **Emergency halt mechanism.** Used three times in Thorchain's history; the protocol must be able to freeze outbounds on suspected custody compromise or consensus fault. + +## High-level functionality and flow + +``` + LEZ validator set (~100-600 nodes, bonded) + FROST threshold signatures per external curve + + + ETH vault BTC vault XMR vault + (secp256k1) (secp256k1) (Ed25519, FROSTLASS over CLSAG) + + AMM pools on LEZ + (xy=k, native asset settlement) + + + Privacy layer: + - shielded swap intents + - sealed-bid batch matching + - stealth outbound addresses + - Waku transport for orderflow +``` + +**Happy path.** User sends BTC to a vault address on Bitcoin, carrying a memo (or, with LEZ privacy primitives, a commitment) that specifies the destination asset and address. LEZ validators observe the deposit, reach consensus via their consensus protocol, route the swap through the appropriate AMM pool, queue the outbound, and the threshold signature group co-signs an outbound transaction on the destination chain. Outbound is broadcast to a stealth address derived from the destination address. Total wall-clock time: source-chain finality plus LEZ consensus plus destination-chain finality, typically minutes. + +**Validator-set churn.** On a fixed cadence, the protocol runs a distributed key generation for the next validator set and migrates vault balances from old keys to new keys. New validators bond their stake; departing validators recover their bond after a vesting period. + +**Misbehaviour path.** Failed keygen, failed keysign, observed double-spend attempts, or chain-attributable malfeasance trigger slashing of the responsible validator's bond. Slashing amounts and trigger conditions are protocol-defined. + +**Emergency path.** A `halt` mechanism (Thorchain's `make halt` precedent; Serai uses session-level rollback during DKG failure) freezes outbounds on suspected solvency or signing failure. + +## Pros + +- **Highest deployed-volume model.** Thorchain has cleared $112B cumulative cross-chain volume since 2021 ([DefiLlama Thorchain DEX](https://defillama.com/protocol/thorchain-dex)). The AMM-style middle-chain pattern wins on liquidity gravity and user experience over every atomic-swap competitor. +- **Sub-block-time settlement on the middle chain.** Only destination-chain finality and the TSS keysign delay the outbound. No multi-hour timelock windows. +- **Arbitrary asset pairs.** Pair coverage is reduced to "does the validator set run an observer for chain X". BTC, ETH, XMR all in scope at launch. +- **Cryptoeconomic recourse.** Misbehaviour is slashable. The economic security argument is explicit and bounded. +- **LEZ privacy execution is a real differentiator.** No comparator offers shielded swap intents, sealed-bid batch matching, or stealth outbound addresses. This is the precise gap LEZ can fill. +- **Composable with the rest of LEZ.** The protocol-owned vault assets can back lending markets, structured products, and so on, on the same LEZ. + +## Cons + +- **Custody risk is real and realised.** Thorchain's GG20 TSS vault was drained in May 2026 ($10.8M) via a TSSHOCK-class implementation weakness. Wormhole's Solana bridge was drained in February 2022 ($326M) via a per-chain contract bug; Jump Crypto re-deposited the loss out of pocket. The federated middle-chain pattern has a non-zero historical loss rate. +- **Signer federation is a chokepoint.** Validators are identifiable; the validator set is a target for out-of-protocol pressure (legal, regulatory, kinetic). The federation cannot be made "fully decentralised" in the sense that an atomic-swap design can. +- **Pre-economic-security bootstrap.** Serai's mint-on-bootstrap design illustrates that the slashable-bond argument does not bind until the validator-stake pool catches up with custody. The launch window is a real risk. +- **XMR privacy compromise.** Any TSS custody of Monero is necessarily view-key-shared: the validator set learns the LEZ-side Monero deposit history. This is the same compromise Serai accepts (FROSTLASS over CLSAG); it must be called out plainly to users, not papered over. +- **Engineering surface is large.** Building a new chain, a per-external-chain observer fleet, a TSS scheme with serious audit posture, churn/migration logic, and an emergency halt is a multi-year programme. Serai took roughly six years from inception to post-audit pre-mainnet. + +## Risks + +- **TSS implementation failure.** The May 2026 Thorchain incident is the canonical example. Mitigation: choose FROST over GG20 (Serai's choice, and the lesson Thorchain's incident reinforces); budget for at least one Cypher Stack-equivalent audit of the chosen scheme; design with FROSTLASS-grade Monero support from the start rather than retrofitting. +- **Per-external-chain contract risk.** Wormhole's 2022 incident bypassed rather than broke the trust model: a Solana-side `load_instruction_at` bug let an attacker forge VAAs. Every integrated chain adds an attack surface independent of the LEZ consensus. Mitigation: minimise per-chain on-chain components; lean on TSS-signed outputs to chains with no LEZ-deployed contract. +- **Validator-set capture.** A small or homogeneous validator set is a censorship and coercion target. Mitigation: stake-weighted permissionless entry; geographic and jurisdictional diversity as a soft target. +- **Pre-mainnet economic-security gap.** Slashable-bond security depends on stake value catching up with custody value. Mitigation: explicit caps on custody until the bond-to-custodied ratio binds; transparent on-protocol ratio enforcement (Thorchain's Incentive Pendulum is one mechanism). +- **Regulatory exposure on XMR custody.** Holding XMR in a protocol-owned vault attracts more scrutiny than holding BTC. Mitigation: validator geographic diversity; documented privacy posture; clear separation between protocol governance and individual validator entities. +- **Privacy claim overreach.** The LEZ privacy primitives close the public-ledger linkability gap but do not protect against an honest-but-curious validator set. The threat model must be documented honestly so users do not assume "private" means "the validators learn nothing". + +## Relationship to other RFPs in this bundle + +- **RFP-003 (Atomic Swaps with LEZ, open)** is the baseline atomic-swap RFP. RFP-021 is the structural alternative: federated middle layer instead of bilateral atomic swap. The two coexist: RFP-021 handles the high-liquidity bulk path; RFP-003 (and its evolutions RFP-022 and RFP-023) cover the non-custodial niche. +- **RFP-004 (Privacy-Preserving DEX, open)** is a *single-chain* shielded DEX on LEZ. RFP-021 is *cross-chain* with vault custody. Distinct scopes; the two could ship in parallel and serve different user journeys (intra-LEZ shielded trading vs cross-chain settlement). +- **RFP-022 (bonded atomic swaps)** and **RFP-023 (reputation-based atomic swaps)** are the non-custodial alternatives. They preserve cryptographic non-custody at the cost of multi-hour settlement and counterparty interactivity. RFP-021 sacrifices non-custody for AMM-style liquidity and one-step UX. The Logos design space is broad enough to ship both modes. +- **RFP-024 (sXMR pure)** and **RFP-025 (sXMR with SLA)** target a different product: synthetic XMR exposure inside LEZ DeFi, with atomic-swap redemption to real XMR. They are orthogonal to RFP-021 and could ship alongside it, sharing the same LEZ privacy primitives. + +See [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) for the full federated-signers vs atomic-swaps trust analysis that motivates this RFP's place in the bundle. + +## References + +- [DefiLlama Thorchain DEX (volume figures)](https://defillama.com/protocol/thorchain-dex) +- [Serai AMM docs](https://docs.serai.exchange/amm/) +- [Serai blog: Announcing monero-oxide (2025-09-09)](https://serai.exchange/2025/09/09/monero-serai-oxide.html) +- [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md) +- [Thorchain Medium: Why Cross-Chain bridges are superior to Atomic Swaps (2019)](https://medium.com/thorchain/why-cross-chain-bridges-are-superior-to-atomic-swaps-aebde263103c) +- [Thorchain docs: Continuous Liquidity Pools](https://docs.thorchain.org/technical-documentation/thorchain-finance/continuous-liquidity-pools) +- [Crypto Times: $10.8M drained from Thorchain (2026-05-17)](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) +- [Halborn: Wormhole Hack February 2022](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) +- [FROST paper (Komlo and Goldberg)](https://eprint.iacr.org/2020/852) diff --git a/RFPs/RFP-022-bonded-atomic-swaps.md b/RFPs/RFP-022-bonded-atomic-swaps.md new file mode 100644 index 0000000..3e068fd --- /dev/null +++ b/RFPs/RFP-022-bonded-atomic-swaps.md @@ -0,0 +1,138 @@ +--- +id: RFP-022 +title: Bonded Atomic Swaps (Two Tiers) +tier: XL +funding: $TBD +status: draft +category: Applications & Integrations +--- + +# RFP-022 — Bonded Atomic Swaps (Two Tiers) + +> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos team and the community compare cross-chain DEX designs across RFP-021 through RFP-025. Hard requirements, team profile, timeline, and contracting details are deliberately omitted; they will be filled in if the design is selected for funding. + +## 🧭 Overview + +Extend RFP-003 (Atomic Swaps with LEZ, open) with a maker/taker bond layer on LEZ that constrains the free-option problem inherent to atomic swaps. Bonds are posted on LEZ in stables or LEZ-native assets; slashing is conditioned on LEZ-observable failures to advance through the swap state machine. + +The design splits into two tiers that reflect a structural asymmetry in the underlying cryptography: + +- **Tier 1 (LEZ to BTC, LEZ to ETH).** Both sides' locks are verifiable on LEZ via a chain-watching light-client module. Both Alice's and Bob's bonds are slashable on default; full bilateral free-option mitigation. +- **Tier 2 (LEZ to XMR).** Alice's XMR lock cannot be proven on LEZ without view-key disclosure to public state, because Monero has no SPV-style proof primitive that does not reveal the per-tx private key and blinding factor. Bob's lock (on LEZ) remains observable, so Bob's bond is slashable; Alice's bond is slashable only on her LEZ-observable abandonment (failure to reveal after Bob has locked Logos). Alice keeps a residual pre-XMR-lock free option that only reputation (RFP-023) can constrain. + +The Bond layer is a strict superset of RFP-003. Builders should consume the per-pair SDKs from RFP-003 unchanged; this RFP adds the bond escrow contract, the bond accounting, and the LEZ-side proof verification primitives. + +## Desired properties + +- **Non-custodial.** No vault holds external assets; no signer set. Bonds live in LEZ-native assets on LEZ. +- **Free-option mitigation (Tier 1).** Symmetric bonding makes both sides' optionality strictly EV-negative when bonds are sized above the option value (`σ × √T × notional`, around 2 to 5% of trade notional for 1-hour windows). +- **Free-option mitigation (Tier 2).** Bob's optionality is closed by his slashable bond. Alice's post-Bob-lock optionality is closed by her bond. Alice's pre-XMR-lock optionality is *not* closed; this is the structural limit of the asymmetry. +- **Unauthenticated proof submitter.** Either party can broadcast the other's signed lock transaction (broadcasting is permissionless on every supported chain). The LEZ inclusion-proof submitter is also unauthenticated. This eliminates "attest or be slashed" grief vectors: a malformed lock simply never lands, the state machine times out, no slashing dispute occurs. +- **Bondless taker entry path.** First-time takers can complete a capped first swap (worked example: US$100 equivalent notional) without posting a taker bond. After the first swap, the taker has LEZ-denominated assets they can post as bond against larger swap sizes. This is enforceable by the LEZ escrow program directly; no reputation registry needed. +- **Upgrade clause for Tier 2.** When a non-disclosing Monero proof primitive becomes production-ready (FCMP++ or equivalent), Tier 2 collapses into Tier 1: Alice's XMR lock becomes verifiable on LEZ without view-key disclosure, and the residual free option closes. +- **Composes with RFP-023 reputation.** Maker reputation (and zk-membership-proof taker reputation if available) compounds the cost of defection. In Tier 2 specifically, taker reputation is load-bearing because it is the only restraint on Alice's pre-lock free option. + +## High-level functionality and flow + +### Tier 1: LEZ to BTC (example) + +``` +Phase Alice LEZ contract Bob + +0. Quote <----------- Logos Delivery ----------> + Joint-key setup for 2-of-2 Taproot output + +1. Commit post B_alice + (LEZ-side bond) --> receives B_alice + +2. Lock-BTC sign BTC lock tx --> over Waku --> broadcast to BTC + + <-- inclusion proof from anyone --> verifies PoW, merkle, scriptpubkey, amount + + slash window opens if Bob does not advance: + B_bob_slice goes to Alice + +3. Lock-Logos (waits) <-- receives Bob locks trade_amount + trade_amount + + B_bob_slice + B_bob_slice conditioned on secret s + +4. Reveal publishes adaptor sig --> reveals s + if Alice does not reveal: + B_alice goes to Bob + +5. Settle <-- Alice's bond Bob claims BTC using s + refunds + Bob's bond slice + releases +``` + +The unauthenticated proof submitter property: Bob can broadcast Alice's signed BTC lock himself; the LEZ inclusion-proof submitter is also unauthenticated (Bob, Alice, or a watchtower service can post the proof). If Alice signs a malformed lock (wrong amount, wrong scriptpubkey), Bob does not broadcast; the tx never lands on Bitcoin; the inclusion proof never materialises; the LEZ state machine quietly times out. No slashing dispute, no fraud-proof window. The swap fails closed because the precondition for state advancement (a real BTC lock) never holds. + +### Tier 2: LEZ to XMR + +Same phase structure, with the following differences: + +- Phase 2 (Lock-XMR): Alice's XMR lock is *not* verifiable on LEZ. The state machine cannot transition from Commit to Lock-Logos based on observation of Alice's Monero lock. Bob detects Alice's lock by running a Monero wallet himself (the bilateral `check_tx_proof` she sends him privately, which does *not* go on LEZ). Bob's decision to advance to Lock-Logos is off-chain. +- If Alice never locks XMR after Commit, the state machine times out; both bonds refund (no LEZ-observable default). Alice has paid only gas; she keeps her pre-XMR-lock free option. +- Phase 3 onwards: Bob's lock on LEZ is observable. From this point forward, Tier 2 matches Tier 1: Alice's bond is slashable on failure to reveal; Bob's bond is slashable on failure to complete after the reveal. + +### Bondless taker entry path + +A taker without LEZ-denominated assets initiates a "first-swap" mode flagged in the LEZ escrow program: + +- Trade notional capped at a small value (worked example: US$100 equivalent), sized against expected free-option value at the protocol's typical lock window. +- No taker bond required. +- After completion, the taker has LEZ-denominated assets in their account from the swap proceeds. They can post these as bond against subsequent larger swaps. +- The cap is enforced by the LEZ escrow program; no reputation registry is required to make the cap binding. This decouples the bondless entry path from the (more complex) reputation infrastructure in RFP-023. + +## Pros + +- **Closes the free-option problem cryptoeconomically for BTC and ETH (Tier 1).** No bilateral counterparty trust, no third-party attestation, no validator federation. The slash is enforced by the LEZ smart contract directly off the on-chain state of both chains. +- **Preserves the non-custodial property of atomic swaps.** No vault to drain, no TSS to break, no validator set to compromise. Funds never leave Alice's or Bob's control during the swap. +- **Builds cleanly on RFP-003.** Per-pair SDKs and the LEZ-side Risc0 escrow programs from RFP-003 are reused; this RFP layers on the bond escrow and the proof verification primitives. The dependency chain is clean. +- **Material improvement for the LEZ to XMR pair (Tier 2) on the maker side.** Bob's free option is closed even though Alice's lock is not verifiable on LEZ. This unblocks a category of makers who today refuse to post against atomic-swap takers because they can be free-optioned. +- **Bondless taker entry path solves the onboarding chicken-and-egg.** A privacy-seeking taker arriving from XMR or BTC does not need to acquire LEZ assets before their first swap. They complete a small first swap, accumulate LEZ assets, and bond from there. No KYC-tolerant on-ramp required. +- **Upgrade-clean for FCMP++.** When the non-disclosing Monero proof primitive ships, Tier 2 collapses into Tier 1 with no protocol-level rewrite. The RFP carries an explicit upgrade clause. + +## Cons + +- **Does not fix settlement time.** Settlement is still bounded by source-chain finality plus LEZ finality plus the timelock window. Hours, not minutes. The bond does not accelerate cryptographic settlement. +- **Does not fix interactivity.** Both parties must be online to lock, reveal, and (if the other side defaults) submit the slash claim. The bond removes the incentive to grief but not the requirement to participate. +- **Per-trade matching, no AMM.** No protocol-owned liquidity, no AMM pricing. Each swap requires a willing counterparty for the exact pair and exact size. RFP-021 wins decisively on liquidity gravity. +- **Bond opportunity cost.** Makers must lock LEZ-denominated bond capital, which yields nothing during the lock window. This raises maker spreads relative to the unbonded (free-option) atomic swap of RFP-003. +- **Bond denomination friction.** First-time takers need LEZ-denominated bond assets. The bondless-taker capped-entry path mitigates this but only for the first swap. +- **Tier 2 is structurally weaker.** Alice retains a pre-XMR-lock free option on the LEZ to XMR pair. Reputation (RFP-023) is the only available restraint on this option under current Monero cryptography. Users must understand the asymmetry. +- **More complex than RFP-003.** Bond accounting, slash conditions, light-client modules, dispute windows. The protocol surface and audit surface both grow. + +## Risks + +- **Cross-chain bond correlation.** If Bob is matched against N concurrent swaps and the LEZ chain re-orgs or his observer crashes, all N swaps may slash him. Mitigation: per-maker concurrency caps; bond scaling with active-swap count; explicit re-org tolerance windows. +- **Light-client implementation risk (Tier 1).** The BTC and ETH light-client modules are the load-bearing primitive. A bug that lets an attacker submit a false inclusion proof is a direct theft vector. Mitigation: fork from well-audited references (ZeroSync, Citrea Clementine LCP for BTC; Nimbus-derived for ETH); independent audit budget. +- **Bond sizing parameter risk.** Bond too small leaves residual optionality; bond too large prices honest makers out of the market. Volatility regime changes (e.g. XMR price moves of 20% in a session) widen the option value. Mitigation: protocol-adjustable bond parameters; optional volatility-indexed bond sizing. +- **Adversarial bond-bootstrap attack.** An attacker who controls the first set of makers can credibly claim "reputation-rich" status and capture taker flow. Mitigation: combine bond requirements with reputation accrual (RFP-023) so reputation cannot be purchased without time-and-capital cost. +- **FCMP++ upgrade slippage (Tier 2).** If the non-disclosing Monero proof primitive does not ship on the expected horizon, Tier 2 remains permanently asymmetric. Mitigation: design the protocol assuming Tier 2 is the steady state; treat FCMP++ as an optional improvement, not a dependency. +- **First-swap cap evasion.** A taker could split a large trade into many capped first swaps under fresh pseudonyms. Mitigation: cap by IP, device fingerprint (weak), or by Sybil-resistant identity proof (stronger); combine with rate limits enforced at the LEZ escrow program. + +## Relationship to other RFPs in this bundle + +- **RFP-003 (Atomic Swaps with LEZ, open)** is the foundation this RFP extends. The per-pair SDKs (LEZ-BTC, LEZ-XMR, LEZ-ETH), the Risc0 LEZ-side escrow, and the custom-LEZ-token support (RFP-003 hard requirement 7) are dependencies. RFP-022 layers bond escrow, slash conditions, and chain-watching light-client modules on top. +- **RFP-021 (cross-chain privacy DEX)** is the federated-custody alternative. RFP-021 sacrifices non-custody for AMM liquidity and one-step UX; RFP-022 sacrifices liquidity gravity for non-custody. The two coexist in a complete cross-chain DEX strategy. +- **RFP-023 (reputation-based atomic swaps)** is the bonding alternative. RFP-022 consumes the maker-reputation primitive from RFP-023; in Tier 2 specifically, the taker-reputation primitive is the only restraint on Alice's residual pre-XMR-lock free option. If RFP-023 ships later, RFP-022 specifies a stub interface and degrades to "count of completed swaps" reputation in the interim. +- **RFP-024 (sXMR pure)** and **RFP-025 (sXMR with SLA)** are orthogonal. They target synthetic XMR exposure inside LEZ DeFi; this RFP targets real-asset atomic swaps. They could be deployed alongside. + +See [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) for the full mitigation-2 design analysis and the impossibility argument for the LEZ to XMR Tier 2 asymmetry. + +## References + +- [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) +- [eth-lez-atomic-swaps reference implementation](https://github.com/logos-co/eth-lez-atomic-swaps) +- [Bitcoin to Monero atomic swaps (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) +- [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) +- [Adaptor signatures, Lloyd Fournier](https://github.com/LLFourn/one-time-vrf/blob/master/main.pdf) +- [Scriptless Scripts, Andrew Poelstra](https://github.com/apoelstra/scriptless-scripts) +- [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) +- [Citrea Clementine LCP](https://citrea.xyz/learn/clementine) +- [ZeroSync](https://zerosync.org/) +- [Monero whitepaper: Zero to Monero 2.0](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) +- [Monero FCMP overview](https://www.getmonero.org/resources/moneropedia/fcmp.html) diff --git a/RFPs/RFP-023-reputation-atomic-swaps.md b/RFPs/RFP-023-reputation-atomic-swaps.md new file mode 100644 index 0000000..ed90f95 --- /dev/null +++ b/RFPs/RFP-023-reputation-atomic-swaps.md @@ -0,0 +1,148 @@ +--- +id: RFP-023 +title: Reputation-Based Atomic Swaps (Bonding Alternative) +tier: XL +funding: $TBD +status: draft +category: Applications & Integrations +--- + +# RFP-023 — Reputation-Based Atomic Swaps (Bonding Alternative) + +> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos team and the community compare cross-chain DEX designs across RFP-021 through RFP-025. Hard requirements, team profile, timeline, and contracting details are deliberately omitted; they will be filled in if the design is selected for funding. + +## 🧭 Overview + +Extend RFP-003 (Atomic Swaps with LEZ, open) with an on-chain reputation registry that constrains the free-option problem inherent to atomic swaps, *without* requiring bonded collateral as the primary cost-of-defection. + +The premise: a maker who has completed N successful swaps with zero defections has built up a reputation asset whose net present value (discounted future fee revenue) exceeds the expected value of any single grief attack. The protocol does not need to slash bonded collateral; the *market* effectively slashes the maker by refusing future trades. Reputation is therefore a long-tailed bond the protocol does not have to size, hold, or directly enforce. + +The cryptographic challenge is taker reputation. Takers should be unlinkable across swaps (a privacy-positioned cross-chain DEX should not require its users to maintain a persistent on-chain identity that can be deanonymised). The RFP requires applicants to address two complementary design paths: a capped-pseudonym path (linkable, simple) and a zero-knowledge reputation path (unlinkable, complex, reusing the LEZ Risc0 zkVM that RFP-003 already establishes). + +Reputation as a primitive is consumed by other RFPs in the bundle: RFP-022 (bonded atomic swaps) uses maker reputation to compound the cost of defection on top of bonded collateral; RFP-025 (sXMR with SLA, option 2a) uses LP reputation as the attestation layer for default attribution (because "LP defaulted" cannot be rendered from atomic-swap state alone, per the cross-cutting analysis in the trust-model contrast appendix). + +## Desired properties + +- **Maker reputation primitive.** A registry on LEZ that tracks per-maker (count of completed swaps, slash history, time-in-protocol, total fee revenue, optional liveness signals). Public read; write access gated by the LEZ atomic-swap escrow program. +- **Taker reputation primitive with privacy options.** Two paths the RFP requires applicants to consider and ship at least one of: + - **Capped anonymous takers.** First-swap takers are size-capped (worked example: US$100 notional). Cap relaxes after N successful completions under the same persistent pseudonym. Linkability is opt-in: a taker who wants larger size accepts linkability as the cost. + - **Zero-knowledge reputation.** Takers prove "I have completed at least N swaps with zero slashes" without revealing *which* swaps, via a Sparse Merkle Tree of swap outcomes maintained by the LEZ escrow program plus a zk membership proof generated by the taker. Preserves unlinkability across swaps while letting the taker borrow against accumulated reputation. +- **Sybil-resistance by accrual rate.** Reputation accrual is rate-limited by completed-swap throughput and per-pseudonym notional caps, so spinning up fresh identities is bounded by the cost of N honest swaps over the accrual window. +- **No protocol-held bond required for the core design.** The reputation asset is the cost of defection; the protocol does not custody slashable collateral as a precondition of participation. Bonds can be layered on top (per RFP-022) but are not the load-bearing mechanism here. +- **Bootstrap path.** Reputation has zero value at launch. The protocol must specify a bootstrap path: a combination of bondless capped entry (same mechanic as RFP-022's first-swap cap) and RFP-022 bonds for early adopters, transitioning to reputation-only as reputation accrues. +- **Maker exit.** A maker can withdraw from the protocol by transferring their identity (selling the reputation as an asset, if the registry permits) or by abandoning it (accepting reputation loss). Reputation is not refundable. + +## High-level functionality and flow + +### Maker reputation + +``` + LEZ escrow program (RFP-003) + + reputation registry (RFP-023) + + + Maker ----> register identity (one-time) + (deposit small registration fee) + + + per swap: + - escrow program records outcome (success / slash) on maker identity + - reputation field updates atomically with swap settlement + + Taker ----> query registry by maker identity + inspect (count, slashes, time, fee revenue) + decide whether to swap +``` + +Maker identity is a persistent on-chain pseudonym, publicly readable. Makers want this property: it lets them receive quote requests over Logos Delivery, accumulate fee revenue, amortise gas, and signal trustworthiness. Reputation as a public good for makers maps cleanly to the existing maker daemon shape in RFP-003. + +### Taker reputation: capped-pseudonym path + +``` + Taker ----> generate persistent pseudonym (Pi) + + + first swap under Pi: + - LEZ escrow enforces notional cap (e.g. US$100) + - on success, escrow increments completed-swap count on Pi + + later swaps under Pi: + - notional cap relaxes by formula (e.g. tier 1: $500 after 5 swaps; + tier 2: $5000 after 20; tier 3: unbounded after 50) + - linkability across swaps is intrinsic to using the same Pi +``` + +Trade-off: simple to implement and easy for users to reason about. But large-volume takers expose a linkable identity across all their swaps; an adversary who profiles makers can deanonymise large traders' patterns. + +### Taker reputation: zero-knowledge path + +``` + Taker ----> generate ephemeral pseudonym for each swap + + + on each completed swap: + - LEZ escrow inserts a swap-outcome leaf into a Sparse Merkle Tree + (SMT) keyed by a taker-side commitment H(secret_i || swap_id_i) + - taker holds the secret_i needed to re-prove membership + + later swaps: + - taker generates a zk membership proof: "I have at least N + leaves in the SMT with outcome=success and zero leaves with + outcome=slash, without revealing which leaves" + - escrow program verifies the proof and unlocks the corresponding + notional cap tier +``` + +Trade-off: preserves unlinkability across swaps (the taker uses a fresh pseudonym per swap, joined only by the zk proof of accumulated reputation). Engineering-expensive: requires a circuit-friendly execution layer on LEZ (the Risc0 zkVM from RFP-003) and careful side-channel analysis. Reuses the same proof infrastructure RFP-021's shielded swap intents and RFP-004's private-account pattern depend on. + +### Reputation primitive consumed by other RFPs + +- **RFP-022** consumes the maker reputation primitive to compound cost of defection above the bond. In Tier 2 (LEZ to XMR) specifically, the taker reputation primitive is the only restraint on Alice's pre-XMR-lock free option (because her XMR lock cannot be proven on LEZ). +- **RFP-025** option 2a (bonded LP set) consumes LP reputation as the default-attribution layer, because "LP defaulted" is not a verdict an on-chain program can render from atomic-swap state alone (per the cross-cutting analysis in [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md)). + +## Pros + +- **No protocol-held bond required for the core mechanic.** Capital efficiency is highest among the free-option mitigations: no LEZ-denominated bond locks up maker capital during swap windows. +- **Scales with maker career.** Reputation accrues over many swaps; a maker who has completed 10,000 swaps has a far larger implicit bond than any reasonable explicit bond size. The mechanism strengthens as the protocol matures. +- **Closer to the cypherpunk "no third-party trust" ideal than RFP-022.** No bond escrow contract holds funds; no LEZ-side slashing logic enforces collateral forfeit. The only on-chain artefact is the reputation registry, which records outcomes but does not custody assets. +- **Composable with bond designs.** RFP-022 can layer reputation on top of bonds for compounded defection cost. The two are not exclusive. +- **Unlinkable taker reputation is genuinely novel.** The zk membership proof path, if shipped, is one of the first deployable instances of "I have reputation but you cannot tell which swaps built it". The privacy positioning of Logos benefits directly. +- **Solves the LEZ to XMR Tier 2 gap (with RFP-022).** Where RFP-022 alone leaves Alice with a pre-XMR-lock free option, RFP-023 taker reputation constrains it by making defection cost reputation rather than collateral. + +## Cons + +- **Bootstrap problem is real.** At launch, reputation has zero value, so the first cohort of swaps has the strongest free-option exposure. The protocol must combine reputation with bondless caps (this RFP) plus optional RFP-022 bonds for the bootstrap phase. The early protocol experience is worse than the steady-state. +- **Zero-knowledge path is engineering-expensive.** Circuit design, side-channel analysis, audit, and ongoing performance work. The capped-pseudonym path is simpler but exposes linkability. +- **Sybil mitigation requires careful parametrisation.** If the per-pseudonym accrual rate is too generous, attackers can mint reputation cheaply. If too restrictive, honest takers cannot accumulate reputation fast enough to access the trade sizes they need. +- **Maker reputation does not protect against first-time defection.** A new maker with zero reputation can grief and walk away at no reputation cost. The first swap any taker does with any new maker is unprotected. Mitigation: combine with RFP-022 bonds during the maker's reputation-building phase. +- **Reputation transfer mechanics are governance-sensitive.** If reputation is transferable (a maker can sell their identity), an attacker can purchase a high-reputation identity and grief immediately. If non-transferable, maker exit is painful (no salvage value). Both directions require careful policy. +- **Maker reputation is publicly linkable, by design.** This is the right trade-off for the maker role (they want a persistent identity) but it must be documented honestly: makers are deanonymised by the protocol. + +## Risks + +- **Sybil attacks at scale.** Cheap to mint new pseudonyms; defection from a low-reputation identity is consequence-free. Mitigation: reputation accrual rate-limited by completed-swap throughput and notional caps; cost of building reputation equals the cost of N honest swaps plus the bond-equivalent capital tied up over the accrual window. +- **Sidechannel deanonymisation of zk-reputation takers.** Even unlinkable proofs leak via timing, notional distribution, maker-side counterparty profiling, and (if poorly implemented) proof-construction telemetry. The privacy claim is "unlinkable across the public ledger", not "unlinkable to a maker who actively profiles its counterparties". This distinction must be documented for users. +- **Reputation-purchase attack.** An attacker buys a high-reputation maker identity (if transferable) and grief-attacks. Mitigation: non-transferable reputation, or transfer with a notice period and a "decayed-reputation" cooling window. +- **Bootstrap free-option exposure.** Until reputation accumulates, the protocol depends on RFP-022 bonds for first-cohort security. If RFP-022 ships later than RFP-023, the bootstrap window is unprotected. Mitigation: ship together, or include a stub bond mechanism in RFP-023 itself. +- **zkVM proof cost regression.** If proof generation cost regresses (e.g. due to LEZ zkVM upgrade), zk-reputation takers face a sudden cost increase. Mitigation: proof-cost monitoring; protocol-adjustable proof-generation parameters. +- **Privacy-positioning narrative risk.** "Reputation" reads to some users as the opposite of "privacy". The communication challenge is real: explaining that the protocol records *outcomes* (which can be private under zk proofs) without recording *identities* (which it explicitly does not). Documentation budget required. +- **Governance attack on the registry.** If the reputation registry is upgradeable, an attacker who captures the upgrade key can wipe reputation or insert false reputation. Mitigation: immutable registry contract, with explicit migration path if upgrade is ever required. + +## Relationship to other RFPs in this bundle + +- **RFP-003 (Atomic Swaps with LEZ, open)** is the foundation. The per-pair SDKs, Risc0 escrow programs, and Logos Delivery / Logos Chat coordination are dependencies. RFP-023 layers the reputation registry and (in the zk path) the SMT-of-outcomes infrastructure on top. +- **RFP-022 (bonded atomic swaps)** consumes the maker reputation primitive defined here. In Tier 2 (LEZ to XMR), taker reputation is the only restraint on Alice's residual pre-XMR-lock free option. RFP-022 and RFP-023 can be implemented as a single workstream or sequenced (RFP-023 first to provide the primitive, then RFP-022 consumes it). +- **RFP-021 (cross-chain privacy DEX)** is the federated-custody alternative. Orthogonal: RFP-021 sacrifices non-custody for AMM-style liquidity; RFP-023 sacrifices throughput for reputation-as-bond non-custody. +- **RFP-025 (sXMR with SLA, option 2a)** consumes LP reputation as the default-attribution layer for slashing, because "LP defaulted" cannot be rendered from atomic-swap state alone. RFP-023 is a prerequisite for the credible deployment of RFP-025 option 2a. +- **RFP-024 (sXMR pure)** does not require reputation (the pure design has no SLA to enforce), but could optionally consume maker reputation for the LP-discovery UX. +- **RFP-004 (Privacy-Preserving DEX, open)** does not have a reputation primitive; RFP-023's reputation registry is a distinct artefact and does not collide. + +See [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) for the full reputation-as-bond analysis (mitigation 3) and the taker-privacy-tension discussion. + +## References + +- [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) +- [Wormhole Guardian set design (reputation-as-bond at scale)](https://wormhole.com/docs/learn/security/) +- [Sparse Merkle Tree (Vitalik Buterin, "Optimizing sparse Merkle trees")](https://ethresear.ch/t/optimizing-sparse-merkle-trees/3751) +- [Risc0 zkVM](https://dev.risczero.com/) +- [Logos Delivery and Logos Chat (referenced from RFP-003)](https://github.com/logos-co/logos-docs) diff --git a/RFPs/RFP-024-synthetic-xmr-pure.md b/RFPs/RFP-024-synthetic-xmr-pure.md new file mode 100644 index 0000000..4b28c87 --- /dev/null +++ b/RFPs/RFP-024-synthetic-xmr-pure.md @@ -0,0 +1,117 @@ +--- +id: RFP-024 +title: Synthetic XMR (sXMR), Pure Non-Custodial Design +tier: XL +funding: $TBD +status: draft +category: Applications & Integrations +--- + +# RFP-024 — Synthetic XMR (sXMR), Pure Non-Custodial Design + +> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos team and the community compare cross-chain DEX designs across RFP-021 through RFP-025. Hard requirements, team profile, timeline, and contracting details are deliberately omitted; they will be filled in if the design is selected for funding. + +## 🧭 Overview + +Build a synthetic XMR token (sXMR) on LEZ that tracks the XMR price via oracle, is composable across LEZ DeFi, and redeems to real XMR via peer-to-peer atomic swap. The protocol holds no XMR, runs no signer set, and offers no redemption SLA. + +The wedge: this is the only synthetic in the published landscape where the redemption path itself preserves privacy. sBTC (Stacks) redeems to public BTC; every other commodity synthetic (sETH, sLINK, perpetuals-collateralised positions) redeems to traceable transparent assets. sXMR is the first design where a successful redemption deposits real XMR on Monero L1, severing the public trail. + +The honest framing: this is a synthetic with a soft, market-clearing peg, not a hard-redeemable synthetic. The oracle is the *quoted* price; the *achievable* price is whatever an XMR LP will swap for, when one is willing. Structurally closer to a DEX trading pair than to sBTC (Stacks). The product fits a privacy-maximalist audience that wants XMR-shaped exposure inside LEZ DeFi without depending on protocol-held custody. + +## Desired properties + +- **Non-custodial.** No vault holds XMR. No signer set. No bridge. +- **Soft peg.** The oracle is a reference price; the achievable redemption price is whatever an LP quotes. Spread widens under stress without bound. +- **No redemption guarantee.** A counterparty may not exist when the user wants to exit. The protocol does not commit to availability. +- **Composable on LEZ.** sXMR is a vanilla LEZ token (the LEZ token program standard from RFP-003 hard requirement 7), callable by any other LEZ program: lending markets, DEXes, governance, structured products. +- **Private exit.** Successful redemption deposits real XMR on Monero L1, severing the public trail. The XMR side never touches LEZ. +- **Open LP set.** Anyone with XMR can quote. No permission required; no LP registry; no bond. +- **Regulatory minimalism.** The protocol does not handle XMR; it is, in defensible terms, a price feed plus a matching board for users to find each other. +- **Off-chain orderbook.** Quotes and intents flow over Logos Delivery (the same coordination primitive RFP-003 uses for maker advertisement). The on-chain artefact is the atomic-swap settlement program; the matching itself is bilateral and off-chain. + +## High-level functionality and flow + +``` + sXMR LEZ program oracle (XMR/USD) Oracle program on LEZ + (token + stable vault) <---------------------- + + mint | burn + + Intent gossip match Open XMR LPs + (off-chain via Logos (anonymous; free + Delivery) to enter/exit) + sXMR <--> XMR quotes + + atomic swap (adaptor-sig protocol from RFP-003) + LEZ <------------------------------> Monero L1 + + sXMR holder gets XMR XMR LP gets sXMR, + on Monero L1 burns for stable +``` + +### Mint + +A user deposits a stable (or other LEZ-accepted asset) into the sXMR collateral vault on LEZ; the protocol mints sXMR to the user at the current oracle price (with a configurable mint fee). The vault holds the collateral; sXMR circulates freely. + +### Redemption (the privacy-preserving exit) + +1. Alice (sXMR holder) signals intent to redeem over Logos Delivery. +2. Bob (open-set XMR LP) sees the intent, computes his quote (oracle price plus his spread), and replies bilaterally. +3. Alice accepts; Alice and Bob execute an atomic swap using the RFP-003 LEZ-XMR SDK. Alice's sXMR is burned on LEZ; Bob's XMR arrives on Monero at an address Alice controls. The matching, the quote, and the bilateral acknowledgement happen off-chain over Logos Delivery and Logos Chat. +4. Bob's swapped sXMR is burned by Bob; the released stable collateral becomes Bob's payout (less any protocol fee). + +### Failure modes (no protocol enforcement) + +- If Bob walks away mid-swap, the atomic-swap timelock returns Alice's sXMR; she retains her position. +- If no Bob exists, Alice's sXMR trades at a discount to oracle until a Bob shows up or Alice gives up. There is no protocol-side compensation for redemption delay. + +## Pros + +- **Cleanest privacy story in the bundle.** Successful redemption ends with real XMR on Monero L1. No protocol-side custody, no signer-set deposit-history leak (the RFP-021 and RFP-025 option 2b weakness), no view-key disclosure (the RFP-022 Tier 2 constraint). +- **Cryptographic non-custody is full.** No vault, no bond, no SLA. The trust assumption is the oracle (for pricing) and the soundness of the RFP-003 atomic-swap protocol. The protocol cannot lose user funds in a custody breach because it does not have custody. +- **Composable from day one.** sXMR is a vanilla LEZ token; lending markets and DEXes can integrate without coordinating with the sXMR team. The product surface scales with the rest of LEZ DeFi. +- **Regulatory defensibility is highest.** The protocol does not handle XMR. Operators of price feeds and matching boards have meaningfully different exposure from operators of XMR-custodying bridges. +- **Lowest engineering cost in the bundle's synthetics line.** No SLA enforcement; no LP registry; no slashing logic; no signer-set custody. The core deliverable is a token, a collateral vault, an oracle integration, and an intent layer over Logos Delivery. +- **Open LP set is censorship-resistant.** No permissioned set; no KYC; no operator that can be coerced into refusing service. + +## Cons + +- **Soft peg widens under stress without bound.** The achievable redemption price is the marginal LP quote. If LPs vanish, sXMR can trade at any discount to oracle; the protocol cannot intervene. +- **No redemption SLA.** Users who want guaranteed redemption (institutions, market makers, structured products) cannot use sXMR directly under Goal 1; they need RFP-025. +- **Demand asymmetry.** It is easy to mint sXMR (privacy-curious DeFi users want XMR exposure inside LEZ); it is harder to source LPs (XMR maximalists may not want a public LP role at all, even pseudonymous). The LP side is the structural bottleneck. +- **Adverse selection of LPs.** LPs only show up when oracle is below true market XMR price (free money for them on the redemption leg) and vanish when oracle is above (would-be loss). Redemption availability is asymmetric across regimes. +- **Atomic-swap UX inherited.** 30 to 60 minutes per swap, both parties online. The intent layer over Logos Delivery softens this but cannot remove it. +- **No protocol-side enforcement of LP behaviour.** Refusing to proceed is *valid behaviour* under the atomic-swap protocol; the protocol cannot distinguish malicious refusal from connectivity loss. Reputation (RFP-023) is the only available restraint, and even then it operates as soft pressure, not enforcement. +- **Oracle dependency.** The oracle is the only price signal; oracle attack or stale price degrades minting accuracy. Mitigation lives outside this RFP (existing oracle RFPs in the bundle, or oracle aggregation patterns). + +## Risks + +- **LP exodus.** All XMR holders stop quoting. sXMR trades at an indefinite discount to oracle until LPs return. Mitigation: design the protocol to survive long discount regimes without auto-liquidation; let the discount be the market signal that restores LP supply. +- **Oracle manipulation.** A manipulated XMR/USD oracle lets an attacker mint sXMR cheaply or under-collateralise existing positions. Mitigation: use a redundant oracle stack with median-of-N pricing; impose configurable price-deviation guards on minting. +- **Collateral solvency.** If the collateral asset (stables or otherwise) is itself compromised (depeg, exploit, regulatory freeze), sXMR backing degrades. Mitigation: accept only collateral with documented threat models; cap protocol-wide collateral concentration by asset. +- **Privacy-claim overreach.** sXMR itself is *not* a private asset on LEZ (the token program is public state). The privacy property applies *only* to the redemption-to-XMR path. If users mint sXMR from a public LEZ account and never redeem, no privacy is conferred. The communication challenge is non-trivial; documentation must be honest. +- **Regulatory inflection on Monero.** If a jurisdiction outlaws Monero entirely, the redemption path becomes legally fraught for LPs in that jurisdiction. The protocol itself is insulated (it does not handle XMR) but the LP economy may concentrate in friendlier jurisdictions. Strategic, not technical. +- **Atomic-swap maker burnout.** The free-option problem RFP-022 addresses applies here too: LPs can be free-optioned by takers. Without bonds (Goal 1's premise), this can drive LPs away. Mitigation: optional layered consumption of RFP-022 Tier 2 (bonded XMR atomic swaps) or RFP-023 (reputation) for the redemption leg, as separate products on top of the same sXMR token. +- **No protocol-side fee revenue capture.** Open LP set means LPs capture the spread; the protocol's only revenue is mint and burn fees on sXMR itself. Sustainability depends on mint/burn volume, which depends on LEZ DeFi composability adoption. + +## Relationship to other RFPs in this bundle + +- **RFP-003 (Atomic Swaps with LEZ, open)** is the foundation: the LEZ-XMR atomic-swap SDK is the redemption settlement layer. RFP-024 does not modify RFP-003; it builds the sXMR product on top of it. +- **RFP-025 (sXMR with SLA)** is the complementary design. RFP-024 targets the privacy-maximalist audience accepting market-clearing redemption; RFP-025 targets the SLA-needing audience accepting custody risk. The two together cover the synthetics design space. A reader should pick one or both based on which user segment they want to serve. +- **RFP-022 (bonded atomic swaps)** could optionally be consumed by RFP-024 as the redemption-leg primitive: instead of bare atomic swaps, redemption uses bonded atomic swaps. This compounds LP commitment but adds bond friction on the LP side. The pure design in this RFP does not require this layering. +- **RFP-023 (reputation-based atomic swaps)** could optionally be consumed for LP-discovery UX (takers see LP reputation before initiating). Not strictly required for the core product. +- **RFP-021 (cross-chain privacy DEX)** is orthogonal. RFP-021 offers real-XMR cross-chain swaps with federated custody; RFP-024 offers synthetic-XMR exposure with atomic-swap redemption. Different products; same broad audience can use both. +- **RFP-004 (Privacy-Preserving DEX, open)** is the natural single-chain trading venue for sXMR once minted. Trade sXMR against stables on RFP-004's AMM pools under the deshield-swap-reshield pattern; redeem to real XMR via RFP-024. + +See [appendix/sxmr-design-space.md](../appendix/sxmr-design-space.md) for the full Goal 1 / Goal 2a / Goal 2b design analysis and the pre-spec validation list. + +## References + +- [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) +- [appendix/sxmr-design-space.md](../appendix/sxmr-design-space.md) +- [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) +- [Synthetix V3 documentation (CDP-style collateral reference)](https://docs.synthetix.io/v/v3/) +- [Bitcoin to Monero atomic swaps (getmonero.org)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) +- [eigenwallet/core (XMR atomic swap fork of comit-network/xmr-btc-swap)](https://github.com/eigenwallet/core) +- [Farcaster project (XMR atomic swap, community-scale active)](https://github.com/farcaster-project) diff --git a/RFPs/RFP-025-synthetic-xmr-sla.md b/RFPs/RFP-025-synthetic-xmr-sla.md new file mode 100644 index 0000000..e47d16b --- /dev/null +++ b/RFPs/RFP-025-synthetic-xmr-sla.md @@ -0,0 +1,183 @@ +--- +id: RFP-025 +title: Synthetic XMR (sXMR) with Redemption SLA +tier: XL +funding: $TBD +status: draft +category: Applications & Integrations +--- + +# RFP-025 — Synthetic XMR (sXMR) with Redemption SLA + +> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos team and the community compare cross-chain DEX designs across RFP-021 through RFP-025. Hard requirements, team profile, timeline, and contracting details are deliberately omitted; they will be filled in if the design is selected for funding. + +## 🧭 Overview + +Build a synthetic XMR token (sXMR) on LEZ with a redemption SLA: users can redeem sXMR for real XMR at oracle price, on demand, up to the protocol's committed capacity. The atomic swap is still the settlement primitive, but counterparty availability is no longer left to the open market. + +The RFP requires applicants to commit to one of two sub-designs: + +- **Option 2a: Bonded LP set.** LPs join a registered set on LEZ, post stable collateral as bond, and are obligated to honour redemption requests within a window. Default triggers bond slashing paid to the redeemer. Non-custodial in the strict sense (LPs hold their own XMR) but bonded for performance. +- **Option 2b: Protocol XMR reserve.** The protocol accumulates an XMR reserve (from mint fees, a yield programme, or a one-time treasury seed) held in a threshold-signer multisig on Monero. Redemption draws directly from the reserve. Custodial: trust lives in the signer set. + +The RFP exists so applicants can argue for one of the two and the Logos team can pick. The two options have different threat models, different LP economics, and different regulatory exposures. They cannot be combined cleanly: option 2b's reserve and option 2a's open-but-bonded LP set are different protocols sharing only the sXMR token name. + +This RFP is the marketable companion to RFP-024 (sXMR pure non-custodial). A reader should pick at least one of the two, and may pick both, depending on which user segment they want to serve. + +## Desired properties (both options) + +- **Redemption SLA.** A user redeeming sXMR for XMR receives real XMR on Monero L1 within a documented window (e.g. 60 minutes for option 2a; instant settlement subject to atomic-swap timelock for option 2b). +- **Oracle-priced redemption.** Redemption price is within a documented tolerance of the oracle reference; not subject to LP-quote dispersion. +- **Composable sXMR token on LEZ.** Vanilla LEZ token (the LEZ token program standard from RFP-003 hard requirement 7), callable by lending, DEXes, governance, structured products. +- **Private exit.** Successful redemption ends with real XMR on Monero L1. The XMR side never leaks the redeemer's LEZ-side identity beyond the redemption flow itself. +- **Bondless taker entry path.** First-time redeemers (the taker side, from the atomic-swap perspective) are not required to post a LEZ-denominated bond for the first redemption up to a capped notional (worked example: US$100 equivalent). After the first redemption, the taker has LEZ-denominated assets they can post against subsequent redemptions. The bond on the *LP side* (option 2a) or the *reserve* (option 2b) is unaffected; those are maker-side or protocol-side constructs. + +## Option 2a: bonded LP set + +LPs join a registered set on LEZ. Each LP posts stable collateral on LEZ equal to (or some multiple of) their XMR commitment. When a redemption request is routed to an LP, they must complete the atomic swap within a window. If they default, their bond is slashed and paid to the redeemer. LPs may leave the set, but only after a notice period that exceeds the redemption SLA. + +``` + sXMR LEZ program + + LP registry + + slashing logic (consumes RFP-023 reputation + for default attribution) + + redemption LP bond + request + + sXMR holder Bonded LP + burns sXMR, atomic swap posts stable bond + receives XMR <----------------> delivers XMR or + (adaptor-sig) forfeits bond + + if LP defaults: bond paid out as compensation, + attribution layered via RFP-023 reputation +``` + +**Enforceability caveat.** "LP defaulted" is not a verdict an on-chain program can render from atomic-swap state alone (per the cross-cutting analysis in [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md)). Refusing to proceed is *valid behaviour* under the atomic-swap protocol; the LEZ contract cannot distinguish malicious refusal from connectivity loss. The realistic implementation consumes the RFP-023 reputation primitive as the attribution layer: an LP who repeatedly fails to honour redemptions loses reputation; the bond is slashed against the *attested* default condition, not against atomic-swap state directly. Without RFP-023 (or an equivalent attestor mechanism), the bond can be used only to gate participation (priority, fee tiers, future-slot access), not slashed with cryptographic certainty on a single failed swap. + +## Option 2b: protocol XMR reserve + +The protocol holds an XMR reserve in a threshold-signer multisig on Monero. Redemption draws from the reserve directly, with the atomic swap acting as the settlement rail between the reserve custodian and the redeemer. + +``` + sXMR LEZ program + + reserve accounting + + burn sXMR trigger swap + + Reserve module + (LEZ program) + + atomic swap + (adaptor-sig) + + Threshold-signer reserve on Monero + (n-of-m, bonded signers, view-key-shared) +``` + +At this point the design has reinvented sBTC (Stacks) with an oracle bolted on. The atomic swap is the wire format; trust lives in the signer set. The same view-key-shared TSS custody constraint applies as in RFP-021: honest-but-curious signers learn the protocol-side deposit history. This is the structural trade-off option 2b accepts in exchange for the redemption SLA. The signer set must be bonded and slashable to make the trust assumption explicit. + +## High-level functionality and flow (common) + +### Mint + +Identical to RFP-024. User deposits accepted LEZ collateral; protocol mints sXMR at oracle price; collateral sits in vault. + +### Redemption (option 2a) + +1. Alice (sXMR holder) submits a redemption request to the LEZ sXMR program. +2. Program routes the request to a bonded LP in the registry (round-robin, reputation-weighted, or auction-priced). +3. LP receives the request; LP and Alice execute an atomic swap via the RFP-003 LEZ-XMR SDK within the SLA window. +4. On success, Alice's sXMR is burned, LP claims the released collateral as their payout. +5. On failure (LP times out): bond slashing is triggered. RFP-023 reputation attestation establishes that the failure was the LP's fault (not the redeemer's); slashed bond is paid to the redeemer as compensation; LP's reputation is decremented. + +### Redemption (option 2b) + +1. Alice submits a redemption request. +2. Program signals the reserve module; threshold signers co-sign a Monero spend from the reserve to a destination Alice supplies. +3. Atomic-swap protocol enforces the conditional: Alice's sXMR is burned only if the Monero spend lands on chain. +4. Reserve accounting updates; if the reserve is depleted below a safety threshold, mints are paused until the reserve is replenished from mint fees or treasury. + +## Pros (both options) + +- **Redemption SLA is a real product feature.** Institutions, market makers, and structured-products integrators can underwrite sXMR positions because they have a documented exit window. +- **Hard peg within capacity.** Redemption price tracks oracle within a documented tolerance, not LP-quote dispersion. The sXMR token becomes usable as collateral inside other LEZ programs with predictable mark-to-market. +- **Composable from day one.** Vanilla LEZ token; the SLA is what makes downstream integrations viable. +- **Private exit preserved.** Successful redemption ends with real XMR on Monero L1, regardless of which option is chosen. Privacy on the destination chain is intact. +- **Bondless taker entry path.** Privacy-seeking redeemers without LEZ assets can complete a first capped redemption without bond friction. + +## Pros (option 2a-specific) + +- **Non-custodial in the strict sense.** LPs custody their own XMR; the protocol does not hold the underlying asset. No vault to drain. +- **Decentralised LP set.** Anyone meeting the bond requirement can join the registered set. +- **Slashing bounds the loss.** A defaulting LP's bond becomes the redeemer's compensation; protocol-wide solvency is bounded by total bonded capacity. +- **No signer-set custody risk for sXMR holders.** Trust assumption is the bonded-LP set's collective behaviour, which is bounded by the bond size, not by signer-set integrity. + +## Pros (option 2b-specific) + +- **Strongest SLA guarantee.** Redemption draws from a protocol-managed reserve; no LP discovery, no per-redemption matching. Settlement is deterministic up to the atomic-swap protocol's timelock. +- **Predictable redemption capacity.** Bounded by the reserve size; capacity planning is governance-driven rather than LP-supply-driven. +- **Lower operational complexity for redeemers.** Single counterparty (the reserve module), not a matched LP. + +## Cons (both options) + +- **Some form of trust returns.** RFP-024 (pure) trusts only the oracle and the atomic-swap protocol; RFP-025 trusts additionally an LP set (option 2a) or a signer set (option 2b). The cypherpunk story is weaker. +- **Atomic-swap UX is still inherited.** 30 to 60 minutes per redemption, both parties online. The SLA constrains the *availability* of the counterparty but not the cryptographic settlement time. +- **Oracle dependency is sharper.** With an SLA on oracle-priced redemption, an oracle failure has SLA-breaking consequences, not just mint-side accuracy consequences. +- **Regulatory exposure is higher.** A protocol that commits to redeeming a privacy coin on demand draws more scrutiny than RFP-024's price-feed-plus-matching-board posture. + +## Cons (option 2a-specific) + +- **Slashing requires off-chain attribution.** The LEZ contract cannot adjudicate "LP defaulted" from atomic-swap state. RFP-023 reputation is the realistic attribution mechanism; without it, the bond gates participation but does not slash on single defaults. +- **Bond opportunity cost limits LP supply.** Locking stable collateral against XMR commitment is expensive; LP yield must clear the opportunity cost. Realistic capacity is constrained by the LP economy's appetite for the bond/yield trade-off. +- **Coordinated default can exceed bonded capacity.** If many LPs default simultaneously (e.g. during a Monero price shock), aggregate slashing may not cover aggregate redemption demand. The peg breaks. +- **LP notice period limits flexibility.** LPs must wait out a notice period exceeding the SLA before exiting the set; this raises the cost of becoming an LP. + +## Cons (option 2b-specific) + +- **Custodial.** A signer set holds real XMR on Monero. Custody risk is real: signer collusion, key compromise, or signing-software bug can drain the reserve. This is exactly the failure mode that hit Thorchain in May 2026 and Wormhole in February 2022. +- **View-key-shared custody leaks Monero deposit history to signers.** The same compromise RFP-021 makes. Honest-but-curious signers learn the protocol-side Monero deposit history; this is the structural cost of TSS custody of XMR with current cryptography. +- **Effectively recreates sBTC (Stacks) with an oracle.** The novelty of the design is small relative to existing custodial XMR wraps (other than the LEZ privacy execution on the sXMR token side). +- **Reserve undercollateralisation breaks the peg.** If the reserve is drawn down faster than it can be replenished from fees, redemption capacity goes to zero; sXMR loses its peg. +- **Signer-set membership is gated.** Lower decentralisation than option 2a; signer set is a censorship and coercion target. + +## Risks (both options) + +- **Oracle manipulation.** A manipulated XMR/USD oracle lets an attacker mint sXMR cheaply or extract reserve XMR (option 2b) at unfavourable rates. Mitigation: redundant oracle stack with median-of-N pricing; configurable price-deviation guards; SLA-aware oracle staleness checks. +- **Regulatory action.** Either option may attract jurisdiction-specific bans on the protocol, LP participation, or reserve custody. Mitigation: jurisdictional diversity in LP set or signer set; documented compliance posture; willingness to operate as a permissionless smart contract regardless of any single jurisdiction's stance. +- **First-swap cap evasion.** A redeemer could split a large redemption into many capped first-redemptions under fresh pseudonyms. Mitigation: rate limits enforced at the LEZ escrow program; combine with reputation gating (RFP-023) for higher tiers. + +## Risks (option 2a-specific) + +- **RFP-023 dependency.** Without a reputation primitive, the bond is not actually slashable on default. If RFP-023 ships later than RFP-025 option 2a, the protocol launches with a weaker enforcement story than its marketing implies. Mitigation: sequence RFP-023 first, or include a stub-reputation mechanism in RFP-025 itself. +- **Reputation gaming attacks on the LP side.** An LP can build reputation cheaply by completing many small redemptions then default on a large one. Mitigation: notional-weighted reputation; cap per-LP redemption size proportional to accumulated reputation and bond. +- **Bond denomination volatility.** If the bond asset (stables on LEZ) depegs, LPs become under-collateralised against their XMR commitments. Mitigation: cap protocol-wide LP collateral concentration by asset; require LPs to top up on bond-asset depeg events. + +## Risks (option 2b-specific) + +- **Signer-set compromise.** A captured signer set can drain the entire reserve. Mitigation: large signer set (Serai uses up to 600; Thorchain ~100); permissionless entry; high bond-to-custodied ratio; emergency halt mechanism; geographic diversity. +- **Signer-set offline event.** If the signer set cannot reach threshold to sign (network partition, mass node failure), redemption SLA breaks even with no malice. Mitigation: redundant signer geographic placement; documented signer SLOs; emergency-halt mechanism that pauses redemption gracefully rather than failing under load. +- **TSS implementation bug.** Thorchain's GG20 TSS exploit (May 2026, $10.8M) is the canonical example. Mitigation: choose FROST over GG20; budget for Cypher Stack-equivalent audit; isolate signer-software dependencies. + +## Relationship to other RFPs in this bundle + +- **RFP-024 (sXMR pure non-custodial)** is the complementary design. RFP-025 trades non-custody for SLA. A reader should pick one or both based on the target audience: pure-cypherpunk users for RFP-024; SLA-needing users for RFP-025. +- **RFP-003 (Atomic Swaps with LEZ, open)** is the foundation: the LEZ-XMR atomic-swap SDK is the redemption settlement layer for both options. +- **RFP-023 (reputation-based atomic swaps)** is a hard dependency for option 2a's slashing mechanism. The reputation primitive is what makes "LP defaulted" attributable. +- **RFP-022 (bonded atomic swaps)** could optionally be consumed by either option as the bonded-redemption-leg primitive on the atomic-swap settlement, layered on top of the LP-side or reserve-side bond. +- **RFP-021 (cross-chain privacy DEX)** is orthogonal: it offers real-asset cross-chain swaps with federated custody; this RFP offers synthetic-XMR exposure with managed redemption. Option 2b shares the view-key-shared TSS custody trade-off with RFP-021's XMR support; the two RFPs could share signer-set infrastructure if both are funded. +- **RFP-004 (Privacy-Preserving DEX, open)** is the natural single-chain trading venue for sXMR. + +See [appendix/sxmr-design-space.md](../appendix/sxmr-design-space.md) for the Goal 2a vs Goal 2b property matrix and decision tree. + +## References + +- [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) +- [appendix/sxmr-design-space.md](../appendix/sxmr-design-space.md) +- [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) +- [sBTC (Stacks) Bitcoin layer documentation](https://docs.stacks.co/concepts/sbtc) +- [Synthetix V3 (CDP-style collateral reference)](https://docs.synthetix.io/v/v3/) +- [Crypto Times: Thorchain TSS exploit (2026-05-17)](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) +- [Halborn: Wormhole Hack February 2022](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) +- [FROST paper (Komlo and Goldberg)](https://eprint.iacr.org/2020/852) diff --git a/appendix/cross-chain-trust-model-contrast.md b/appendix/cross-chain-trust-model-contrast.md new file mode 100644 index 0000000..16fe323 --- /dev/null +++ b/appendix/cross-chain-trust-model-contrast.md @@ -0,0 +1,220 @@ +# Cross-Chain Trust Model Contrast + +Background appendix for the cross-chain RFP bundle (RFP-021, RFP-022, RFP-023, RFP-024, RFP-025). Establishes the design space the bundle navigates and the mitigations that distinguish the proposed RFPs from each other. + +## Two architectural camps + +Every deployed cross-chain swap design today collapses to one of two trust models. + +### Federated-signer middle chain + +Examples: Thorchain (live since 2021), Serai (pre-mainnet as of 2026-05), Maya, Chainflip. A purpose-built chain whose validator set custodies external assets via a threshold signature scheme (GG20 ECDSA for Thorchain; FROST per-curve for Serai, including FROSTLASS over CLSAG for Monero) and runs swap matching natively. + +What the user trusts: + +1. A threshold of the validator set will not collude to spend from the vault. +2. The cryptographic primitive used to combine signer contributions is sound. Not a free assumption: Thorchain's GG20 TSS failed in production in May 2026, draining $10.8M from an Asgard vault via a TSSHOCK-class weakness. Source: [Crypto Times, 2026-05-17](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/). +3. The implementations on every external chain are correct. Not a free assumption either: a Solana-side `load_instruction_at` bug let an attacker forge a Wormhole VAA in February 2022 and mint 120k wETH unbacked ($326M). Source: [Halborn](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022). + +Pros: + +- AMM-style liquidity. A single ordered state machine maintains pool invariants and serves all-comers without per-trade matching. +- One-step user experience: deposit-with-memo, await outbound. No counterparty interactivity, no refund flows, no online-availability requirement past broadcast. +- Sub-block-time settlement on the middle chain; only destination-chain finality and the TSS keysign delay the outbound. +- Arbitrary asset pairs at protocol-set pricing. +- Cryptoeconomic recourse: misbehaviour is slashable. Thorchain runs 2:1 bonded plus 1:1 pooled. Serai caps custody at 33% of allocated validator stake. Source: [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md). + +Cons: + +- Custody risk is real and realised (see incidents cited above). +- The signer federation is a chokepoint for censorship and out-of-protocol pressure on individually identifiable validators. +- Pre-economic-security bootstrap. Serai's mint-on-bootstrap design illustrates that the slashable-bond argument does not bind until the validator-stake pool catches up with custody. +- Public middle-chain state links source and destination identities on the comparator chains. Every comparator publishes the source-to-destination link on at least one public ledger. +- For Monero specifically: any TSS custody of XMR is necessarily view-key-shared. Serai's FROSTLASS over CLSAG is the most advanced production-grade design, but the validator set still observes which Monero outputs are committed to the swap; the privacy property is "honest-but-curious validators learn the LEZ-to-Monero deposit history" not "validators learn nothing". + +### Atomic swap + +Examples: COMIT Network (xmr-btc-swap, archived as of 2024-11), Farcaster, AtomicDEX (rebranded to Komodo Wallet, no recent volume), Liquality (discontinued 2024-06-15). All but Farcaster have wound down. The cryptographic primitive: HTLC for script-compatible pairs; adaptor signatures with cross-curve DLEQ proofs for Monero pairs. + +What the user trusts: nothing beyond the soundness of the cryptographic construction and the liveness of the two parties for the duration of the swap. + +Pros: + +- No custody risk. Funds never leave control of one of the two participants. There is no validator set to slash and no vault to drain. +- No signer federation: no 13-of-19, no 67% threshold, no per-chain observer to be censored or compromised. +- No pre-economic-security window. The cryptographic security is full from day one because there is no bond-to-custody ratio to bootstrap. + +Cons: + +1. **Free option on both sides.** Once one party has locked, the other can wait and observe price movement before completing or walking away. The locker's downside is opportunity cost on inventory locked for the entire timelock window; the waiter's downside is gas plus time. Empirically this is the failure mode that kills BTC-XMR adoption: makers refuse to lock against takers who can free-option them for hours. Recognised in the atomic-swap literature as "the free option problem"; not a bug in any particular implementation, but the cost of atomicity itself. +2. **Settlement time dominated by the slowest chain.** A single swap can take 30 minutes to several hours to finalise because confirmations stack across both chains. Refund timelocks are measured in hours, not minutes. +3. **Mandatory interactivity for both parties.** Both parties must be online for lock, reveal, and (in adversarial paths) refund. If Alice goes offline mid-swap, Bob waits out the refund window, and vice versa. +4. **Per-trade matching.** No protocol-owned liquidity, no AMM pricing; each swap requires a willing counterparty for the exact pair and exact size. +5. **Pair coverage.** HTLC requires compatible scripting on both chains. BTC-XMR specifically required about five years of cryptographic work (2017 proposal to 2021 working implementation via adaptor signatures over Ed25519 and secp256k1). Source: [getmonero.org: Bitcoin to Monero atomic swaps are now live, 2021-08-20](https://www.getmonero.org/2021/08/20/atomic-swaps.html); [Hoenisch and del Pino, IACR 2021/441](https://eprint.iacr.org/2020/1126.pdf). + +Cons (1) through (3) are the ones the design space can plausibly attack without abandoning the atomic-swap model entirely. (4) is structural: "fixing" it by adding protocol-owned liquidity reinvents the middle-chain DEX. (5) is a per-pair engineering cost paid once. + +### Why the federated middle chain has won the volume race + +Thorchain has processed $112B cumulative volume since 2021. The four most-cited atomic-swap projects have collectively produced roughly $35M in volume over the same period (Liquality lifetime figure, [defiprime.com: Liquality](https://defiprime.com/liquality)). The structural reasons: + +- Liquidity gravity. Peer-to-peer matching requires a counterparty per trade; AMM pools concentrate liquidity into a single state machine. +- User experience. Multi-hour timelocks, online-availability requirements, refund flows, and command-line tooling have prevented retail adoption. +- Pair coverage. HTLC was constrained to chain pairs with compatible scripting for years before adaptor-signature techniques generalised it. + +Source: [Thorchain Medium, "Why Cross-Chain bridges are superior to Atomic Swaps" (2019-07-02)](https://medium.com/thorchain/why-cross-chain-bridges-are-superior-to-atomic-swaps-aebde263103c). + +## Mitigations for the addressable atomic-swap cons + +Three independent levers. None is sufficient on its own; their combination defines specific niches that the proposed RFPs target. + +### Mitigation 1: same-asset-to-same-asset (bridge, not trade) + +If the two legs of the swap are denominations of the *same* underlying asset (e.g. native BTC on Bitcoin and an LEZ-side wrapped-BTC token redeemable 1:1 to native BTC via a light-client inclusion proof), the *trade* component disappears: there is no relative-price volatility between the two legs, so the free-option value collapses toward zero. The mid-swap optionality that makes the maker refuse to lock against an arbitrary taker is a function of `σ × √T × notional`; if `σ → 0` for the pair, the option is worthless and the timelock window stops being an exploitable asset. + +Important scoping: + +- This argument applies only to a 1:1 wrapped or SPV-backed token, where redemption is at a contractually fixed ratio and the only `σ` is residual peg slack (premium/discount, queue depth, fees). +- It does *not* apply to an oracle-priced synthetic token (e.g. an sXMR that tracks the XMR price via oracle, collateralised by stables or other assets). The peg slack of an oracle-priced synthetic *is* the volatility the free option pays out on. Oracle-priced synthetic exposure is a distinct product (see RFP-024 and RFP-025); it does not solve the free-option problem. + +Feasibility per chain: + +- For chains with public outputs (BTC, ETH), a 1:1 wrap via light-client proofs is principled. The LEZ-side mint primitive is a Risc0 program that verifies an inclusion proof against a header chain (forkable from ZeroSync or Citrea's Clementine LCP for BTC; from existing Ethereum light-client work for ETH). +- For Monero, no principled wrap is feasible today. Monero has no SPV-style proof primitive that can demonstrate "address Y received amount X" without view-key sharing: ring signatures, RingCT, and one-time stealth addresses defeat external observation by design. Monero's bilateral `check_tx_proof` works in a private wallet-to-wallet context but cannot be lifted to a public LEZ contract without disclosing the per-tx private key and blinding factor to world-readable state, which is mathematically equivalent to view-key disclosure for the swap output. The FCMP++ (full-chain membership and metadata-private proofs) research direction may unlock a non-disclosing variant; it is pre-production. Source: [Monero stealth address documentation](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf); [Monero FCMP++ overview](https://www.getmonero.org/resources/moneropedia/fcmp.html). + +Where Mitigation 1 fits in the bundle: + +- BTC and ETH: complementary to RFP-022 Tier 1 (bonded atomic swaps), but worth treating as a distinct design (the user does not have to overpay a bond when the trade itself has near-zero volatility). +- XMR: not currently feasible. Move to Mitigation 2 or 3 for free-option control. + +### Mitigation 2: bonded atomic swap (forced completion via slashing) + +The maker/taker bond design RFP-022 specifies in detail. Bonds posted on LEZ; slashing conditioned on LEZ-observable failures to advance through the swap state machine. + +#### The free-option problem in concrete form + +Standard adaptor-signature swap. Alice locks first (XMR or BTC) into a 2-of-2 output. Bob then locks Logos in an LEZ contract conditioned on secret `s`. To claim Logos, Alice publishes a signature that reveals `s` to Bob; Bob uses `s` to sweep Alice's lock. + +- Between Lock-Logos and Reveal, Alice holds a free option on the price. +- Between Alice's first lock and Bob's Logos lock, Bob can refuse to lock if the price moved. + +#### Why slashing only works on the LEZ side + +Monero has no scripting. Bitcoin has scripting too limited to hold a bond conditioned on protocol behaviour. The only place a slash can be enforced is on a smart-contract chain. LEZ is the right host for both bonds, but the LEZ contract needs to verify the preconditions (the locks) before applying any slash. This verification primitive splits cleanly into two tiers. + +#### Tier 1: symmetric bonding for LEZ to BTC and LEZ to ETH + +Both sides' locks are verifiable on LEZ via a chain-watching light-client module: BTC via a Risc0 header-chain light client (forkable from ZeroSync or Citrea Clementine LCP); ETH via existing Ethereum light-client work (e.g. Nimbus-derived). The locker's outputs on these chains are publicly identifiable to a known scriptpubkey or address, so an inclusion proof on LEZ leaks nothing the locker relied on as private. Both Alice's and Bob's bonds are slashable on default: full bilateral free-option mitigation. + +Phases and slash conditions (LEZ to BTC example): + +| Phase | What happens | Slash condition | +|-------|--------------|-----------------| +| 0. Quote | Bob signs quote (price, expiry, swap_id, refund_pubkeys); Alice and Bob run joint-key setup for the BTC 2-of-2 Taproot output | none | +| 1. Commit | Alice posts `B_alice` on LEZ referencing swap_id | none | +| 2. Lock-BTC | Alice constructs and signs the BTC lock tx, sends raw bytes to Bob over Waku; Bob verifies and broadcasts to Bitcoin (if Bob stalls, Alice broadcasts herself). Once confirmed, anyone submits `{btc_block_headers, merkle_proof, raw_tx}` to the LEZ swap contract, which verifies PoW, inclusion, scriptpubkey, and amount | If lock is confirmed on BTC but Bob does not advance to Lock-Logos within window: `B_bob_slice` goes to Alice | +| 3. Lock-Logos | Bob locks `trade_amount` plus `B_bob_slice` in LEZ contract conditioned on `s` | none | +| 4. Reveal | Alice publishes adaptor signature, revealing `s` to Bob | If Alice does not reveal within window: `B_alice` goes to Bob | +| 5. Settle | Bob claims BTC using `s`; Alice's bond and Bob's bond slice released | If Bob does not claim before deadline: no slash (capital loss is on Bob); Alice's bond auto-refunds | + +The unauthenticated proof-submitter property: Bob can broadcast Alice's signed lock tx himself (broadcasting is permissionless on every chain); the LEZ inclusion-proof submitter is also unauthenticated. This eliminates a class of grief vectors: if Alice signs a malformed lock tx (wrong amount, wrong scriptpubkey), Bob simply does not broadcast it, the tx never lands on Bitcoin, the inclusion proof never materialises, and the LEZ state machine quietly times out. There is no "attest or be slashed" dispute to adjudicate, because the precondition for state advancement (a real BTC lock) never holds. + +Same reasoning applies symmetrically to ETH. + +#### Tier 2: asymmetric bonding for LEZ to XMR + +Alice's XMR lock cannot be proven on LEZ without view-key disclosure to public state, per the impossibility result above (Monero stealth addresses plus RingCT defeat external observation; `check_tx_proof` lifted to a public contract is equivalent to view-key disclosure for the swap output). Consequence: + +- **Bob's bond is slashable on default.** Bob's lock is on LEZ and fully observable. Bond mechanic works exactly as in Tier 1 for Bob's side. +- **Alice's bond is slashable only on LEZ-observable abandonment.** It cannot be slashed for "failing to lock XMR" because LEZ cannot verify whether she did. It *can* be slashed for failing to reveal the secret on LEZ after Bob has locked Logos, because both the reveal and Bob's lock are LEZ-observable. +- **Residual free option Alice keeps.** Alice can refuse to lock XMR after Commit without on-chain consequence (her bond is gated by the reveal-after-Bob-lock event, which never occurs in this branch). Bob detects this off-chain by not seeing the XMR lock arrive and walks away without locking Logos; no slash on either side. Alice keeps a pre-XMR-lock free option but loses the post-Bob-lock free option. The residual option is smaller (it is the option to walk away from a quote before any meaningful commitment) but it is real. + +Tier 2 user experience: "Bob is bonded; Alice is reputation-gated only" under the current cryptography. When FCMP++ ships, Alice's lock becomes verifiable on LEZ without view-key disclosure and Tier 2 collapses into Tier 1; the RFP should carry an explicit upgrade clause. + +#### What both tiers fix + +- Con (1), the free option, partially or fully depending on tier. In Tier 1 the slash makes both parties' optionality strictly EV-negative when bonds are sized above option value (`σ × √T × notional`, so 2-5% of trade notional for 1-hour windows). In Tier 2 only Bob's optionality is closed. + +#### What neither tier fixes + +- Con (2): settlement time. Still bounded by source-chain finality plus LEZ finality plus the timelock window. The bond does not accelerate cryptographic settlement. +- Con (3): interactivity. Both parties must be online to lock, reveal, and (if the other side defaults) submit the slash claim. The bond removes the incentive to grief but not the requirement to participate. +- Cross-chain bond correlation: if Bob is matched against N concurrent swaps and LEZ re-orgs or his observer crashes, all N swaps slash him. Per-maker concurrency caps or bond scaling with active-swap count are needed. + +### Mitigation 3: maker and taker reputation + +A maker is a repeat participant; a long history of completed swaps is itself a slashable asset because losing the reputation forfeits all future fee revenue. This is the same argument that secures Wormhole's Guardians without bonded stake (reputation as economic gravity) but applied to a maker registry rather than a signer set. The proposed primitive is the subject of RFP-023. + +#### Maker reputation: trivially linkable + +Bob already wants a persistent identity on LEZ to receive quote requests, accumulate fee revenue, amortise bond posting, and signal trustworthiness. Layering reputation (count of completed swaps, slash history, time-in-protocol, total fee revenue) on top of (or instead of) a bond compounds the cost of defection. A maker with 10,000 completed swaps walking away from a single griefable trade is an irrational actor; the reputation acts as a long-tailed bond that the protocol cannot directly slash but the market does. + +#### Taker reputation: the privacy tension + +Takers are the population a privacy-positioned cross-chain DEX specifically wants to keep anonymous. A persistent on-chain taker identity that accumulates reputation is at direct odds with the privacy positioning, because reputation requires linkability across swaps by definition. + +Two design paths the proposed RFPs require applicants to consider: + +- **Capped anonymous takers.** First-swap takers size-capped (US$100 notional) without reputation; the cap relaxes after N successful completions under the same persistent pseudonym. Linkability is opt-in: a taker who wants larger size accepts linkability as the cost. +- **Zero-knowledge reputation.** Takers prove "I have completed at least N swaps with zero slashes" without revealing *which* swaps, via a Sparse Merkle Tree of swap outcomes maintained by the LEZ escrow program plus a zk membership proof. Preserves unlinkability across swaps while letting the taker borrow against accumulated reputation. Engineering-expensive; reuses the LEZ zkVM (Risc0) that RFP-003 already establishes. + +#### Threat model + +- Sybil attacks: cheap to mint new pseudonyms. Mitigation: reputation accrual is rate-limited by completed-swap throughput and notional caps. Cost of building reputation equals the cost of N honest swaps plus the bond-equivalent capital tied up over the accrual window. +- Maker griefing under multiple identities: a maker who slashes one identity can spin up another. Same mitigation: reputation accrual takes time and capital. +- Sidechannel deanonymisation: even zk reputation has timing, notional, and maker-side-view sidechannels. The privacy claim is "unlinkable across the public ledger" not "unlinkable to a maker who actively profiles its counterparties". This distinction must be documented for users. +- Bootstrap problem: the protocol has zero reputation at launch, so the first cohort of swaps has the strongest free-option exposure. Mitigation: start with caps plus RFP-022 bonds for early adopters; transition to reputation-only as reputation accrues. + +## The bondless-taker capped-entry mechanic + +A cross-cutting onboarding constraint that every bonding RFP in this bundle adopts (RFP-022, RFP-025). + +The problem: a privacy-seeking taker arriving from XMR or BTC has no LEZ-denominated assets yet. Requiring them to acquire LEZ assets before their first swap, then lock those assets as a bond, is exactly the chicken-and-egg the cross-chain DEX is supposed to solve. + +The mechanic: + +- First swap is capped at a small notional (worked example: US$100 equivalent), with no taker bond required. +- The cap is enforceable by the LEZ escrow program directly; no reputation registry needed. +- After completing the first swap, the taker has LEZ-denominated assets in their account. They can post these as a bond against larger swap sizes (or, if RFP-023 reputation is available, accrue reputation in lieu of bond). +- The cap value (US$100) is illustrative; applicants size it against expected free-option value at the protocol's typical lock window. + +Why this matters: it is the only way the bonding designs (RFP-022, RFP-025) provide a viable entry path for first-time takers without making them custody-tolerating or KYC-tolerating to acquire LEZ assets out of band. + +## Synthesis + +The three mitigations combine, with each RFP in the bundle picking a different combination: + +| RFP | Mitigation 1 | Mitigation 2 | Mitigation 3 | Bondless taker | +|-----|--------------|--------------|--------------|----------------| +| RFP-021 (federated middle chain) | not applicable | not applicable | not applicable | not applicable | +| RFP-022 (bonded atomic swaps) | complementary (BTC, ETH) | core mechanic (two tiers) | maker side | yes | +| RFP-023 (reputation-based) | not applicable | not applicable | core mechanic | inherits via cap | +| RFP-024 (sXMR pure) | not applicable | not applicable | not applicable | not applicable | +| RFP-025 (sXMR with SLA) | not applicable | LP-side bond (2a) or reserve (2b) | LP side | yes | + +The federated middle chain (RFP-021) sidesteps the free-option problem entirely by removing atomicity in favour of AMM-style execution. The bonded and reputation designs attack the free-option problem directly. The sXMR designs use atomic swaps as the redemption settlement layer rather than the DEX trading primitive, so the free-option problem appears in a different form (LP unavailability rather than counterparty defection). + +A reader choosing between the RFPs should ask: + +- Is custody acceptable in exchange for AMM liquidity and one-step UX? RFP-021. +- Is non-custody worth multi-hour settlement and interactivity, for BTC and ETH at scale? RFP-022 Tier 1. +- Is non-custody worth multi-hour settlement and interactivity for XMR specifically, accepting that Alice retains a residual pre-lock free option? RFP-022 Tier 2 plus RFP-023. +- Is reputation as economic gravity preferable to bonded collateral for the trust gradient? RFP-023. +- Is the requirement "synthetic XMR exposure inside LEZ DeFi composability" rather than "real XMR settlement"? RFP-024 (no SLA) or RFP-025 (with SLA). + +## References + +- [Bitcoin to Monero atomic swaps are now live (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) +- [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) +- [Decred blog: On-Chain Atomic Swaps (2017)](https://blog.decred.org/2017/09/20/On-Chain-Atomic-Swaps/) +- [comit-network/xmr-btc-swap (archived 2024-11)](https://github.com/comit-network/xmr-btc-swap) +- [Thorchain Medium: Why Cross-Chain bridges are superior to Atomic Swaps (2019-07-02)](https://medium.com/thorchain/why-cross-chain-bridges-are-superior-to-atomic-swaps-aebde263103c) +- [Thorchain docs: Continuous Liquidity Pools](https://docs.thorchain.org/technical-documentation/thorchain-finance/continuous-liquidity-pools) +- [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md) +- [Serai AMM docs](https://docs.serai.exchange/amm/) +- [Halborn: Wormhole Hack February 2022](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) +- [Crypto Times: $10.8M drained from Thorchain (2026-05-17)](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) +- [Monero whitepaper: Zero to Monero 2.0](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) +- [Monero FCMP overview](https://www.getmonero.org/resources/moneropedia/fcmp.html) +- [defiprime.com: Liquality](https://defiprime.com/liquality) +- [Liquality discontinuation announcement (2024-05-20)](https://x.com/Liquality_io/status/1792678368694985162) diff --git a/appendix/sxmr-design-space.md b/appendix/sxmr-design-space.md new file mode 100644 index 0000000..dc67cbb --- /dev/null +++ b/appendix/sxmr-design-space.md @@ -0,0 +1,242 @@ +# sXMR Design Space: Synthetic XMR on LEZ + +Background appendix for RFP-024 (sXMR pure non-custodial) and RFP-025 (sXMR with redemption SLA). Establishes the three design goals these RFPs partition between and the trade-offs that distinguish them. + +## What sXMR is + +A synthetic Monero token deployed as a program on the canonical Logos Execution Zone (LEZ). Oracle-priced for trading and composability inside LEZ; redeemed to real XMR via peer-to-peer atomic swap with no central custodian, no bridge, and no protocol-held reserves. + +The wedge: the only synthetic in the published landscape that terminates in a privacy-preserving asset on a privacy chain. sBTC (Stacks) redeems to public BTC, leaving the destination on a transparent ledger. Every other commodity synthetic (sBTC variants, sETH, sLINK) redeems to traceable transparent assets. sXMR is the first design where the redemption path itself preserves privacy. + +Honest framing: this is a synthetic with a soft, market-clearing peg, not a hard-redeemable synthetic. The oracle is the *quoted* price; the *achievable* price is whatever an XMR LP will swap for, when one is willing. Structurally closer to a DEX trading pair than to sBTC (Stacks). + +The RFP set picks one of two product directions before specifying further. They are incompatible at the architectural level: + +- **Non-custodial, mostly-works** (RFP-024). Pure atomic-swap design ships. Soft peg, market-dependent exit. The interesting product for privacy maximalists. +- **Always real XMR at oracle price** (RFP-025). Requires bonded LPs (slashable stable collateral on LEZ) or a protocol XMR reserve. Custody or solvency risk returns. The marketable product for SLA-needing audiences. + +## Goal 1: non-custodial, mostly-works + +The premise of RFP-024. + +### Properties + +- **Non-custodial.** No vault holds XMR. No signer set. No bridge. +- **Soft peg.** Oracle is a reference; achievable redemption price is whatever an LP quotes. Spread widens under stress without bound. +- **No redemption guarantee.** Counterparty may not exist when you want to exit. +- **Composable on LEZ.** sXMR is a vanilla LEZ token, callable by any other LEZ program (lending, DEX, governance). +- **Private exit.** Successful redemption deposits real XMR on Monero L1, severing the public trail. +- **Open LP set.** Anyone with XMR can quote; no permission required. +- **Regulatory minimalism.** Protocol does not handle XMR; arguably just a price feed plus a matching board. + +### High-level flow + +``` + sXMR LEZ program oracle (XMR/USD) Oracle program on LEZ + (token + stable vault) <----------------- + + mint | burn + + Intent gossip match Open XMR LPs + (off-chain, via Logos (anonymous, free + Delivery) to enter/exit) + sXMR <--> XMR quotes + + atomic swap (adaptor-sig) + LEZ <----------------------> Monero L1 + + sXMR holder gets XMR XMR LP gets sXMR, + on Monero L1 burns for stable +``` + +### Failure modes + +1. **LP exodus.** All XMR holders stop quoting. sXMR trades at an indefinite discount to oracle. +2. **Adverse selection.** LPs only show up when oracle is below true XMR price (free money for them) and vanish when oracle is above (would-be loss). Redemption is asymmetric across regimes. +3. **Demand asymmetry.** Easy to mint sXMR (privacy-curious DeFi users want it); harder to source LPs (XMR maximalists may not want a public LP role at all). +4. **User experience cost.** Monero atomic swap windows are 30 to 60 minutes; both parties must be online unless an intent layer is built on top. + +### When this fits + +- Privacy-maximalist user base willing to accept variable redemption. +- Use cases that need sXMR for trading exposure rather than guaranteed redemption (DeFi composability, hedging, speculation). +- Builders willing to ship the cryptographically pure version and let the market clear. + +## Cross-cutting design challenge + +Two questions that affect both Goal 1 and Goal 2. + +### The orderbook probably should not be on-chain + +An on-chain orderbook (whether on the canonical LEZ or anywhere else) is expensive, leaks intent publicly (which undermines the privacy story), and provides no security benefit: the atomic swap is what makes settlement trustless, not the matching layer. A better split: + +- **Off-chain matching via Logos Delivery.** LPs broadcast quotes; redeemers broadcast intents; parties pair up bilaterally. Quotes and intents never hit chain state. +- **On-chain settlement only.** A minimal LEZ program that verifies the atomic-swap primitive (lock, reveal, refund) on the LEZ side. It knows nothing about prices, identities, or who matched with whom. + +This also aligns better with the privacy proposition: an on-chain orderbook would be a public registry of "everyone trying to acquire real XMR right now." + +### Atomic-swap execution is hard to enforce on-chain + +Atomic swaps are deliberately symmetric: either party can refuse the next message at any stage, and both sides refund at timeout. On-chain evidence cannot distinguish: + +- An LP maliciously refusing to proceed. +- An LP whose node went down or lost connectivity. +- A redeemer never locking their side, making the LP's non-lock correct behaviour. +- A redeemer locking and then refusing to reveal, blaming the LP. + +This is the whole point of an atomic swap: nobody can be forced to complete, and nobody loses funds if they walk away. + +Critically, this means an atomic swap behaves like a free option for whichever party acts next. Stage by stage: + +1. **Alice (redeemer) locks sXMR on LEZ.** Bob (LP) now holds a free option: if the XMR price has moved in his favour since the quote, he locks his XMR and the swap proceeds; if it has moved against him, he simply does not lock. Alice's sXMR refunds at timeout. Bob has paid only the cost of waiting and gained the optionality of letting an adverse swap expire. +2. **Bob (LP) locks XMR on Monero.** Alice now holds the same free option in reverse. If the price has moved in her favour, she completes the swap by revealing the secret; if it has moved against her, she does not reveal. Both sides refund. Alice has paid only fees. +3. **Secret reveal.** Once the secret is revealed by either side, the swap completes; this is the only stage where the protocol is no longer optional. + +So at every stage before completion, the next party to act has a no-cost-beyond-fees option to abandon the swap based on price movement during the lock window. The "swap" is in effect a short-dated American option that either party can let expire. + +This is well-known in the atomic-swap literature (the "free option problem"). It is not a bug in any particular implementation; it is the cost of atomicity itself. The cross-cutting [trust-model contrast appendix](./cross-chain-trust-model-contrast.md) covers the mitigations in depth. + +Consequently, **a clean "LP defaulted, slash the bond" rule is not enforceable from on-chain state alone.** Refusing to proceed is *valid behaviour* under the protocol, not a default. Any slashing or "punishment" mechanism needs an off-chain attestation of who refused, which means one of: + +- A trusted attestor or committee deciding default, which reintroduces centralised trust. +- A reputation system, which is only useful at scale and cannot enforce against first-time defection. +- A multi-attestor oracle quorum watching both chains, which adds its own trust assumption and liveness requirement. + +Without one of those, the on-chain program can only do one thing: deny future LP slots, queue priority, or fee tiers. It cannot slash collateral with cryptographic certainty. + +### Implication for Goal 2 + +- **Goal 2a (bonded LPs)** is structurally weaker than its description suggests. The bond cannot be slashed on a simple "LP refused" condition; any real slashing requires a reputation or attestor system layered on top. Read the design as best-effort with a reputation layer (consuming the primitive from RFP-023), not as cryptographically guaranteed redemption. +- **Goal 2b (protocol reserve)** is unaffected by the symmetry problem; trust simply lives in the signer set instead. + +## Goal 2: always real XMR at oracle price + +The premise of RFP-025. sXMR must be redeemable for real XMR at (or very near) the oracle price, on demand. The atomic swap is still the settlement primitive, but counterparty availability is no longer left to the open market. The protocol either commits LPs to honour redemption or holds an XMR reserve itself. + +Two sub-designs, each restoring some trust that Goal 1 deliberately avoided. RFP-025 puts the choice between them to applicants. + +### Sub-design 2a: bonded LP set + +LPs join a registered set. Each LP posts stable collateral on LEZ equal to (or some multiple of) their XMR commitment. When a redemption request is routed to an LP, they must complete the atomic swap within a window. If they default, their bond is slashed and paid to the redeemer. LPs may leave the set, but only after a notice period that exceeds the redemption SLA. + +Enforceability caveat (see the cross-cutting section above): "LP defaulted" is not a verdict an on-chain program can render from atomic-swap state alone. Any slashing rule needs an off-chain attestor or a reputation system to attribute fault. Without one, the bond can be used to gate participation (priority, fee tiers, future-slot access) but not slashed with cryptographic certainty on a single failed swap. The realistic implementation consumes the RFP-023 reputation primitive as the attribution layer. + +``` + sXMR LEZ program + + LP registry + + slashing logic + + redemption request LP bond + + sXMR holder Bonded LP + burns sXMR, <----- atomic swap posts stable bond, + receives XMR (adaptor-sig, delivers XMR or + SLA) forfeits bond + + if LP defaults: bond is paid out as compensation, + reputation attests non-delivery +``` + +### Sub-design 2b: protocol XMR reserve + +The protocol accumulates an XMR reserve from mint fees, a yield programme, or a one-time treasury seed. Reserve is held in a threshold-signer multisig or analogous custody arrangement on Monero. Redemption draws from the reserve directly, with the atomic swap acting as the settlement rail between the reserve custodian and the redeemer. + +``` + sXMR LEZ program + + reserve accounting + + burn sXMR trigger swap + + Reserve module + (LEZ program) + + atomic swap + + Threshold-signer reserve on Monero + (n-of-m, bonded signers) +``` + +At this point the design has reinvented sBTC (Stacks) with an oracle bolted on. The atomic swap is just the wire format; trust lives in the signer set. The same view-key-shared TSS custody constraint applies as in RFP-021 (Serai-like federated middle chain): honest-but-curious signers learn the protocol-side deposit history. This is the structural trade-off Goal 2b accepts in exchange for the redemption SLA. + +### Properties comparison + +| Property | 2a Bonded LPs | 2b Protocol reserve | +|----------|---------------|---------------------| +| Custodian | None (LPs custody their own XMR) | Yes (signer set) | +| Redemption guarantee | Up to total bonded capacity | Up to reserve size | +| Slashing surface | Yes (bond slashed on default, attested via reputation) | No (reserve is the slashing) | +| Oracle role | Pricing plus default attestation | Pricing only | +| LP economics | Yield from spreads plus protocol incentives, less bond opportunity cost | Not applicable (no third-party LPs) | +| Decentralisation | High (anyone can be a bonded LP if they post the bond) | Low (signer set is gated) | +| Censorship resistance | Medium (LP set is registered) | Low (signers are known) | +| Best-case redemption speed | Atomic swap (30 to 60 min) | Atomic swap (30 to 60 min) | +| Failure mode | Bond runs out under coordinated default | Signer collusion or custody breach | + +### When this fits + +- Audiences that need a redemption SLA (institutions, market makers, structured products). +- Use cases where sXMR is collateral inside other protocols and a stable peg matters more than purist non-custody. +- Regulatory contexts where "guaranteed redemption" is a feature, not a liability. + +### Failure modes + +- **Bonded LPs (2a):** coordinated default exceeds bonded capacity; the slashing oracle for default attestation is itself a trusted component; bond opportunity cost limits LP supply. +- **Protocol reserve (2b):** signer set is a target; if reserve is undercollateralised, peg breaks; effectively recreates sBTC (Stacks) custody risk. The TSS custody also leaks deposit history to signers (the Monero privacy break called out in the [trust-model contrast appendix](./cross-chain-trust-model-contrast.md)). + +## Property matrix across goals + +| Property | Goal 1 (pure) | Goal 2a (bonded LPs) | Goal 2b (reserve) | sBTC (reference) | +|----------|---------------|----------------------|-------------------|------------------| +| Custodian | None | None (LPs self-custody) | Yes | Yes | +| Reserve | None | None | Yes | Yes | +| Redemption guarantee | None | Bounded by bonds | Bounded by reserve | Bounded by reserve | +| Peg type | Soft | Hard within capacity | Hard within capacity | Hard 1:1 | +| Oracle dependency | Pricing | Pricing plus default attestation | Pricing | None for peg | +| LP role | Optional, open | Registered, bonded | None | None | +| Privacy on redemption | Yes (XMR L1) | Yes (XMR L1) | Yes (XMR L1) | No (BTC L1) | +| Worst-case failure | Indefinite discount, no exit | Bond depleted, partial exit | Signer compromise, full loss | Signer compromise, full loss | +| Closest existing analogue | DEX trading pair | Bonded relay (no direct analogue) | sBTC (Stacks) | sBTC (Stacks) | + +## Decision tree + +``` + Does the design need a redemption SLA? + + no yes + + + Goal 1 (pure) Does the protocol accept custody risk? + RFP-024 + no yes + + + Goal 2a (bonded LPs) Goal 2b (reserve) + RFP-025 option (a) RFP-025 option (b) + (oracle-priced sBTC) +``` + +## Pre-spec validation + +Before committing to either goal, applicants should validate: + +1. **Atomic swap UX with Monero today.** Live protocols (eigenwallet/unstoppableswap fork of comit-network/xmr-btc-swap, Farcaster) take 30 to 60 minutes and require both parties online. Confirm async or intent-based variants are production-grade before designing UX around them. +2. **LP supply.** Will XMR holders actually LP? They self-select for privacy maximalism and may not want a public on-chain LP role. The LP side is the bottleneck; validate before designing the rest. +3. **Bond economics (Goal 2a only).** Required bond size as a multiple of XMR notional; opportunity cost of locked stable collateral on LEZ; expected APY needed to attract bonded LPs. +4. **Signer set sourcing (Goal 2b only).** Same problem space as sBTC (Stacks); revisit that project's trust assumptions before reinventing them. Also revisit RFP-021's federated-middle-chain trust analysis, which covers the same TSS custody design space. +5. **Regulatory.** A synthetic that terminates in a privacy coin will draw scrutiny under any of the three designs. Goal 1 has the cleanest defence (protocol is a price feed and a matching board); Goal 2b has the weakest (protocol custodies XMR). + +## Bottom line + +- **Goal 1 (RFP-024)** is the most interesting design and the one with the strongest privacy story. It will not satisfy users who expect a redemption SLA. +- **Goal 2a (RFP-025 option a)** is the most novel of the SLA-bearing designs: non-custodial, atomic-swap-settled, but with bonded LPs underwriting redemption capacity. No direct analogue exists in the published landscape. Depends on RFP-023 reputation for default attribution. +- **Goal 2b (RFP-025 option b)** is a real product but, structurally, an oracle-priced sBTC (Stacks) for Monero. The atomic swap is cosmetic; the trust assumption is the signer set. + +Pick the goal before writing the spec. The three designs have different threat models, different LP economics, and different regulatory exposures. + +## References + +- [sBTC (Stacks) Bitcoin layer documentation](https://docs.stacks.co/concepts/sbtc) +- [Synthetix V3 documentation](https://docs.synthetix.io/v/v3/) +- [eigenwallet/core (XMR atomic swap fork of comit-network/xmr-btc-swap)](https://github.com/eigenwallet/core) +- [Farcaster project](https://github.com/farcaster-project) +- [Bitcoin to Monero atomic swaps (getmonero.org)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) From ba4adfda0c1ef9b8f01441162c0d22bc5cba1d6d Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 21 May 2026 18:44:42 +1000 Subject: [PATCH 02/17] rfp: convert ASCII diagrams to Mermaid, fix IACR citation - RFP-021: replace the labels-only ASCII architecture sketch with a Mermaid flowchart that shows the validator set, the per-curve TSS vaults, and the LEZ execution layer (AMM plus privacy primitives) with proper connections. - RFP-022: replace the Tier 1 ASCII swimlane with a Mermaid sequenceDiagram covering phases 0 through 5 (Quote, Commit, Lock-BTC, Lock-Logos, Reveal, Settle) with explicit slash-window notes. - appendix/cross-chain-trust-model-contrast.md line 53: fix the inline citation of the Hoenisch and del Pino BTC-XMR atomic-swap paper from "IACR 2021/441" to "IACR 2020/1126". The URL was already correct and the references block (line 208) and RFP-022 (line 135) had the right identifier; only the inline mention was wrong. Co-Authored-By: Claude Opus 4.7 (1M context) --- RFPs/RFP-021-cross-chain-privacy-dex.md | 43 +++++++++----- RFPs/RFP-022-bonded-atomic-swaps.md | 61 +++++++++++--------- appendix/cross-chain-trust-model-contrast.md | 2 +- 3 files changed, 61 insertions(+), 45 deletions(-) diff --git a/RFPs/RFP-021-cross-chain-privacy-dex.md b/RFPs/RFP-021-cross-chain-privacy-dex.md index 0b2a787..ceb17bd 100644 --- a/RFPs/RFP-021-cross-chain-privacy-dex.md +++ b/RFPs/RFP-021-cross-chain-privacy-dex.md @@ -31,22 +31,33 @@ This is the most ambitious option in the cross-chain bundle. It is also the one ## High-level functionality and flow -``` - LEZ validator set (~100-600 nodes, bonded) - FROST threshold signatures per external curve - - - ETH vault BTC vault XMR vault - (secp256k1) (secp256k1) (Ed25519, FROSTLASS over CLSAG) - - AMM pools on LEZ - (xy=k, native asset settlement) - - + Privacy layer: - - shielded swap intents - - sealed-bid batch matching - - stealth outbound addresses - - Waku transport for orderflow +```mermaid +flowchart TB + subgraph Validators["LEZ validator set (100-600 nodes, bonded)"] + direction LR + V1["Validator 1"] + V2["Validator 2"] + Vn["Validator N"] + V1 --- V2 --- Vn + end + + subgraph Vaults["TSS vaults (FROST threshold signatures, per curve)"] + direction LR + ETHVault["ETH vault
(secp256k1)"] + BTCVault["BTC vault
(secp256k1)"] + XMRVault["XMR vault
(Ed25519, FROSTLASS over CLSAG)"] + end + + subgraph Execution["LEZ execution"] + direction TB + AMM["AMM pools
(xy=k, native-asset settlement)"] + Privacy["Privacy layer:
- shielded swap intents
- sealed-bid batch matching
- stealth outbound addresses
- Waku transport for orderflow"] + AMM --- Privacy + end + + Validators -->|"co-sign deposits/outbounds"| Vaults + Vaults -->|"observed deposits feed swap engine"| Execution + Execution -->|"queued outbounds signed via TSS"| Vaults ``` **Happy path.** User sends BTC to a vault address on Bitcoin, carrying a memo (or, with LEZ privacy primitives, a commitment) that specifies the destination asset and address. LEZ validators observe the deposit, reach consensus via their consensus protocol, route the swap through the appropriate AMM pool, queue the outbound, and the threshold signature group co-signs an outbound transaction on the destination chain. Outbound is broadcast to a stealth address derived from the destination address. Total wall-clock time: source-chain finality plus LEZ consensus plus destination-chain finality, typically minutes. diff --git a/RFPs/RFP-022-bonded-atomic-swaps.md b/RFPs/RFP-022-bonded-atomic-swaps.md index 3e068fd..2835ced 100644 --- a/RFPs/RFP-022-bonded-atomic-swaps.md +++ b/RFPs/RFP-022-bonded-atomic-swaps.md @@ -36,34 +36,39 @@ The Bond layer is a strict superset of RFP-003. Builders should consume the per- ### Tier 1: LEZ to BTC (example) -``` -Phase Alice LEZ contract Bob - -0. Quote <----------- Logos Delivery ----------> - Joint-key setup for 2-of-2 Taproot output - -1. Commit post B_alice - (LEZ-side bond) --> receives B_alice - -2. Lock-BTC sign BTC lock tx --> over Waku --> broadcast to BTC - - <-- inclusion proof from anyone --> verifies PoW, merkle, scriptpubkey, amount - - slash window opens if Bob does not advance: - B_bob_slice goes to Alice - -3. Lock-Logos (waits) <-- receives Bob locks trade_amount - trade_amount + + B_bob_slice - B_bob_slice conditioned on secret s - -4. Reveal publishes adaptor sig --> reveals s - if Alice does not reveal: - B_alice goes to Bob - -5. Settle <-- Alice's bond Bob claims BTC using s - refunds - Bob's bond slice - releases +```mermaid +sequenceDiagram + participant Alice + participant LEZ as LEZ swap contract + participant BTC as Bitcoin network + participant Bob + + Note over Alice,Bob: Phase 0 - Quote + Alice->>Bob: Quote request (Logos Delivery) + Bob->>Alice: Signed quote (price, expiry, swap_id, refund_pubkeys) + Note over Alice,Bob: Joint-key setup for 2-of-2 Taproot output + + Note over Alice,LEZ: Phase 1 - Commit + Alice->>LEZ: Post B_alice referencing swap_id + + Note over Alice,Bob: Phase 2 - Lock-BTC + Alice->>Bob: Signed BTC lock tx bytes (over Waku) + Bob->>BTC: Broadcast lock tx (or Alice broadcasts herself if Bob stalls) + BTC-->>LEZ: Inclusion proof (submitted by anyone:
headers + merkle + raw_tx) + LEZ->>LEZ: Verify PoW, inclusion, scriptpubkey, amount + Note over LEZ: Slash window opens
If Bob does not advance:
B_bob_slice -> Alice + + Note over LEZ,Bob: Phase 3 - Lock-Logos + Bob->>LEZ: Lock trade_amount + B_bob_slice conditioned on s + + Note over Alice,LEZ: Phase 4 - Reveal + Alice->>LEZ: Publish adaptor signature (reveals s) + Note over LEZ: If Alice does not reveal in window:
B_alice -> Bob + + Note over Bob,BTC: Phase 5 - Settle + Bob->>BTC: Claim BTC using s + LEZ-->>Alice: Refund B_alice + LEZ-->>Bob: Release B_bob_slice ``` The unauthenticated proof submitter property: Bob can broadcast Alice's signed BTC lock himself; the LEZ inclusion-proof submitter is also unauthenticated (Bob, Alice, or a watchtower service can post the proof). If Alice signs a malformed lock (wrong amount, wrong scriptpubkey), Bob does not broadcast; the tx never lands on Bitcoin; the inclusion proof never materialises; the LEZ state machine quietly times out. No slashing dispute, no fraud-proof window. The swap fails closed because the precondition for state advancement (a real BTC lock) never holds. diff --git a/appendix/cross-chain-trust-model-contrast.md b/appendix/cross-chain-trust-model-contrast.md index 16fe323..daa8f01 100644 --- a/appendix/cross-chain-trust-model-contrast.md +++ b/appendix/cross-chain-trust-model-contrast.md @@ -50,7 +50,7 @@ Cons: 2. **Settlement time dominated by the slowest chain.** A single swap can take 30 minutes to several hours to finalise because confirmations stack across both chains. Refund timelocks are measured in hours, not minutes. 3. **Mandatory interactivity for both parties.** Both parties must be online for lock, reveal, and (in adversarial paths) refund. If Alice goes offline mid-swap, Bob waits out the refund window, and vice versa. 4. **Per-trade matching.** No protocol-owned liquidity, no AMM pricing; each swap requires a willing counterparty for the exact pair and exact size. -5. **Pair coverage.** HTLC requires compatible scripting on both chains. BTC-XMR specifically required about five years of cryptographic work (2017 proposal to 2021 working implementation via adaptor signatures over Ed25519 and secp256k1). Source: [getmonero.org: Bitcoin to Monero atomic swaps are now live, 2021-08-20](https://www.getmonero.org/2021/08/20/atomic-swaps.html); [Hoenisch and del Pino, IACR 2021/441](https://eprint.iacr.org/2020/1126.pdf). +5. **Pair coverage.** HTLC requires compatible scripting on both chains. BTC-XMR specifically required about five years of cryptographic work (2017 proposal to 2021 working implementation via adaptor signatures over Ed25519 and secp256k1). Source: [getmonero.org: Bitcoin to Monero atomic swaps are now live, 2021-08-20](https://www.getmonero.org/2021/08/20/atomic-swaps.html); [Hoenisch and del Pino, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf). Cons (1) through (3) are the ones the design space can plausibly attack without abandoning the atomic-swap model entirely. (4) is structural: "fixing" it by adding protocol-owned liquidity reinvents the middle-chain DEX. (5) is a per-pair engineering cost paid once. From f7575a76739cdf90531f0c19c16d1533ecaf4b5c Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 21 May 2026 19:53:11 +1000 Subject: [PATCH 03/17] rfp: apply fact-check fixes across the bundle Findings consolidated from seven parallel fact-check agents (one per new file). Fixes applied as a single follow-up commit. Citation corrections: - IACR ePrint 2020/1126 is "Bitcoin-Monero Cross-chain Atomic Swap" by Joel Gugger, not Hoenisch and del Pino. The Hoenisch/del Pino paper "Atomic Swaps between Bitcoin and Monero" is arXiv:2101.12332. The earlier "fix" commit (ba4adfd) swapped one wrong attribution (IACR 2021/441) for another (IACR 2020/1126 / Hoenisch and del Pino). Now cites both papers correctly: Gugger 2020/1126 and Hoenisch/del Pino arXiv:2101.12332. Affects RFP-022 line 135 and appendix line 53/References. - Broken URLs replaced: getmonero.org/resources/moneropedia/fcmp.html -> getmonero.org/2024/04/27/fcmps.html (the canonical FCMP++ post); citrea.xyz/learn/clementine -> docs.citrea.xyz/essentials/ clementine-trust-minimized-bitcoin-bridge; LLFourn/one-time-vrf -> LLFourn/one-time-VES (correct repo); wormhole.com/docs/learn/ security -> wormhole.com/docs/protocol/infrastructure/guardians (which actually contains "Security through reputation, not tokens"); docs.stacks.co/concepts/sbtc -> docs.stacks.co/learn/sbtc (post-redirect canonical URL). - Synthetix V3 docs link replaced with SIP-302, the primary source describing snxUSD-minting against collateral. The previously cited /v/v3/ page documents perps trading only. - Inline Thorchain bond-to-pooled ratio (2:1 + 1:1) was cited via the Serai Validator Sets spec and the Thorchain CLP page, neither of which document that ratio. Cite docs.thorchain.org/understanding- thorchain/rune instead. - Liquality "$35M lifetime volume" originally cited defiprime.com which does not state the figure. Reframed as widely-cited marketing copy without primary anchor. Substantive claim revisions: - Tier 2 Monero cryptography text in RFP-022 line 21 tightened: "reveals either the per-tx private key or the recipient view key (plus the output blinding factor), each of which is sufficient to deanonymise the swap output". Reflects the distinction between OutProofV2 (tx_secret_key) and InProofV2 (view secret key). Cites Zero to Monero 2.0 inline. - Wedge claim "the only synthetic in the published landscape" was overclaimed: Synthetix's historical sXMR paired with the Secret Network Monero Bridge already offers XMR-L1 redemption under signer-set custody; Haven Protocol's xAsset family offered privacy-chain synthetics (closed Dec 2024). Narrowed to "the only currently published, live synthetic whose redemption deposits real XMR on Monero L1 *non-custodially, via peer-to-peer atomic swap*". Affects RFP-024 and the sxmr-design-space appendix. - "Reinvented sBTC with an oracle bolted on" framing in RFP-025 option 2b corrected: sBTC is 1:1 redemption-backed, not oracle- priced. The structural overlap is the threshold-signer custody model; the peg semantics differ. Reworded throughout. - Serai timeline in RFP-021 corrected: "roughly six years" -> "roughly five years" (Serai dev began 2021, not 2020). "post-audit as of 2026-04" -> "post-cryptographic-audit by Cypher Stack in May 2025; mainnet not yet launched". - Thorchain cumulative volume updated from $112B to >$120B per DefiLlama dashboard, with access date. - Wormhole reputation analogy in RFP-023 and the appendix softened: Wormhole is 19 hand-picked PoA signers, not a permissionless reputation-accruing population. RFP-023 premise reframed as a design conjecture rather than a proven theorem. - Wormhole Feb 2022 categorisation in RFP-025 fixed: was listed under "signer collusion / key compromise / signing-software bug"; actually a per-chain bridge-contract bug (load_instruction_at) that bypassed the signer set entirely. Recategorised. - Settlement-time claim "30 to 60 minutes per swap" repeated five times across the bundle without primary source. Hedged to "Monero-confirmation-bound; typically under an hour but with variance from network conditions". Applicants asked to measure against a recent client release rather than rely on the indicative range. - "About five years (2017 proposal to 2021 implementation)" was four years. Corrected. - COMIT xmr-btc-swap "archived as of 2024-11" -> "unmaintained since 2024-11; archival pending per issue #1791" (the repo is not actually flagged as archived on GitHub). - Thorchain TSS incident dated more precisely: "May 2026" -> "2026-05-15" where applicable. Wormhole "February 2022" -> "2022-02-02" where applicable. Citation hygiene: - Inline citation added for sBTC-redeems-to-BTC claim in RFP-024. - Demand-asymmetry and adverse-selection claims in RFP-024 marked as predicted behaviour ("predicted demand asymmetry", "predicted adverse selection") rather than stated facts. - "(accessed 2026-05-21)" added to all external citations across the seven new files, matching the inline-citation convention used by the sibling appendix lez-vs-dedicated-zone.md. - Han et al. IACR 2019/896 added as the canonical "free option problem" reference in the sxmr-design-space appendix. No changes to the Mermaid diagrams added in commit ba4adfd. Co-Authored-By: Claude Opus 4.7 (1M context) --- RFPs/RFP-021-cross-chain-privacy-dex.md | 30 +++++++------ RFPs/RFP-022-bonded-atomic-swaps.md | 31 +++++++------ RFPs/RFP-023-reputation-atomic-swaps.md | 11 ++--- RFPs/RFP-024-synthetic-xmr-pure.md | 20 +++++---- RFPs/RFP-025-synthetic-xmr-sla.md | 21 ++++----- appendix/cross-chain-trust-model-contrast.md | 46 ++++++++++---------- appendix/sxmr-design-space.md | 23 ++++++---- 7 files changed, 100 insertions(+), 82 deletions(-) diff --git a/RFPs/RFP-021-cross-chain-privacy-dex.md b/RFPs/RFP-021-cross-chain-privacy-dex.md index ceb17bd..391b719 100644 --- a/RFPs/RFP-021-cross-chain-privacy-dex.md +++ b/RFPs/RFP-021-cross-chain-privacy-dex.md @@ -15,7 +15,7 @@ category: Applications & Integrations Build a cross-chain privacy DEX on LEZ that custodies external assets (BTC, ETH, XMR, and others) via a threshold signature scheme held by the LEZ validator set, executes swaps natively against an AMM, and adds LEZ-specific privacy primitives (shielded swap intents, sealed-bid batch matching, stealth outbound addresses) that the existing comparators (Thorchain, Serai, Maya, Chainflip) do not offer. -The design follows the **federated-signer middle chain** pattern that Thorchain ($112B cumulative volume since 2021) and Serai (pre-mainnet, post-audit as of 2026-04) have converged on. RFP-021 inherits that pattern's well-understood AMM-style liquidity and one-step user experience, then layers LEZ's privacy execution primitives on top to close the privacy gap that every comparator leaves open: even Serai's middle-chain state is publicly readable, and Thorchain's source-chain memos link source and destination addresses on transparent ledgers before the middle chain even sees them. +The design follows the **federated-signer middle chain** pattern that Thorchain (over $120B cumulative volume since 2021 per DefiLlama, accessed 2026-05-21) and Serai (pre-mainnet, post-cryptographic-audit by Cypher Stack in May 2025) have converged on. RFP-021 inherits that pattern's well-understood AMM-style liquidity and one-step user experience, then layers LEZ's privacy execution primitives on top to close the privacy gap that every comparator leaves open: even Serai's middle-chain state is publicly readable, and Thorchain's source-chain memos link source and destination addresses on transparent ledgers before the middle chain even sees them. This is the most ambitious option in the cross-chain bundle. It is also the one with the strongest empirical case (volume, user experience, asset coverage) and the strongest custody risk. @@ -70,7 +70,7 @@ flowchart TB ## Pros -- **Highest deployed-volume model.** Thorchain has cleared $112B cumulative cross-chain volume since 2021 ([DefiLlama Thorchain DEX](https://defillama.com/protocol/thorchain-dex)). The AMM-style middle-chain pattern wins on liquidity gravity and user experience over every atomic-swap competitor. +- **Highest deployed-volume model.** Thorchain has cleared over $120B cumulative cross-chain volume since 2021 ([DefiLlama Thorchain DEX](https://defillama.com/protocol/thorchain-dex), accessed 2026-05-21). The AMM-style middle-chain pattern wins on liquidity gravity and user experience over every atomic-swap competitor. - **Sub-block-time settlement on the middle chain.** Only destination-chain finality and the TSS keysign delay the outbound. No multi-hour timelock windows. - **Arbitrary asset pairs.** Pair coverage is reduced to "does the validator set run an observer for chain X". BTC, ETH, XMR all in scope at launch. - **Cryptoeconomic recourse.** Misbehaviour is slashable. The economic security argument is explicit and bounded. @@ -79,15 +79,15 @@ flowchart TB ## Cons -- **Custody risk is real and realised.** Thorchain's GG20 TSS vault was drained in May 2026 ($10.8M) via a TSSHOCK-class implementation weakness. Wormhole's Solana bridge was drained in February 2022 ($326M) via a per-chain contract bug; Jump Crypto re-deposited the loss out of pocket. The federated middle-chain pattern has a non-zero historical loss rate. +- **Custody risk is real and realised.** Thorchain's GG20 TSS vault was drained on 2026-05-15 ($10.8M) via a TSSHOCK-class implementation weakness. Wormhole's Solana bridge was drained on 2022-02-02 ($326M) via a per-chain contract bug (`load_instruction_at`); Jump Crypto re-deposited the loss out of pocket. The federated middle-chain pattern has a non-zero historical loss rate. - **Signer federation is a chokepoint.** Validators are identifiable; the validator set is a target for out-of-protocol pressure (legal, regulatory, kinetic). The federation cannot be made "fully decentralised" in the sense that an atomic-swap design can. - **Pre-economic-security bootstrap.** Serai's mint-on-bootstrap design illustrates that the slashable-bond argument does not bind until the validator-stake pool catches up with custody. The launch window is a real risk. - **XMR privacy compromise.** Any TSS custody of Monero is necessarily view-key-shared: the validator set learns the LEZ-side Monero deposit history. This is the same compromise Serai accepts (FROSTLASS over CLSAG); it must be called out plainly to users, not papered over. -- **Engineering surface is large.** Building a new chain, a per-external-chain observer fleet, a TSS scheme with serious audit posture, churn/migration logic, and an emergency halt is a multi-year programme. Serai took roughly six years from inception to post-audit pre-mainnet. +- **Engineering surface is large.** Building a new chain, a per-external-chain observer fleet, a TSS scheme with serious audit posture, churn/migration logic, and an emergency halt is a multi-year programme. Serai took roughly five years from inception (around 2021) to post-cryptographic-audit pre-mainnet status (Cypher Stack audits completed May 2025; mainnet not yet launched as of 2026-05-21). ## Risks -- **TSS implementation failure.** The May 2026 Thorchain incident is the canonical example. Mitigation: choose FROST over GG20 (Serai's choice, and the lesson Thorchain's incident reinforces); budget for at least one Cypher Stack-equivalent audit of the chosen scheme; design with FROSTLASS-grade Monero support from the start rather than retrofitting. +- **TSS implementation failure.** The 2026-05-15 Thorchain incident is the canonical example. Mitigation: choose FROST over GG20 (Serai's choice, and the lesson Thorchain's incident reinforces); budget for at least one Cypher Stack-equivalent audit of the chosen scheme; design with FROSTLASS-grade Monero support from the start rather than retrofitting. - **Per-external-chain contract risk.** Wormhole's 2022 incident bypassed rather than broke the trust model: a Solana-side `load_instruction_at` bug let an attacker forge VAAs. Every integrated chain adds an attack surface independent of the LEZ consensus. Mitigation: minimise per-chain on-chain components; lean on TSS-signed outputs to chains with no LEZ-deployed contract. - **Validator-set capture.** A small or homogeneous validator set is a censorship and coercion target. Mitigation: stake-weighted permissionless entry; geographic and jurisdictional diversity as a soft target. - **Pre-mainnet economic-security gap.** Slashable-bond security depends on stake value catching up with custody value. Mitigation: explicit caps on custody until the bond-to-custodied ratio binds; transparent on-protocol ratio enforcement (Thorchain's Incentive Pendulum is one mechanism). @@ -105,12 +105,14 @@ See [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust ## References -- [DefiLlama Thorchain DEX (volume figures)](https://defillama.com/protocol/thorchain-dex) -- [Serai AMM docs](https://docs.serai.exchange/amm/) -- [Serai blog: Announcing monero-oxide (2025-09-09)](https://serai.exchange/2025/09/09/monero-serai-oxide.html) -- [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md) -- [Thorchain Medium: Why Cross-Chain bridges are superior to Atomic Swaps (2019)](https://medium.com/thorchain/why-cross-chain-bridges-are-superior-to-atomic-swaps-aebde263103c) -- [Thorchain docs: Continuous Liquidity Pools](https://docs.thorchain.org/technical-documentation/thorchain-finance/continuous-liquidity-pools) -- [Crypto Times: $10.8M drained from Thorchain (2026-05-17)](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) -- [Halborn: Wormhole Hack February 2022](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) -- [FROST paper (Komlo and Goldberg)](https://eprint.iacr.org/2020/852) +- [DefiLlama Thorchain DEX (volume figures)](https://defillama.com/protocol/thorchain-dex) (accessed 2026-05-21) +- [Serai AMM docs](https://docs.serai.exchange/amm/) (accessed 2026-05-21) +- [Serai blog: Announcing monero-oxide (2025-09-09)](https://serai.exchange/2025/09/09/monero-serai-oxide.html) (accessed 2026-05-21) +- [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md) (accessed 2026-05-21) +- [Serai blog: How Far We've Come (2023-10-06)](https://serai.exchange/2023/10/06/how-far-weve-come.html) (accessed 2026-05-21) +- [Thorchain Medium: Why Cross-Chain bridges are superior to Atomic Swaps (2019)](https://medium.com/thorchain/why-cross-chain-bridges-are-superior-to-atomic-swaps-aebde263103c) (accessed 2026-05-21) +- [Thorchain docs: Continuous Liquidity Pools](https://docs.thorchain.org/technical-documentation/thorchain-finance/continuous-liquidity-pools) (accessed 2026-05-21) +- [Thorchain docs: RUNE (bond-to-pooled ratio)](https://docs.thorchain.org/understanding-thorchain/rune) (accessed 2026-05-21) +- [Crypto Times: $10.8M drained from Thorchain on 2026-05-15](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) (accessed 2026-05-21) +- [Halborn: Wormhole Hack February 2022](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) (accessed 2026-05-21) +- [FROST: Flexible Round-Optimized Schnorr Threshold Signatures (Komlo and Goldberg, SAC 2020 / IACR 2020/852)](https://eprint.iacr.org/2020/852) (accessed 2026-05-21) diff --git a/RFPs/RFP-022-bonded-atomic-swaps.md b/RFPs/RFP-022-bonded-atomic-swaps.md index 2835ced..e07a449 100644 --- a/RFPs/RFP-022-bonded-atomic-swaps.md +++ b/RFPs/RFP-022-bonded-atomic-swaps.md @@ -18,18 +18,18 @@ Extend RFP-003 (Atomic Swaps with LEZ, open) with a maker/taker bond layer on LE The design splits into two tiers that reflect a structural asymmetry in the underlying cryptography: - **Tier 1 (LEZ to BTC, LEZ to ETH).** Both sides' locks are verifiable on LEZ via a chain-watching light-client module. Both Alice's and Bob's bonds are slashable on default; full bilateral free-option mitigation. -- **Tier 2 (LEZ to XMR).** Alice's XMR lock cannot be proven on LEZ without view-key disclosure to public state, because Monero has no SPV-style proof primitive that does not reveal the per-tx private key and blinding factor. Bob's lock (on LEZ) remains observable, so Bob's bond is slashable; Alice's bond is slashable only on her LEZ-observable abandonment (failure to reveal after Bob has locked Logos). Alice keeps a residual pre-XMR-lock free option that only reputation (RFP-023) can constrain. +- **Tier 2 (LEZ to XMR).** Alice's XMR lock cannot be proven on LEZ without revealing either the per-tx private key or the recipient view key (plus the output blinding factor), each of which is sufficient to deanonymise the swap output once submitted to world-readable LEZ state. Monero's bilateral `check_tx_proof` (OutProofV2 or InProofV2 variants per [Zero to Monero 2.0 §Payment Proofs](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf)) is the canonical disclosure-requiring proof; no SPV-style alternative exists pre-FCMP++. Bob's lock (on LEZ) remains observable, so Bob's bond is slashable; Alice's bond is slashable only on her LEZ-observable abandonment (failure to reveal after Bob has locked Logos). Alice keeps a residual pre-XMR-lock free option that only reputation (RFP-023) can constrain. The Bond layer is a strict superset of RFP-003. Builders should consume the per-pair SDKs from RFP-003 unchanged; this RFP adds the bond escrow contract, the bond accounting, and the LEZ-side proof verification primitives. ## Desired properties - **Non-custodial.** No vault holds external assets; no signer set. Bonds live in LEZ-native assets on LEZ. -- **Free-option mitigation (Tier 1).** Symmetric bonding makes both sides' optionality strictly EV-negative when bonds are sized above the option value (`σ × √T × notional`, around 2 to 5% of trade notional for 1-hour windows). +- **Free-option mitigation (Tier 1).** Symmetric bonding makes both sides' optionality strictly EV-negative when bonds are sized above the option value (`σ × √T × notional` is the standard option-pricing heuristic; an indicative range is 2 to 5% of trade notional for 1-hour windows, to be validated by applicants against actual observed BTC/ETH volatility). - **Free-option mitigation (Tier 2).** Bob's optionality is closed by his slashable bond. Alice's post-Bob-lock optionality is closed by her bond. Alice's pre-XMR-lock optionality is *not* closed; this is the structural limit of the asymmetry. - **Unauthenticated proof submitter.** Either party can broadcast the other's signed lock transaction (broadcasting is permissionless on every supported chain). The LEZ inclusion-proof submitter is also unauthenticated. This eliminates "attest or be slashed" grief vectors: a malformed lock simply never lands, the state machine times out, no slashing dispute occurs. - **Bondless taker entry path.** First-time takers can complete a capped first swap (worked example: US$100 equivalent notional) without posting a taker bond. After the first swap, the taker has LEZ-denominated assets they can post as bond against larger swap sizes. This is enforceable by the LEZ escrow program directly; no reputation registry needed. -- **Upgrade clause for Tier 2.** When a non-disclosing Monero proof primitive becomes production-ready (FCMP++ or equivalent), Tier 2 collapses into Tier 1: Alice's XMR lock becomes verifiable on LEZ without view-key disclosure, and the residual free option closes. +- **Upgrade clause for Tier 2.** When a non-disclosing Monero proof primitive becomes production-ready (FCMP++ or equivalent; in specification phase per [Monero, FCMP++ announcement, 2024-04-27](https://www.getmonero.org/2024/04/27/fcmps.html), accessed 2026-05-21), Tier 2 collapses into Tier 1: Alice's XMR lock becomes verifiable on LEZ without view-key disclosure, and the residual free option closes. - **Composes with RFP-023 reputation.** Maker reputation (and zk-membership-proof taker reputation if available) compounds the cost of defection. In Tier 2 specifically, taker reputation is load-bearing because it is the only restraint on Alice's pre-lock free option. ## High-level functionality and flow @@ -130,14 +130,17 @@ See [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust ## References - [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) -- [eth-lez-atomic-swaps reference implementation](https://github.com/logos-co/eth-lez-atomic-swaps) -- [Bitcoin to Monero atomic swaps (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) -- [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) -- [Adaptor signatures, Lloyd Fournier](https://github.com/LLFourn/one-time-vrf/blob/master/main.pdf) -- [Scriptless Scripts, Andrew Poelstra](https://github.com/apoelstra/scriptless-scripts) -- [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) -- [Citrea Clementine LCP](https://citrea.xyz/learn/clementine) -- [ZeroSync](https://zerosync.org/) -- [Monero whitepaper: Zero to Monero 2.0](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) -- [Monero FCMP overview](https://www.getmonero.org/resources/moneropedia/fcmp.html) +- [eth-lez-atomic-swaps reference implementation](https://github.com/logos-co/eth-lez-atomic-swaps) (accessed 2026-05-21) +- [Bitcoin to Monero atomic swaps (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) (accessed 2026-05-21) +- [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) (accessed 2026-05-21) +- [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332 (2021-01-29)](https://arxiv.org/abs/2101.12332) (accessed 2026-05-21) +- [comit-network/xmr-btc-swap (BTC-XMR adaptor-signature reference implementation; unmaintained since 2024-11)](https://github.com/comit-network/xmr-btc-swap) (accessed 2026-05-21) +- [eigenwallet/core (active fork of comit-network/xmr-btc-swap; v4.6.1, 2026-05-15)](https://github.com/eigenwallet/core) (accessed 2026-05-21) +- [LLFourn one-time-VES: Verifiably Encrypted Signatures (Lloyd Fournier, adaptor signatures)](https://github.com/LLFourn/one-time-VES/blob/master/main.pdf) (accessed 2026-05-21) +- [apoelstra/scriptless-scripts: atomic-swap protocol notes (Andrew Poelstra)](https://github.com/apoelstra/scriptless-scripts/blob/master/md/atomic-swap.md) (accessed 2026-05-21) +- [BIP-340: Schnorr signatures for secp256k1](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) (accessed 2026-05-21) +- [BIP-341: Taproot](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) (accessed 2026-05-21) +- [Citrea Clementine: Trust-Minimized Bitcoin Bridge](https://docs.citrea.xyz/essentials/clementine-trust-minimized-bitcoin-bridge) (accessed 2026-05-21) +- [ZeroSync](https://zerosync.org/) (accessed 2026-05-21) +- [Monero, Zero to Monero 2.0 (whitepaper, §Payment Proofs)](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) (accessed 2026-05-21) +- [Monero, FCMP++ announcement (2024-04-27)](https://www.getmonero.org/2024/04/27/fcmps.html) (accessed 2026-05-21) diff --git a/RFPs/RFP-023-reputation-atomic-swaps.md b/RFPs/RFP-023-reputation-atomic-swaps.md index ed90f95..4851e9d 100644 --- a/RFPs/RFP-023-reputation-atomic-swaps.md +++ b/RFPs/RFP-023-reputation-atomic-swaps.md @@ -15,7 +15,7 @@ category: Applications & Integrations Extend RFP-003 (Atomic Swaps with LEZ, open) with an on-chain reputation registry that constrains the free-option problem inherent to atomic swaps, *without* requiring bonded collateral as the primary cost-of-defection. -The premise: a maker who has completed N successful swaps with zero defections has built up a reputation asset whose net present value (discounted future fee revenue) exceeds the expected value of any single grief attack. The protocol does not need to slash bonded collateral; the *market* effectively slashes the maker by refusing future trades. Reputation is therefore a long-tailed bond the protocol does not have to size, hold, or directly enforce. +The premise (a design conjecture to be validated in implementation, not a proven theorem): a maker who has completed N successful swaps with zero defections has built up a reputation asset whose net present value (discounted future fee revenue) plausibly exceeds the expected value of any single grief attack. The protocol does not need to slash bonded collateral; the *market* effectively slashes the maker by refusing future trades. Reputation is therefore a long-tailed bond the protocol does not have to size, hold, or directly enforce. The closest deployed instance is Wormhole's Guardian set (Proof-of-Authority committee), which operates on the same economic argument under a different mechanism. The cryptographic challenge is taker reputation. Takers should be unlinkable across swaps (a privacy-positioned cross-chain DEX should not require its users to maintain a persistent on-chain identity that can be deanonymised). The RFP requires applicants to address two complementary design paths: a capped-pseudonym path (linkable, simple) and a zero-knowledge reputation path (unlinkable, complex, reusing the LEZ Risc0 zkVM that RFP-003 already establishes). @@ -142,7 +142,8 @@ See [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust ## References - [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) -- [Wormhole Guardian set design (reputation-as-bond at scale)](https://wormhole.com/docs/learn/security/) -- [Sparse Merkle Tree (Vitalik Buterin, "Optimizing sparse Merkle trees")](https://ethresear.ch/t/optimizing-sparse-merkle-trees/3751) -- [Risc0 zkVM](https://dev.risczero.com/) -- [Logos Delivery and Logos Chat (referenced from RFP-003)](https://github.com/logos-co/logos-docs) +- [Wormhole Guardian set (reputation-substituting-for-bond under Proof-of-Authority)](https://wormhole.com/docs/protocol/infrastructure/guardians/) (accessed 2026-05-21) +- [Wormhole 101: Guardians (supporting context)](https://wormhole.com/blog/wormhole-101-guardians) (accessed 2026-05-21) +- [Sparse Merkle Tree (Vitalik Buterin, "Optimizing sparse Merkle trees", ethresear.ch, 2018-10-09)](https://ethresear.ch/t/optimizing-sparse-merkle-trees/3751) (accessed 2026-05-21) +- [Risc0 zkVM](https://dev.risczero.com/) (accessed 2026-05-21) +- [Logos Delivery and Logos Chat (referenced from RFP-003)](https://github.com/logos-co/logos-docs) (accessed 2026-05-21) diff --git a/RFPs/RFP-024-synthetic-xmr-pure.md b/RFPs/RFP-024-synthetic-xmr-pure.md index 4b28c87..01ebcd0 100644 --- a/RFPs/RFP-024-synthetic-xmr-pure.md +++ b/RFPs/RFP-024-synthetic-xmr-pure.md @@ -15,7 +15,7 @@ category: Applications & Integrations Build a synthetic XMR token (sXMR) on LEZ that tracks the XMR price via oracle, is composable across LEZ DeFi, and redeems to real XMR via peer-to-peer atomic swap. The protocol holds no XMR, runs no signer set, and offers no redemption SLA. -The wedge: this is the only synthetic in the published landscape where the redemption path itself preserves privacy. sBTC (Stacks) redeems to public BTC; every other commodity synthetic (sETH, sLINK, perpetuals-collateralised positions) redeems to traceable transparent assets. sXMR is the first design where a successful redemption deposits real XMR on Monero L1, severing the public trail. +The wedge: this is the only currently published, live synthetic whose redemption deposits real XMR on Monero L1 *non-custodially, via peer-to-peer atomic swap*. sBTC (Stacks) redeems to a user-supplied public Bitcoin address (per [docs.stacks.co: sBTC-to-BTC withdrawal](https://docs.stacks.co/more-guides/sbtc/bridging-bitcoin/sbtc-to-btc), accessed 2026-05-21); every other commodity synthetic (sETH, sLINK, perpetuals-collateralised positions) redeems to traceable transparent assets. The closest prior art is custodial: Synthetix's historical sXMR token paired with the Secret Network Monero Bridge offered XMR-L1 redemption under signer-set custody (the same trust model RFP-025 option 2b accepts); Haven Protocol's xAsset family offered synthetics on a dedicated privacy chain but closed in December 2024 and never offered xXMR. RFP-024 is the first design where the redemption path itself preserves privacy *and* avoids custody. The honest framing: this is a synthetic with a soft, market-clearing peg, not a hard-redeemable synthetic. The oracle is the *quoted* price; the *achievable* price is whatever an XMR LP will swap for, when one is willing. Structurally closer to a DEX trading pair than to sBTC (Stacks). The product fits a privacy-maximalist audience that wants XMR-shaped exposure inside LEZ DeFi without depending on protocol-held custody. @@ -79,9 +79,9 @@ A user deposits a stable (or other LEZ-accepted asset) into the sXMR collateral - **Soft peg widens under stress without bound.** The achievable redemption price is the marginal LP quote. If LPs vanish, sXMR can trade at any discount to oracle; the protocol cannot intervene. - **No redemption SLA.** Users who want guaranteed redemption (institutions, market makers, structured products) cannot use sXMR directly under Goal 1; they need RFP-025. -- **Demand asymmetry.** It is easy to mint sXMR (privacy-curious DeFi users want XMR exposure inside LEZ); it is harder to source LPs (XMR maximalists may not want a public LP role at all, even pseudonymous). The LP side is the structural bottleneck. -- **Adverse selection of LPs.** LPs only show up when oracle is below true market XMR price (free money for them on the redemption leg) and vanish when oracle is above (would-be loss). Redemption availability is asymmetric across regimes. -- **Atomic-swap UX inherited.** 30 to 60 minutes per swap, both parties online. The intent layer over Logos Delivery softens this but cannot remove it. +- **Predicted demand asymmetry.** Mint demand is expected to be easy (privacy-curious DeFi users want XMR exposure inside LEZ); LP supply is expected to be harder to source (XMR maximalists may not want a public LP role at all, even pseudonymous). The LP side is the predicted structural bottleneck; applicants should validate against early LP onboarding before scaling. +- **Predicted adverse selection of LPs.** LPs are expected to show up when oracle is below true market XMR price (free money for them on the redemption leg) and to vanish when oracle is above (would-be loss). Redemption availability is expected to be asymmetric across regimes; analogous to uncollateralised peer-to-peer market-making in other venues but unverified for this product. +- **Atomic-swap UX inherited.** Settlement time is dominated by Monero block confirmations, typically under an hour but with variance from network conditions; both parties online for the duration. The intent layer over Logos Delivery softens this but cannot remove it. - **No protocol-side enforcement of LP behaviour.** Refusing to proceed is *valid behaviour* under the atomic-swap protocol; the protocol cannot distinguish malicious refusal from connectivity loss. Reputation (RFP-023) is the only available restraint, and even then it operates as soft pressure, not enforcement. - **Oracle dependency.** The oracle is the only price signal; oracle attack or stale price degrades minting accuracy. Mitigation lives outside this RFP (existing oracle RFPs in the bundle, or oracle aggregation patterns). @@ -111,7 +111,11 @@ See [appendix/sxmr-design-space.md](../appendix/sxmr-design-space.md) for the fu - [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) - [appendix/sxmr-design-space.md](../appendix/sxmr-design-space.md) - [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) -- [Synthetix V3 documentation (CDP-style collateral reference)](https://docs.synthetix.io/v/v3/) -- [Bitcoin to Monero atomic swaps (getmonero.org)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) -- [eigenwallet/core (XMR atomic swap fork of comit-network/xmr-btc-swap)](https://github.com/eigenwallet/core) -- [Farcaster project (XMR atomic swap, community-scale active)](https://github.com/farcaster-project) +- [Synthetix SIP-302: V3 collateral and snxUSD minting (CDP-style reference)](https://sips.synthetix.io/sips/sip-302/) (accessed 2026-05-21) +- [Bitcoin to Monero atomic swaps (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) (accessed 2026-05-21) +- [eigenwallet/core (XMR atomic swap, active fork of comit-network/xmr-btc-swap; v4.6.1, 2026-05-15)](https://github.com/eigenwallet/core) (accessed 2026-05-21) +- [Stacks docs: sBTC overview](https://docs.stacks.co/learn/sbtc) (accessed 2026-05-21) +- [Stacks docs: sBTC-to-BTC withdrawal](https://docs.stacks.co/more-guides/sbtc/bridging-bitcoin/sbtc-to-btc) (accessed 2026-05-21) +- [Secret Network Monero Bridge (custodial XMR-to-Secret Network reference, structural counter-example for the wedge)](https://docs.scrt.network/) (accessed 2026-05-21) +- [Haven Protocol shutdown notice (December 2024)](https://havenprotocol.org/) (accessed 2026-05-21) +- [Farcaster project (XMR atomic swap; low-velocity, last release v0.8.4 on 2023-01-16, last `farcaster-node` commit Aug 2024)](https://github.com/farcaster-project/farcaster-node) (accessed 2026-05-21) diff --git a/RFPs/RFP-025-synthetic-xmr-sla.md b/RFPs/RFP-025-synthetic-xmr-sla.md index e47d16b..09738f9 100644 --- a/RFPs/RFP-025-synthetic-xmr-sla.md +++ b/RFPs/RFP-025-synthetic-xmr-sla.md @@ -76,7 +76,7 @@ The protocol holds an XMR reserve in a threshold-signer multisig on Monero. Rede (n-of-m, bonded signers, view-key-shared) ``` -At this point the design has reinvented sBTC (Stacks) with an oracle bolted on. The atomic swap is the wire format; trust lives in the signer set. The same view-key-shared TSS custody constraint applies as in RFP-021: honest-but-curious signers learn the protocol-side deposit history. This is the structural trade-off option 2b accepts in exchange for the redemption SLA. The signer set must be bonded and slashable to make the trust assumption explicit. +At this point the design has adopted sBTC's (Stacks) threshold-signer custody model, with an oracle-priced peg layer replacing sBTC's 1:1 redemption peg. The structural overlap is the custody side (a bonded n-of-m signer set holding the underlying asset on its native chain); the peg semantics differ (sBTC is 1:1 redemption-backed, this design is oracle-priced). The atomic swap is the wire format; trust lives in the signer set. The same view-key-shared TSS custody constraint applies as in RFP-021: honest-but-curious signers learn the protocol-side deposit history. This is the structural trade-off option 2b accepts in exchange for the redemption SLA. The signer set must be bonded and slashable to make the trust assumption explicit. ## High-level functionality and flow (common) @@ -123,7 +123,7 @@ Identical to RFP-024. User deposits accepted LEZ collateral; protocol mints sXMR ## Cons (both options) - **Some form of trust returns.** RFP-024 (pure) trusts only the oracle and the atomic-swap protocol; RFP-025 trusts additionally an LP set (option 2a) or a signer set (option 2b). The cypherpunk story is weaker. -- **Atomic-swap UX is still inherited.** 30 to 60 minutes per redemption, both parties online. The SLA constrains the *availability* of the counterparty but not the cryptographic settlement time. +- **Atomic-swap UX is still inherited.** Settlement time is dominated by Monero block confirmations, typically under an hour but with variance from network conditions; both parties online for the duration. The SLA constrains the *availability* of the counterparty but not the cryptographic settlement time. - **Oracle dependency is sharper.** With an SLA on oracle-priced redemption, an oracle failure has SLA-breaking consequences, not just mint-side accuracy consequences. - **Regulatory exposure is higher.** A protocol that commits to redeeming a privacy coin on demand draws more scrutiny than RFP-024's price-feed-plus-matching-board posture. @@ -136,9 +136,9 @@ Identical to RFP-024. User deposits accepted LEZ collateral; protocol mints sXMR ## Cons (option 2b-specific) -- **Custodial.** A signer set holds real XMR on Monero. Custody risk is real: signer collusion, key compromise, or signing-software bug can drain the reserve. This is exactly the failure mode that hit Thorchain in May 2026 and Wormhole in February 2022. +- **Custodial.** A signer set holds real XMR on Monero. Custody risk is real: signer collusion, key compromise, or signing-software bug can drain the reserve. This is the failure mode that hit Thorchain on 2026-05-15 (TSS implementation weakness, $10.8M). The Wormhole February 2022 incident ($326M) is a related-but-distinct category: a per-chain bridge-contract bug (`load_instruction_at` on Solana) bypassed the signer set entirely rather than compromising it; the lesson is that per-chain contract surface adds attack vectors independent of the TSS itself. - **View-key-shared custody leaks Monero deposit history to signers.** The same compromise RFP-021 makes. Honest-but-curious signers learn the protocol-side Monero deposit history; this is the structural cost of TSS custody of XMR with current cryptography. -- **Effectively recreates sBTC (Stacks) with an oracle.** The novelty of the design is small relative to existing custodial XMR wraps (other than the LEZ privacy execution on the sXMR token side). +- **Adopts sBTC (Stacks)'s threshold-signer custody model, with an oracle-priced peg replacing 1:1 redemption.** The custody novelty is small relative to existing custodial XMR wraps (the differentiator is the LEZ privacy execution on the sXMR token side, plus the explicit slashable-signer-bond posture). - **Reserve undercollateralisation breaks the peg.** If the reserve is drawn down faster than it can be replenished from fees, redemption capacity goes to zero; sXMR loses its peg. - **Signer-set membership is gated.** Lower decentralisation than option 2a; signer set is a censorship and coercion target. @@ -158,7 +158,7 @@ Identical to RFP-024. User deposits accepted LEZ collateral; protocol mints sXMR - **Signer-set compromise.** A captured signer set can drain the entire reserve. Mitigation: large signer set (Serai uses up to 600; Thorchain ~100); permissionless entry; high bond-to-custodied ratio; emergency halt mechanism; geographic diversity. - **Signer-set offline event.** If the signer set cannot reach threshold to sign (network partition, mass node failure), redemption SLA breaks even with no malice. Mitigation: redundant signer geographic placement; documented signer SLOs; emergency-halt mechanism that pauses redemption gracefully rather than failing under load. -- **TSS implementation bug.** Thorchain's GG20 TSS exploit (May 2026, $10.8M) is the canonical example. Mitigation: choose FROST over GG20; budget for Cypher Stack-equivalent audit; isolate signer-software dependencies. +- **TSS implementation bug.** Thorchain's GG20 TSS exploit on 2026-05-15 ($10.8M) is the canonical example. Mitigation: choose FROST over GG20; budget for Cypher Stack-equivalent audit; isolate signer-software dependencies. ## Relationship to other RFPs in this bundle @@ -176,8 +176,9 @@ See [appendix/sxmr-design-space.md](../appendix/sxmr-design-space.md) for the Go - [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) - [appendix/sxmr-design-space.md](../appendix/sxmr-design-space.md) - [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) -- [sBTC (Stacks) Bitcoin layer documentation](https://docs.stacks.co/concepts/sbtc) -- [Synthetix V3 (CDP-style collateral reference)](https://docs.synthetix.io/v/v3/) -- [Crypto Times: Thorchain TSS exploit (2026-05-17)](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) -- [Halborn: Wormhole Hack February 2022](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) -- [FROST paper (Komlo and Goldberg)](https://eprint.iacr.org/2020/852) +- [sBTC (Stacks) Bitcoin layer documentation](https://docs.stacks.co/learn/sbtc) (accessed 2026-05-21) +- [sBTC withdrawal to a user-supplied Bitcoin address](https://docs.stacks.co/more-guides/sbtc/bridging-bitcoin/sbtc-to-btc) (accessed 2026-05-21) +- [Synthetix SIP-302: V3 collateral and snxUSD minting (CDP-style reference)](https://sips.synthetix.io/sips/sip-302/) (accessed 2026-05-21) +- [Crypto Times: $10.8M drained from Thorchain on 2026-05-15](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) (accessed 2026-05-21) +- [Halborn: Wormhole Hack on 2022-02-02 (technical analysis)](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) (accessed 2026-05-21) +- [FROST: Flexible Round-Optimized Schnorr Threshold Signatures (Komlo and Goldberg, SAC 2020 / IACR 2020/852)](https://eprint.iacr.org/2020/852) (accessed 2026-05-21) diff --git a/appendix/cross-chain-trust-model-contrast.md b/appendix/cross-chain-trust-model-contrast.md index daa8f01..72c7c4c 100644 --- a/appendix/cross-chain-trust-model-contrast.md +++ b/appendix/cross-chain-trust-model-contrast.md @@ -13,8 +13,8 @@ Examples: Thorchain (live since 2021), Serai (pre-mainnet as of 2026-05), Maya, What the user trusts: 1. A threshold of the validator set will not collude to spend from the vault. -2. The cryptographic primitive used to combine signer contributions is sound. Not a free assumption: Thorchain's GG20 TSS failed in production in May 2026, draining $10.8M from an Asgard vault via a TSSHOCK-class weakness. Source: [Crypto Times, 2026-05-17](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/). -3. The implementations on every external chain are correct. Not a free assumption either: a Solana-side `load_instruction_at` bug let an attacker forge a Wormhole VAA in February 2022 and mint 120k wETH unbacked ($326M). Source: [Halborn](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022). +2. The cryptographic primitive used to combine signer contributions is sound. Not a free assumption: Thorchain's GG20 TSS failed in production on 2026-05-15, draining $10.8M from an Asgard vault via a TSSHOCK-class weakness. Source: [Crypto Times, 2026-05-17](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) (accessed 2026-05-21). +3. The implementations on every external chain are correct. Not a free assumption either: on 2022-02-02 a Solana-side `load_instruction_at` bug let an attacker forge a Wormhole VAA and mint 120k wETH unbacked ($326M). Source: [Halborn](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) (accessed 2026-05-21). Pros: @@ -22,7 +22,7 @@ Pros: - One-step user experience: deposit-with-memo, await outbound. No counterparty interactivity, no refund flows, no online-availability requirement past broadcast. - Sub-block-time settlement on the middle chain; only destination-chain finality and the TSS keysign delay the outbound. - Arbitrary asset pairs at protocol-set pricing. -- Cryptoeconomic recourse: misbehaviour is slashable. Thorchain runs 2:1 bonded plus 1:1 pooled. Serai caps custody at 33% of allocated validator stake. Source: [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md). +- Cryptoeconomic recourse: misbehaviour is slashable. Thorchain runs 2:1 bonded plus 1:1 pooled, per [Thorchain docs: RUNE](https://docs.thorchain.org/understanding-thorchain/rune) (accessed 2026-05-21). Serai caps custody at 33% of allocated validator stake, per [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md) (accessed 2026-05-21). Cons: @@ -34,7 +34,7 @@ Cons: ### Atomic swap -Examples: COMIT Network (xmr-btc-swap, archived as of 2024-11), Farcaster, AtomicDEX (rebranded to Komodo Wallet, no recent volume), Liquality (discontinued 2024-06-15). All but Farcaster have wound down. The cryptographic primitive: HTLC for script-compatible pairs; adaptor signatures with cross-curve DLEQ proofs for Monero pairs. +Examples: COMIT Network (xmr-btc-swap, unmaintained since 2024-11 with archival pending per issue #1791), Farcaster (low-velocity since 2024), AtomicDEX (rebranded to Komodo Wallet, no recent volume), Liquality (discontinued 2024-06-15). All but Farcaster have wound down. The cryptographic primitive: HTLC for script-compatible pairs; adaptor signatures with cross-curve DLEQ proofs for Monero pairs. What the user trusts: nothing beyond the soundness of the cryptographic construction and the liveness of the two parties for the duration of the swap. @@ -50,13 +50,13 @@ Cons: 2. **Settlement time dominated by the slowest chain.** A single swap can take 30 minutes to several hours to finalise because confirmations stack across both chains. Refund timelocks are measured in hours, not minutes. 3. **Mandatory interactivity for both parties.** Both parties must be online for lock, reveal, and (in adversarial paths) refund. If Alice goes offline mid-swap, Bob waits out the refund window, and vice versa. 4. **Per-trade matching.** No protocol-owned liquidity, no AMM pricing; each swap requires a willing counterparty for the exact pair and exact size. -5. **Pair coverage.** HTLC requires compatible scripting on both chains. BTC-XMR specifically required about five years of cryptographic work (2017 proposal to 2021 working implementation via adaptor signatures over Ed25519 and secp256k1). Source: [getmonero.org: Bitcoin to Monero atomic swaps are now live, 2021-08-20](https://www.getmonero.org/2021/08/20/atomic-swaps.html); [Hoenisch and del Pino, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf). +5. **Pair coverage.** HTLC requires compatible scripting on both chains. BTC-XMR specifically required about four years of cryptographic work (2017 proposal to 2021 working implementation via adaptor signatures over Ed25519 and secp256k1). Sources: [getmonero.org: Bitcoin to Monero atomic swaps are now live, 2021-08-20](https://www.getmonero.org/2021/08/20/atomic-swaps.html) (accessed 2026-05-21); [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) (accessed 2026-05-21); [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332](https://arxiv.org/abs/2101.12332) (accessed 2026-05-21). Cons (1) through (3) are the ones the design space can plausibly attack without abandoning the atomic-swap model entirely. (4) is structural: "fixing" it by adding protocol-owned liquidity reinvents the middle-chain DEX. (5) is a per-pair engineering cost paid once. ### Why the federated middle chain has won the volume race -Thorchain has processed $112B cumulative volume since 2021. The four most-cited atomic-swap projects have collectively produced roughly $35M in volume over the same period (Liquality lifetime figure, [defiprime.com: Liquality](https://defiprime.com/liquality)). The structural reasons: +Thorchain has processed over $118B cumulative volume by December 2025 (per [Messari: THORChain State of the Network Q4 2025](https://messari.io/report/state-of-thorchain-q4-2025)) and over $120B by May 2026 (per [DefiLlama Thorchain DEX dashboard](https://defillama.com/protocol/thorchain-dex), accessed 2026-05-21). The four most-cited atomic-swap projects have collectively produced roughly $35M in volume over the same period (Liquality marketing copy widely cited but not anchored to a primary source). The structural reasons: - Liquidity gravity. Peer-to-peer matching requires a counterparty per trade; AMM pools concentrate liquidity into a single state machine. - User experience. Multi-hour timelocks, online-availability requirements, refund flows, and command-line tooling have prevented retail adoption. @@ -80,7 +80,7 @@ Important scoping: Feasibility per chain: - For chains with public outputs (BTC, ETH), a 1:1 wrap via light-client proofs is principled. The LEZ-side mint primitive is a Risc0 program that verifies an inclusion proof against a header chain (forkable from ZeroSync or Citrea's Clementine LCP for BTC; from existing Ethereum light-client work for ETH). -- For Monero, no principled wrap is feasible today. Monero has no SPV-style proof primitive that can demonstrate "address Y received amount X" without view-key sharing: ring signatures, RingCT, and one-time stealth addresses defeat external observation by design. Monero's bilateral `check_tx_proof` works in a private wallet-to-wallet context but cannot be lifted to a public LEZ contract without disclosing the per-tx private key and blinding factor to world-readable state, which is mathematically equivalent to view-key disclosure for the swap output. The FCMP++ (full-chain membership and metadata-private proofs) research direction may unlock a non-disclosing variant; it is pre-production. Source: [Monero stealth address documentation](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf); [Monero FCMP++ overview](https://www.getmonero.org/resources/moneropedia/fcmp.html). +- For Monero, no principled wrap is feasible today. Monero has no SPV-style proof primitive that can demonstrate "address Y received amount X" without view-key sharing: ring signatures, RingCT, and one-time stealth addresses defeat external observation by design. Monero's bilateral `check_tx_proof` (which can be either an OutProofV2 that requires the per-tx private key, or an InProofV2 that requires the recipient view key) works in a private wallet-to-wallet context but cannot be lifted to a public LEZ contract without disclosing either the per-tx private key or the view key (plus the output blinding factor) to world-readable state, which is sufficient to deanonymise the swap output. The FCMP++ (full-chain membership and metadata-private proofs) research direction may unlock a non-disclosing variant; it is pre-production. Sources: [Monero, Zero to Monero 2.0 §Payment Proofs](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) (accessed 2026-05-21); [Monero, FCMP++ (2024-04-27)](https://www.getmonero.org/2024/04/27/fcmps.html) (accessed 2026-05-21). Where Mitigation 1 fits in the bundle: @@ -143,7 +143,7 @@ Tier 2 user experience: "Bob is bonded; Alice is reputation-gated only" under th ### Mitigation 3: maker and taker reputation -A maker is a repeat participant; a long history of completed swaps is itself a slashable asset because losing the reputation forfeits all future fee revenue. This is the same argument that secures Wormhole's Guardians without bonded stake (reputation as economic gravity) but applied to a maker registry rather than a signer set. The proposed primitive is the subject of RFP-023. +A maker is a repeat participant; a long history of completed swaps is itself a slashable asset because losing the reputation forfeits all future fee revenue. The closest deployed instance of reputation substituting for bonded stake is Wormhole's Guardian set, which operates as a Proof-of-Authority committee of named validator companies; the framing applies *the economic argument* (reputation can substitute for bond) to a different mechanism (a permissionless maker registry that accrues reputation per swap, rather than a governance-curated whitelist). The proposed primitive is the subject of RFP-023. #### Maker reputation: trivially linkable @@ -204,17 +204,19 @@ A reader choosing between the RFPs should ask: ## References -- [Bitcoin to Monero atomic swaps are now live (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) -- [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) -- [Decred blog: On-Chain Atomic Swaps (2017)](https://blog.decred.org/2017/09/20/On-Chain-Atomic-Swaps/) -- [comit-network/xmr-btc-swap (archived 2024-11)](https://github.com/comit-network/xmr-btc-swap) -- [Thorchain Medium: Why Cross-Chain bridges are superior to Atomic Swaps (2019-07-02)](https://medium.com/thorchain/why-cross-chain-bridges-are-superior-to-atomic-swaps-aebde263103c) -- [Thorchain docs: Continuous Liquidity Pools](https://docs.thorchain.org/technical-documentation/thorchain-finance/continuous-liquidity-pools) -- [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md) -- [Serai AMM docs](https://docs.serai.exchange/amm/) -- [Halborn: Wormhole Hack February 2022](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) -- [Crypto Times: $10.8M drained from Thorchain (2026-05-17)](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) -- [Monero whitepaper: Zero to Monero 2.0](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) -- [Monero FCMP overview](https://www.getmonero.org/resources/moneropedia/fcmp.html) -- [defiprime.com: Liquality](https://defiprime.com/liquality) -- [Liquality discontinuation announcement (2024-05-20)](https://x.com/Liquality_io/status/1792678368694985162) +- [Bitcoin to Monero atomic swaps are now live (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) (accessed 2026-05-21) +- [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) (accessed 2026-05-21) +- [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332 (2021-01-29)](https://arxiv.org/abs/2101.12332) (accessed 2026-05-21) +- [Decred blog: On-Chain Atomic Swaps, 2017-09-20 (first on-chain atomic swap, Decred-Litecoin)](https://blog.decred.org/2017/09/20/On-Chain-Atomic-Swaps/) (accessed 2026-05-21) +- [comit-network/xmr-btc-swap (unmaintained since 2024-11; archival pending per issue #1791)](https://github.com/comit-network/xmr-btc-swap) (accessed 2026-05-21) +- [Thorchain Medium: Why Cross-Chain bridges are superior to Atomic Swaps (2019-07-02)](https://medium.com/thorchain/why-cross-chain-bridges-are-superior-to-atomic-swaps-aebde263103c) (accessed 2026-05-21) +- [Thorchain docs: Continuous Liquidity Pools](https://docs.thorchain.org/technical-documentation/thorchain-finance/continuous-liquidity-pools) (accessed 2026-05-21) +- [Thorchain docs: RUNE (bond-to-pooled ratio)](https://docs.thorchain.org/understanding-thorchain/rune) (accessed 2026-05-21) +- [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md) (accessed 2026-05-21) +- [Serai AMM docs](https://docs.serai.exchange/amm/) (accessed 2026-05-21) +- [Halborn: Wormhole Hack February 2022 (technical analysis)](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) (accessed 2026-05-21) +- [Crypto Times: $10.8M drained from Thorchain on 2026-05-15](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) (accessed 2026-05-21) +- [Monero, Zero to Monero 2.0 (whitepaper)](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) (accessed 2026-05-21) +- [Monero, FCMP++ announcement (2024-04-27)](https://www.getmonero.org/2024/04/27/fcmps.html) (accessed 2026-05-21) +- [defiprime.com: Liquality](https://defiprime.com/liquality) (accessed 2026-05-21) +- [Liquality discontinuation announcement (2024-05-20)](https://x.com/Liquality_io/status/1792678368694985162) (accessed 2026-05-21) diff --git a/appendix/sxmr-design-space.md b/appendix/sxmr-design-space.md index dc67cbb..0152c09 100644 --- a/appendix/sxmr-design-space.md +++ b/appendix/sxmr-design-space.md @@ -6,7 +6,7 @@ Background appendix for RFP-024 (sXMR pure non-custodial) and RFP-025 (sXMR with A synthetic Monero token deployed as a program on the canonical Logos Execution Zone (LEZ). Oracle-priced for trading and composability inside LEZ; redeemed to real XMR via peer-to-peer atomic swap with no central custodian, no bridge, and no protocol-held reserves. -The wedge: the only synthetic in the published landscape that terminates in a privacy-preserving asset on a privacy chain. sBTC (Stacks) redeems to public BTC, leaving the destination on a transparent ledger. Every other commodity synthetic (sBTC variants, sETH, sLINK) redeems to traceable transparent assets. sXMR is the first design where the redemption path itself preserves privacy. +The wedge: the only currently published, live synthetic whose redemption deposits real XMR on Monero L1 *non-custodially, via peer-to-peer atomic swap*. sBTC (Stacks) redeems to public BTC, leaving the destination on a transparent ledger. Every other commodity synthetic (sBTC variants, sETH, sLINK) redeems to traceable transparent assets. The closest prior art is custodial: Synthetix's historical sXMR token paired with the Secret Network Monero Bridge offered XMR-L1 redemption under signer-set custody (the same trust model Goal 2b accepts); Haven Protocol's xAsset family offered synthetics on a dedicated privacy chain but closed in December 2024 and never offered xXMR. This design is the first where the redemption path itself preserves privacy *and* avoids custody. Honest framing: this is a synthetic with a soft, market-clearing peg, not a hard-redeemable synthetic. The oracle is the *quoted* price; the *achievable* price is whatever an XMR LP will swap for, when one is willing. Structurally closer to a DEX trading pair than to sBTC (Stacks). @@ -54,7 +54,7 @@ The premise of RFP-024. 1. **LP exodus.** All XMR holders stop quoting. sXMR trades at an indefinite discount to oracle. 2. **Adverse selection.** LPs only show up when oracle is below true XMR price (free money for them) and vanish when oracle is above (would-be loss). Redemption is asymmetric across regimes. 3. **Demand asymmetry.** Easy to mint sXMR (privacy-curious DeFi users want it); harder to source LPs (XMR maximalists may not want a public LP role at all). -4. **User experience cost.** Monero atomic swap windows are 30 to 60 minutes; both parties must be online unless an intent layer is built on top. +4. **User experience cost.** Monero atomic swap windows are dominated by Monero block confirmations, typically under an hour but with variance from network conditions; both parties must be online unless an intent layer is built on top. ### When this fits @@ -169,7 +169,7 @@ At this point the design has reinvented sBTC (Stacks) with an oracle bolted on. | LP economics | Yield from spreads plus protocol incentives, less bond opportunity cost | Not applicable (no third-party LPs) | | Decentralisation | High (anyone can be a bonded LP if they post the bond) | Low (signer set is gated) | | Censorship resistance | Medium (LP set is registered) | Low (signers are known) | -| Best-case redemption speed | Atomic swap (30 to 60 min) | Atomic swap (30 to 60 min) | +| Best-case redemption speed | Atomic swap (Monero-confirmation-bound; typically under an hour) | Atomic swap (Monero-confirmation-bound; typically under an hour) | | Failure mode | Bond runs out under coordinated default | Signer collusion or custody breach | ### When this fits @@ -219,7 +219,7 @@ At this point the design has reinvented sBTC (Stacks) with an oracle bolted on. Before committing to either goal, applicants should validate: -1. **Atomic swap UX with Monero today.** Live protocols (eigenwallet/unstoppableswap fork of comit-network/xmr-btc-swap, Farcaster) take 30 to 60 minutes and require both parties online. Confirm async or intent-based variants are production-grade before designing UX around them. +1. **Atomic swap UX with Monero today.** Live protocols (eigenwallet/unstoppableswap fork of comit-network/xmr-btc-swap, Farcaster) impose settlement times dominated by Monero block confirmations, typically under an hour but with variance, and require both parties online. Applicants should measure the actual distribution against a recent client release rather than rely on the indicative range. Confirm async or intent-based variants are production-grade before designing UX around them. 2. **LP supply.** Will XMR holders actually LP? They self-select for privacy maximalism and may not want a public on-chain LP role. The LP side is the bottleneck; validate before designing the rest. 3. **Bond economics (Goal 2a only).** Required bond size as a multiple of XMR notional; opportunity cost of locked stable collateral on LEZ; expected APY needed to attract bonded LPs. 4. **Signer set sourcing (Goal 2b only).** Same problem space as sBTC (Stacks); revisit that project's trust assumptions before reinventing them. Also revisit RFP-021's federated-middle-chain trust analysis, which covers the same TSS custody design space. @@ -235,8 +235,13 @@ Pick the goal before writing the spec. The three designs have different threat m ## References -- [sBTC (Stacks) Bitcoin layer documentation](https://docs.stacks.co/concepts/sbtc) -- [Synthetix V3 documentation](https://docs.synthetix.io/v/v3/) -- [eigenwallet/core (XMR atomic swap fork of comit-network/xmr-btc-swap)](https://github.com/eigenwallet/core) -- [Farcaster project](https://github.com/farcaster-project) -- [Bitcoin to Monero atomic swaps (getmonero.org)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) +- [sBTC (Stacks) Bitcoin layer documentation](https://docs.stacks.co/learn/sbtc) (accessed 2026-05-21) +- [Synthetix SIP-302: V3 collateral and snxUSD minting (CDP reference)](https://sips.synthetix.io/sips/sip-302/) (accessed 2026-05-21) +- [eigenwallet/core (XMR atomic swap, active fork of comit-network/xmr-btc-swap; v4.6.1, 2026-05-15)](https://github.com/eigenwallet/core) (accessed 2026-05-21) +- [Farcaster project (XMR atomic swap; low-velocity, last release v0.8.4 on 2023-01-16)](https://github.com/farcaster-project/farcaster-node) (accessed 2026-05-21) +- [Bitcoin to Monero atomic swaps (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) (accessed 2026-05-21) +- [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) (accessed 2026-05-21) +- [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332](https://arxiv.org/abs/2101.12332) (accessed 2026-05-21) +- [Secret Network Monero Bridge (custodial XMR-to-Secret Network bridge, structural counter-example for the "only synthetic terminating in XMR L1" wedge)](https://docs.scrt.network/secret-network-documentation/development/snip-20-secret-tokens/snip-721-secret-nfts) (accessed 2026-05-21) +- [Haven Protocol shutdown notice (December 2024; historical xAsset family of privacy-chain synthetics)](https://havenprotocol.org/) (accessed 2026-05-21) +- [Han et al., On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) (accessed 2026-05-21) From d8bb121cd810fa5f875b04862ebf7fe300fe5f1c Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 22 May 2026 16:26:41 +1000 Subject: [PATCH 04/17] rfp: add atomic-swaps-primer appendix (bundle-agnostic survey) Pure background appendix covering atomic-swap mechanics: HTLC, adaptor signatures with cross-curve DLEQ, the canonical XMR-BTC flow (with Mermaid sequence diagram), the locks-first rule (script-bearing side locks first by construction of the adaptor-signature primitive), the free-option problem, and the sigma*sqrt(T)*notional notation used to size free-option premiums. Survey scope only: deployed protocols and published literature. No bundle-specific designs, no recommendations. Part of the appendix/RFP-design split for PR #57. Following commits will rewrite the trust-model-contrast and synthetics appendices to pure survey form, then move the bundle's design content into the relevant RFPs (022-025). Co-Authored-By: Claude Opus 4.7 (1M context) --- appendix/atomic-swaps-primer.md | 138 ++++++++++++++++++++++++++++++++ 1 file changed, 138 insertions(+) create mode 100644 appendix/atomic-swaps-primer.md diff --git a/appendix/atomic-swaps-primer.md b/appendix/atomic-swaps-primer.md new file mode 100644 index 0000000..7b25950 --- /dev/null +++ b/appendix/atomic-swaps-primer.md @@ -0,0 +1,138 @@ +# Atomic Swaps Primer + +Background appendix on how cross-chain atomic swaps work. Covers the cryptographic mechanics, the canonical XMR-BTC flow, and the free-option property of atomicity. Pure survey of deployed protocols and published literature; no specific RFP designs. + +## The primitive + +An atomic swap is a two-party exchange of assets on two different chains where either both legs settle or both legs unwind. Atomicity comes from cryptography, not from a third party: a single secret unlocks both legs, and the protocol is constructed so revealing the secret on one chain forces revelability on the other. + +Two cryptographic constructions are deployed: + +- **Hash time-locked contract (HTLC)** for chain pairs with compatible scripting. The lock outputs are spendable either by knowledge of a hash preimage `s` (claim path) or by waiting out a timelock (refund path). Decred-Litecoin executed the first on-chain HTLC swap on 2017-09-20. Source: [Decred blog, On-Chain Atomic Swaps (2017-09-20)](https://blog.decred.org/2017/09/20/On-Chain-Atomic-Swaps/) (accessed 2026-05-21). +- **Adaptor signatures with cross-curve DLEQ proofs** for chain pairs where one side has restricted scripting (e.g. Monero). The secret is a scalar that completes a signature on one chain; revealing it lets the counterparty produce a valid signature on the other. The construction was first proposed for BTC-XMR in 2017 and reached working implementations in 2021. Sources: [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) (accessed 2026-05-21); [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332](https://arxiv.org/abs/2101.12332) (accessed 2026-05-21); [getmonero.org: Bitcoin to Monero atomic swaps are now live, 2021-08-20](https://www.getmonero.org/2021/08/20/atomic-swaps.html) (accessed 2026-05-21). + +The two constructions differ in their script requirements but share the same trust model and the same free-option property. + +## The canonical XMR-BTC swap + +Standard adaptor-signature flow, as implemented by COMIT (`xmr-btc-swap`, archival pending since 2024-11) and its successor fork eigenwallet (`core`, active as of v4.6.1 on 2026-05-15). + +### Roles + +- **Alice** holds BTC, wants XMR. +- **Bob** holds XMR, wants BTC. + +### Sequence + +```mermaid +sequenceDiagram + autonumber + participant A as Alice (BTC holder) + participant BTC as Bitcoin + participant XMR as Monero + participant B as Bob (XMR holder) + + Note over A,B: 0. Quote and joint-key setup (off-chain) + A->>B: Request quote + B-->>A: Signed quote (price, expiry, refund pubkeys) + A-->>B: Joint-key setup transcript + B-->>A: Joint-key setup transcript + + Note over A,B: 1. Lock-BTC (Alice locks first, script-bearing side) + A->>BTC: Lock BTC to 2-of-2 (Alice + Bob) + BTC-->>B: Confirmation observed + + Note over A,B: 2. Lock-XMR (Bob locks second) + B->>XMR: Lock XMR to joint-key stealth address + XMR-->>A: Confirmation observed (via shared view key) + + Note over A,B: 3. Reveal and Settle + A->>BTC: Publish adaptor signature (allows Bob to claim BTC) + B->>BTC: Claim BTC; broadcast reveals scalar s + A->>XMR: Use s to claim XMR +``` + +### Why BTC is locked first + +The script-bearing side locks first **by construction of the adaptor-signature primitive**, not as a design choice. + +The mechanism: the secret that completes the swap is an Ed25519 scalar `s` whose discrete log corresponds to one half of the joint Monero spend key. Alice's adaptor signature on a Bitcoin transaction is a *signature with `s` factored out*; Bob can adapt it into a valid signature by adding `s`, but the act of broadcasting that adapted signature on Bitcoin publishes `s` as part of the on-chain transaction (it can be extracted by anyone observing the broadcast). Alice then uses `s` to construct a Monero spend signature for the joint-key output, claiming the XMR. + +Reversing the order does not compose: + +- If Bob locked XMR first, there would be no Bitcoin transaction whose broadcast reveals `s`. Bob would need a way to commit to `s` such that Alice can extract it after she locks BTC — but the only mechanism the primitive provides is "Bob's broadcast of a Bitcoin-claim signature reveals `s`", which presupposes Bob has something to claim on Bitcoin. +- Equivalently: the secret-revelation flow points from BTC settlement to XMR claimability. The chain that hosts the adaptor signature (BTC) must hold a lock the counterparty wants to claim before the secret materialises. + +Consequence: **whichever chain holds the script side of the swap locks first.** For XMR-BTC, BTC. For XMR with any other script-bearing chain, that chain. This is a property of the primitive, fixed independently of who is taker or maker. + +### Timelocks and refunds + +Each lock has a refund timelock. If the swap stalls before reveal, the locker can sweep their lock back after the timelock expires. The script-side refund (Alice's BTC) typically has a shorter timelock than the secret-side refund (Bob's XMR), so Alice cannot wait until Bob has refunded his XMR and then claim Alice-side BTC anyway. + +Refund and claim windows are conventionally measured in hours. A swap that proceeds normally completes in roughly one Bitcoin confirmation depth (typically 10-60 minutes for the BTC lock) plus one Monero confirmation depth (typically 10-30 minutes for the XMR lock) plus the reveal latency. + +### Production status of XMR-BTC implementations + +- **COMIT `xmr-btc-swap`**: original reference implementation, [unmaintained since 2024-11, archival pending per issue #1791](https://github.com/comit-network/xmr-btc-swap) (accessed 2026-05-21). +- **eigenwallet `core`**: active fork of `xmr-btc-swap`; v4.6.1 released 2026-05-15. [github.com/eigenwallet/core](https://github.com/eigenwallet/core) (accessed 2026-05-21). +- **Farcaster (farcaster-project/farcaster-node)**: independent XMR-BTC implementation, low-velocity; last release v0.8.4 on 2023-01-16. [github.com/farcaster-project/farcaster-node](https://github.com/farcaster-project/farcaster-node) (accessed 2026-05-21). +- **AtomicDEX / Komodo Wallet**: rebranded; no significant recent BTC-XMR volume. +- **Liquality**: discontinued 2024-06-15. + +The XMR-BTC corridor is real and operational, but adoption is small relative to bridge volumes. See the [trust-model contrast appendix](./cross-chain-trust-model-contrast.md) for volume comparison. + +## The free-option problem + +Atomic swaps are deliberately symmetric: either party can refuse the next message at any stage, and both sides refund at timeout. From outside, this looks like a stall; structurally, it is the design. + +At each phase boundary, one party has committed (locked their leg) and the other has not yet acted. The uncommitted party holds a **free option**: they can observe the market for the duration of the lock window and proceed only if the trade is still in their favour. + +Stage-by-stage in the XMR-BTC flow: + +1. **After Alice locks BTC (step 1, before step 2).** Bob holds the free option. If XMR price has moved against him since the quote, he simply does not lock XMR. Alice's BTC refunds at timeout. Bob's downside: time. Alice's downside: lock window plus refund timelock with capital wedged. +2. **After Bob locks XMR (step 2, before step 3).** Alice holds the free option. If the price has moved against her, she does not publish the adaptor signature. Both legs refund at timeout. Alice's downside: time. Bob's downside: capital wedged for the longer refund window. +3. **After secret reveal (step 3 onward).** No party holds an option; the swap completes deterministically. + +This is the **free-option problem** of atomic swaps. It is not a bug in any particular implementation; it is the cost of atomicity itself. Cited in the literature as the structural reason atomic-swap volume has remained small despite working implementations. Source: [Han et al., On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) (accessed 2026-05-21). + +### Notation for option value + +The expected value of a free option held over a timelock window scales as: + +`option_value ≈ σ × √T × notional` + +where: + +- `σ` = annualised volatility of the price ratio between the two swap legs; +- `T` = duration of the timelock window (the period over which the option holder can observe and decide); +- `notional` = size of the locked leg. + +This is a Black-Scholes-style approximation, valid for small `T` and continuous-time random-walk price dynamics. It is the standard way to size a bond, premium, or cap intended to neutralise the free option a counterparty holds during a lock window. + +## Generalising the locks-first rule across pairs + +The lock-ordering constraint is a property of the cryptographic construction, not of the specific BTC-XMR pair. In any adaptor-signature swap, the **script-bearing side** (the chain that hosts the adaptor signature whose broadcast reveals the secret scalar) must lock first. The non-script side, where the swap output is a joint-key construction that the secret unlocks, locks second. + +For HTLC swaps, the analogous constraint is that the chain whose HTLC reveals the preimage on claim must be locked first; the chain whose HTLC consumes the same preimage on its claim path then settles second. In practice for symmetric-script pairs (e.g. BTC-LTC) the ordering is conventional rather than forced, since both chains can play either role. + +For XMR paired with any other chain, XMR is always the non-script side. The script-bearing partner locks first. + +## What atomic swaps do not provide + +- **Counterparty availability.** Both parties must be online to lock, reveal, and (on adversarial paths) submit refund transactions. If one party goes offline mid-swap, the other waits out the refund window. +- **Per-trade matching.** No protocol-owned liquidity; each swap requires a willing counterparty for the exact pair and size. +- **Pair coverage by default.** HTLC required compatible scripting on both chains; adaptor signatures generalise this but each pair still needs cross-curve cryptographic work (BTC-XMR required ~4 years from proposal to working implementation). +- **Settlement speed.** End-to-end time is dominated by the slowest chain's confirmation depth plus the timelock window. + +These are intrinsic limits of the primitive, not deficiencies of any particular implementation. Deployed protocols address them with off-protocol layers (intent gossip for liveness, market-making conventions for matching) or accept them as user-facing constraints. + +## References + +- [Decred blog, On-Chain Atomic Swaps (2017-09-20, first on-chain swap, Decred-Litecoin)](https://blog.decred.org/2017/09/20/On-Chain-Atomic-Swaps/) (accessed 2026-05-21) +- [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) (accessed 2026-05-21) +- [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332 (2021-01-29)](https://arxiv.org/abs/2101.12332) (accessed 2026-05-21) +- [getmonero.org: Bitcoin to Monero atomic swaps are now live (2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) (accessed 2026-05-21) +- [Han et al., On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) (accessed 2026-05-21) +- [comit-network/xmr-btc-swap (unmaintained since 2024-11; archival pending)](https://github.com/comit-network/xmr-btc-swap) (accessed 2026-05-21) +- [eigenwallet/core (active fork of xmr-btc-swap; v4.6.1, 2026-05-15)](https://github.com/eigenwallet/core) (accessed 2026-05-21) +- [farcaster-project/farcaster-node (independent XMR-BTC implementation; last release v0.8.4, 2023-01-16)](https://github.com/farcaster-project/farcaster-node) (accessed 2026-05-21) From 601796dd6648e545a69553c80906e221b9371ece Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 22 May 2026 16:27:50 +1000 Subject: [PATCH 05/17] rfp: fix Mermaid parse error in atomic-swaps primer The sequence diagram had "scalar s" at end-of-line, which Mermaid's parser treated as a participant token rather than label text. Reworded to "the scalar" / "the revealed scalar" so the diagram renders on GitHub. Co-Authored-By: Claude Opus 4.7 (1M context) --- appendix/atomic-swaps-primer.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/appendix/atomic-swaps-primer.md b/appendix/atomic-swaps-primer.md index 7b25950..e050708 100644 --- a/appendix/atomic-swaps-primer.md +++ b/appendix/atomic-swaps-primer.md @@ -48,8 +48,8 @@ sequenceDiagram Note over A,B: 3. Reveal and Settle A->>BTC: Publish adaptor signature (allows Bob to claim BTC) - B->>BTC: Claim BTC; broadcast reveals scalar s - A->>XMR: Use s to claim XMR + B->>BTC: Claim BTC; broadcast reveals the scalar + A->>XMR: Use the revealed scalar to claim XMR ``` ### Why BTC is locked first From 97ea13a8cbb43a375676dc3cbd0aa6870ac4d9ac Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 22 May 2026 16:30:57 +1000 Subject: [PATCH 06/17] rfp: remove semicolon from mermaid message label Mermaid's sequenceDiagram parser treats semicolons in message labels as statement separators, breaking the diagram. Replaced "Claim BTC; broadcast reveals the scalar" with "Claim BTC, broadcasting the scalar to Alice". Co-Authored-By: Claude Opus 4.7 (1M context) --- appendix/atomic-swaps-primer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/appendix/atomic-swaps-primer.md b/appendix/atomic-swaps-primer.md index e050708..7ed74d4 100644 --- a/appendix/atomic-swaps-primer.md +++ b/appendix/atomic-swaps-primer.md @@ -48,7 +48,7 @@ sequenceDiagram Note over A,B: 3. Reveal and Settle A->>BTC: Publish adaptor signature (allows Bob to claim BTC) - B->>BTC: Claim BTC; broadcast reveals the scalar + B->>BTC: Claim BTC, broadcasting the scalar to Alice A->>XMR: Use the revealed scalar to claim XMR ``` From 796cc0700a7c850a12d3568b055368ec542c84fa Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 22 May 2026 16:44:30 +1000 Subject: [PATCH 07/17] rfp: rewrite appendices as bundle-agnostic surveys Three changes: 1. atomic-swaps-primer.md: corrected Farcaster status (vault confirms still actively maintained as of 2026 with Lightning BTC support, not the v0.8.4-2023-01-16 stale claim). Removed bundle-specific "Generalisation to XMR-LEZ" section. Removed bundle references from notation and closing text. Sourcing for the protocol step diagram and lock-ordering rationale flagged in marclawclaw/research-cross-chain-dex/projects/PENDING-atomic-swap-protocol-details.md. 2. cross-chain-trust-model-contrast.md: stripped Mitigations 1/2/3 design content, Synthesis table, bondless-taker mechanic. All are bundle design choices that belong in the RFPs, not in a survey appendix. Kept the two-camps contrast and the adoption record. All numbers re-grounded against the research vault: Thorchain $112.201B cumulative (DefiLlama, not the $118B Messari claim that was not in vault); AtomicDEX Nomics $5,737 figure; Liquality $35M; Serai pre-mainnet with 2026-04-15 audit; Wormhole 19-of-13 attestation pattern. Every claim now traces to a citation in marclawclaw/research-cross-chain-dex/. 3. synthetics-design-space.md: replaces sxmr-design-space.md. Stripped Goal 1/2a/2b sub-designs (move to RFPs 024 and 025 in follow-up commits). Survey-only taxonomy: oracle-priced over-collateralised (Haven, Synthetix); redeem-to-underlying with custody (sBTC, Secret Monero Bridge); redeem-to-underlying without custody (no deployed example). Privacy-coin specific constraints documented. Secret Monero Bridge included as the closest deployed prior art with its documented launch reception. Three vault-uncertain claims explicitly flagged inline for verification (Haven shutdown date, SIP-302 citation, sBTC trust shape); see PENDING-atomic-swap-protocol-details.md. Inbound links from RFP-024 and RFP-025 to the old sxmr-design-space file will be updated by the follow-up commits that move the design content into those RFPs. Co-Authored-By: Claude Opus 4.7 (1M context) --- appendix/atomic-swaps-primer.md | 8 +- appendix/cross-chain-trust-model-contrast.md | 262 ++++++------------- appendix/sxmr-design-space.md | 247 ----------------- appendix/synthetics-design-space.md | 89 +++++++ 4 files changed, 176 insertions(+), 430 deletions(-) delete mode 100644 appendix/sxmr-design-space.md create mode 100644 appendix/synthetics-design-space.md diff --git a/appendix/atomic-swaps-primer.md b/appendix/atomic-swaps-primer.md index 7ed74d4..8e0a4bd 100644 --- a/appendix/atomic-swaps-primer.md +++ b/appendix/atomic-swaps-primer.md @@ -75,11 +75,11 @@ Refund and claim windows are conventionally measured in hours. A swap that proce - **COMIT `xmr-btc-swap`**: original reference implementation, [unmaintained since 2024-11, archival pending per issue #1791](https://github.com/comit-network/xmr-btc-swap) (accessed 2026-05-21). - **eigenwallet `core`**: active fork of `xmr-btc-swap`; v4.6.1 released 2026-05-15. [github.com/eigenwallet/core](https://github.com/eigenwallet/core) (accessed 2026-05-21). -- **Farcaster (farcaster-project/farcaster-node)**: independent XMR-BTC implementation, low-velocity; last release v0.8.4 on 2023-01-16. [github.com/farcaster-project/farcaster-node](https://github.com/farcaster-project/farcaster-node) (accessed 2026-05-21). -- **AtomicDEX / Komodo Wallet**: rebranded; no significant recent BTC-XMR volume. -- **Liquality**: discontinued 2024-06-15. +- **Farcaster Project (`farcaster-project/farcaster-node`)**: independent BTC-XMR implementation. Still listed as actively maintained as of 2026, with Lightning BTC support added to reduce BTC-side confirmation time. Community-scale rather than volume-scale operation. Sources: [xgram.io: Best Monero atomic swap platforms 2026](https://xgram.io/blog/best-xmr-atomic-swaps-and-community-services-2026) (accessed 2026-05-19); [github.com/farcaster-project](https://github.com/farcaster-project) (accessed 2026-05-19). +- **AtomicDEX / Komodo Wallet**: rebranded to "Komodo Wallet" in 2025. Public trackers report no recent volume; Nomics' last published 24-hour volume figure is approximately USD 5,737 from November 2021. Source: [Nomics: AtomicDEX](https://nomics.com/exchanges/atomicdex) (accessed 2026-05-19). +- **Liquality**: consumer atomic-swap wallet extension discontinued effective 2024-06-15. Sources: [Liquality on X, 2024-05-20](https://x.com/Liquality_io/status/1792678368694985162) (accessed 2026-05-19); [Rootstock Helpdesk: Liquality](https://helpdesk.rootstock.io/solutions/liquality.html) (accessed 2026-05-19). -The XMR-BTC corridor is real and operational, but adoption is small relative to bridge volumes. See the [trust-model contrast appendix](./cross-chain-trust-model-contrast.md) for volume comparison. +The XMR-BTC corridor is operational but at community scale. See the [trust-model contrast appendix](./cross-chain-trust-model-contrast.md) for cumulative-volume comparison against federated-signer protocols. ## The free-option problem diff --git a/appendix/cross-chain-trust-model-contrast.md b/appendix/cross-chain-trust-model-contrast.md index 72c7c4c..ff3bf56 100644 --- a/appendix/cross-chain-trust-model-contrast.md +++ b/appendix/cross-chain-trust-model-contrast.md @@ -1,222 +1,126 @@ # Cross-Chain Trust Model Contrast -Background appendix for the cross-chain RFP bundle (RFP-021, RFP-022, RFP-023, RFP-024, RFP-025). Establishes the design space the bundle navigates and the mitigations that distinguish the proposed RFPs from each other. +Survey appendix on the two architectural camps that deployed cross-chain swap protocols fall into, the trust assumptions each camp asks of users, and the adoption record of each. Pure survey of deployed and pre-mainnet protocols; no design choices made here. + +For the underlying cryptographic mechanics of atomic swaps see the [atomic-swaps primer](./atomic-swaps-primer.md). ## Two architectural camps -Every deployed cross-chain swap design today collapses to one of two trust models. +Every deployed cross-chain swap design today collapses to one of two trust models: a federated-signer middle chain that custodies external assets, or a peer-to-peer atomic swap that custodies nothing. ### Federated-signer middle chain -Examples: Thorchain (live since 2021), Serai (pre-mainnet as of 2026-05), Maya, Chainflip. A purpose-built chain whose validator set custodies external assets via a threshold signature scheme (GG20 ECDSA for Thorchain; FROST per-curve for Serai, including FROSTLASS over CLSAG for Monero) and runs swap matching natively. +A purpose-built chain whose validator set custodies external assets via a threshold signature scheme and runs swap matching natively. + +Representative protocols: + +- **Thorchain.** Cosmos SDK / CometBFT L1 launched 2021. Validators run an off-chain observer-signer daemon (Bifrost) and co-sign outbound transactions from per-asset TSS vaults using a GG20 ECDSA scheme (fork of Binance `tss-lib` upgraded from GG18 to GG20). Native swap matching via slip-based continuous liquidity pools (CLPs) with RUNE as universal pairing asset. ~103 active nodes (cap 120), minimum bond 400,020 RUNE per node. Sources: [DefiLlama Thorchain DEX dashboard](https://defillama.com/protocol/thorchain-dex) (accessed 2026-05-19); [State of the Network Feb 2026](https://blog.thorchain.org/state-of-the-network-february-2026/) (accessed 2026-05-19); [Thorchain Bifrost TSS docs](https://dev.thorchain.org/bifrost/tss.html) (accessed 2026-05-19). +- **Serai.** Substrate-based L1, pre-mainnet as of 2026-05 (Substrate blockchain audit complete 2026-04-15, internal testnet pending). Validator set forms per-coin threshold multisigs using FROST (per-curve, including FROSTLASS over CLSAG for Monero). Native AMM with constant-product pools. Validator cap 600 at launch, staking per-network. Sources: [serai.exchange](https://serai.exchange/) (accessed 2026-05-19); [Audit of Serai's Substrate Blockchain (2026-04-15)](https://serai.exchange/2026/04/15/serai-blockchain-audited.html) (accessed 2026-05-19); [Announcing monero-oxide (2025-09-09)](https://serai.exchange/2025/09/09/monero-serai-oxide.html) (accessed 2026-05-19). +- **Maya, Chainflip.** Cousin protocols of Thorchain, same architectural pattern. +- **Wormhole.** Distinct sub-pattern: not a swap chain but a guardian-attestation messaging protocol. 19 guardian operators sign 13-of-19 multisignature attestations (Verifiable Action Approvals) to relay messages across ~40 connected chains. Token movement uses lock-and-mint or burn-and-mint; cross-asset swaps happen on destination-chain DEXes or solver networks rather than inside Wormhole. Same trust shape (committee of known signers) but no protocol-owned liquidity, no native middle chain. Source: [Wormhole Guardians docs](https://wormhole.com/docs/protocol/infrastructure/guardians/) (accessed 2026-05-19). What the user trusts: -1. A threshold of the validator set will not collude to spend from the vault. -2. The cryptographic primitive used to combine signer contributions is sound. Not a free assumption: Thorchain's GG20 TSS failed in production on 2026-05-15, draining $10.8M from an Asgard vault via a TSSHOCK-class weakness. Source: [Crypto Times, 2026-05-17](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) (accessed 2026-05-21). -3. The implementations on every external chain are correct. Not a free assumption either: on 2022-02-02 a Solana-side `load_instruction_at` bug let an attacker forge a Wormhole VAA and mint 120k wETH unbacked ($326M). Source: [Halborn](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) (accessed 2026-05-21). +1. A threshold of the validator set will not collude to spend from the vault. The economic backstop in Thorchain is a 2:1 invariant (bonded RUNE should exceed twice the pooled liquidity); see [Thorchain economic model](https://docs.thorchain.org/technical-documentation/technical-deep-dive/economic-model.md). +2. The cryptographic primitive used to combine signer contributions is sound. Not a free assumption. On 2026-05-15 a GG20 weakness (TSSHOCK-class: malformed proofs allowing key reconstruction by a colluding signer over many rounds) drained approximately $10.8M from a Thorchain Asgard vault. Sources: [Crypto Times, 2026-05-17](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) (accessed 2026-05-19); [AMBCrypto](https://ambcrypto.com/thorchain-exploit-raises-fresh-concerns-over-mpc-wallet-security/) (accessed 2026-05-19). +3. The signer-to-chain integration is correct. The 2021 Thorchain ETH router exploits (two incidents, combined ~$16M) were not TSS failures: the Bifrost interface trusted smart-contract emitted events from a wrapping attacker contract, so the TSS layer functioned as designed while signing transactions that drained the vault. Source: [Thorchain post-mortem](https://medium.com/thorchain/post-mortem-eth-router-exploits-1-2-and-premature-return-to-trading-incident-2908928c5fb) (accessed 2026-05-19). +4. Implementations on every external chain are correct. The 2022-02-02 Wormhole Solana-side `load_instruction_at` bug let an attacker forge a VAA and mint 120k wETH unbacked ($326M). Source: [Halborn: Wormhole Hack February 2022](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) (accessed 2026-05-19). -Pros: +For Monero specifically: any threshold-signer custody of XMR is necessarily view-key-shared. Serai's FROSTLASS over CLSAG is the most advanced production-grade design but the validator set still observes which Monero outputs are committed to the swap. The privacy property is "honest-but-curious validators learn the protocol-side deposit history", not "validators learn nothing". + +Pros of the federated-signer pattern: - AMM-style liquidity. A single ordered state machine maintains pool invariants and serves all-comers without per-trade matching. -- One-step user experience: deposit-with-memo, await outbound. No counterparty interactivity, no refund flows, no online-availability requirement past broadcast. +- One-step user experience: deposit with memo, await outbound. No counterparty interactivity, no refund flows, no online-availability requirement past broadcast. - Sub-block-time settlement on the middle chain; only destination-chain finality and the TSS keysign delay the outbound. - Arbitrary asset pairs at protocol-set pricing. -- Cryptoeconomic recourse: misbehaviour is slashable. Thorchain runs 2:1 bonded plus 1:1 pooled, per [Thorchain docs: RUNE](https://docs.thorchain.org/understanding-thorchain/rune) (accessed 2026-05-21). Serai caps custody at 33% of allocated validator stake, per [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md) (accessed 2026-05-21). +- Cryptoeconomic recourse: misbehaviour is slashable. Thorchain operates at a documented bond-to-pooled ratio; Serai caps custody at 33% of allocated validator stake per network. Sources: [Thorchain RUNE docs](https://docs.thorchain.org/understanding-thorchain/rune) (accessed 2026-05-19); [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md) (accessed 2026-05-19). -Cons: +Cons of the federated-signer pattern: -- Custody risk is real and realised (see incidents cited above). +- Custody risk is real and realised (see incidents above). - The signer federation is a chokepoint for censorship and out-of-protocol pressure on individually identifiable validators. -- Pre-economic-security bootstrap. Serai's mint-on-bootstrap design illustrates that the slashable-bond argument does not bind until the validator-stake pool catches up with custody. -- Public middle-chain state links source and destination identities on the comparator chains. Every comparator publishes the source-to-destination link on at least one public ledger. -- For Monero specifically: any TSS custody of XMR is necessarily view-key-shared. Serai's FROSTLASS over CLSAG is the most advanced production-grade design, but the validator set still observes which Monero outputs are committed to the swap; the privacy property is "honest-but-curious validators learn the LEZ-to-Monero deposit history" not "validators learn nothing". +- Pre-economic-security bootstrap. Bonded-security guarantees do not bind until the validator stake pool catches up with custody. This is the structural reason Serai is pre-launch despite a complete audit. +- Public middle-chain state links source and destination identities on the comparator chains. ### Atomic swap -Examples: COMIT Network (xmr-btc-swap, unmaintained since 2024-11 with archival pending per issue #1791), Farcaster (low-velocity since 2024), AtomicDEX (rebranded to Komodo Wallet, no recent volume), Liquality (discontinued 2024-06-15). All but Farcaster have wound down. The cryptographic primitive: HTLC for script-compatible pairs; adaptor signatures with cross-curve DLEQ proofs for Monero pairs. - -What the user trusts: nothing beyond the soundness of the cryptographic construction and the liveness of the two parties for the duration of the swap. - -Pros: - -- No custody risk. Funds never leave control of one of the two participants. There is no validator set to slash and no vault to drain. -- No signer federation: no 13-of-19, no 67% threshold, no per-chain observer to be censored or compromised. -- No pre-economic-security window. The cryptographic security is full from day one because there is no bond-to-custody ratio to bootstrap. - -Cons: - -1. **Free option on both sides.** Once one party has locked, the other can wait and observe price movement before completing or walking away. The locker's downside is opportunity cost on inventory locked for the entire timelock window; the waiter's downside is gas plus time. Empirically this is the failure mode that kills BTC-XMR adoption: makers refuse to lock against takers who can free-option them for hours. Recognised in the atomic-swap literature as "the free option problem"; not a bug in any particular implementation, but the cost of atomicity itself. -2. **Settlement time dominated by the slowest chain.** A single swap can take 30 minutes to several hours to finalise because confirmations stack across both chains. Refund timelocks are measured in hours, not minutes. -3. **Mandatory interactivity for both parties.** Both parties must be online for lock, reveal, and (in adversarial paths) refund. If Alice goes offline mid-swap, Bob waits out the refund window, and vice versa. -4. **Per-trade matching.** No protocol-owned liquidity, no AMM pricing; each swap requires a willing counterparty for the exact pair and exact size. -5. **Pair coverage.** HTLC requires compatible scripting on both chains. BTC-XMR specifically required about four years of cryptographic work (2017 proposal to 2021 working implementation via adaptor signatures over Ed25519 and secp256k1). Sources: [getmonero.org: Bitcoin to Monero atomic swaps are now live, 2021-08-20](https://www.getmonero.org/2021/08/20/atomic-swaps.html) (accessed 2026-05-21); [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) (accessed 2026-05-21); [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332](https://arxiv.org/abs/2101.12332) (accessed 2026-05-21). - -Cons (1) through (3) are the ones the design space can plausibly attack without abandoning the atomic-swap model entirely. (4) is structural: "fixing" it by adding protocol-owned liquidity reinvents the middle-chain DEX. (5) is a per-pair engineering cost paid once. - -### Why the federated middle chain has won the volume race - -Thorchain has processed over $118B cumulative volume by December 2025 (per [Messari: THORChain State of the Network Q4 2025](https://messari.io/report/state-of-thorchain-q4-2025)) and over $120B by May 2026 (per [DefiLlama Thorchain DEX dashboard](https://defillama.com/protocol/thorchain-dex), accessed 2026-05-21). The four most-cited atomic-swap projects have collectively produced roughly $35M in volume over the same period (Liquality marketing copy widely cited but not anchored to a primary source). The structural reasons: - -- Liquidity gravity. Peer-to-peer matching requires a counterparty per trade; AMM pools concentrate liquidity into a single state machine. -- User experience. Multi-hour timelocks, online-availability requirements, refund flows, and command-line tooling have prevented retail adoption. -- Pair coverage. HTLC was constrained to chain pairs with compatible scripting for years before adaptor-signature techniques generalised it. - -Source: [Thorchain Medium, "Why Cross-Chain bridges are superior to Atomic Swaps" (2019-07-02)](https://medium.com/thorchain/why-cross-chain-bridges-are-superior-to-atomic-swaps-aebde263103c). - -## Mitigations for the addressable atomic-swap cons - -Three independent levers. None is sufficient on its own; their combination defines specific niches that the proposed RFPs target. - -### Mitigation 1: same-asset-to-same-asset (bridge, not trade) - -If the two legs of the swap are denominations of the *same* underlying asset (e.g. native BTC on Bitcoin and an LEZ-side wrapped-BTC token redeemable 1:1 to native BTC via a light-client inclusion proof), the *trade* component disappears: there is no relative-price volatility between the two legs, so the free-option value collapses toward zero. The mid-swap optionality that makes the maker refuse to lock against an arbitrary taker is a function of `σ × √T × notional`; if `σ → 0` for the pair, the option is worthless and the timelock window stops being an exploitable asset. - -Important scoping: - -- This argument applies only to a 1:1 wrapped or SPV-backed token, where redemption is at a contractually fixed ratio and the only `σ` is residual peg slack (premium/discount, queue depth, fees). -- It does *not* apply to an oracle-priced synthetic token (e.g. an sXMR that tracks the XMR price via oracle, collateralised by stables or other assets). The peg slack of an oracle-priced synthetic *is* the volatility the free option pays out on. Oracle-priced synthetic exposure is a distinct product (see RFP-024 and RFP-025); it does not solve the free-option problem. - -Feasibility per chain: - -- For chains with public outputs (BTC, ETH), a 1:1 wrap via light-client proofs is principled. The LEZ-side mint primitive is a Risc0 program that verifies an inclusion proof against a header chain (forkable from ZeroSync or Citrea's Clementine LCP for BTC; from existing Ethereum light-client work for ETH). -- For Monero, no principled wrap is feasible today. Monero has no SPV-style proof primitive that can demonstrate "address Y received amount X" without view-key sharing: ring signatures, RingCT, and one-time stealth addresses defeat external observation by design. Monero's bilateral `check_tx_proof` (which can be either an OutProofV2 that requires the per-tx private key, or an InProofV2 that requires the recipient view key) works in a private wallet-to-wallet context but cannot be lifted to a public LEZ contract without disclosing either the per-tx private key or the view key (plus the output blinding factor) to world-readable state, which is sufficient to deanonymise the swap output. The FCMP++ (full-chain membership and metadata-private proofs) research direction may unlock a non-disclosing variant; it is pre-production. Sources: [Monero, Zero to Monero 2.0 §Payment Proofs](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) (accessed 2026-05-21); [Monero, FCMP++ (2024-04-27)](https://www.getmonero.org/2024/04/27/fcmps.html) (accessed 2026-05-21). - -Where Mitigation 1 fits in the bundle: - -- BTC and ETH: complementary to RFP-022 Tier 1 (bonded atomic swaps), but worth treating as a distinct design (the user does not have to overpay a bond when the trade itself has near-zero volatility). -- XMR: not currently feasible. Move to Mitigation 2 or 3 for free-option control. +A two-party exchange where atomicity comes from cryptography (HTLC or adaptor signatures) rather than a third party. See the [atomic-swaps primer](./atomic-swaps-primer.md) for mechanics. -### Mitigation 2: bonded atomic swap (forced completion via slashing) +Representative protocols (XMR-BTC corridor specifically): -The maker/taker bond design RFP-022 specifies in detail. Bonds posted on LEZ; slashing conditioned on LEZ-observable failures to advance through the swap state machine. +- **COMIT Network** (`comit-network/xmr-btc-swap`). Original Rust reference implementation of BTC-XMR adaptor-signature swaps. Reference implementation `comit-rs` archived 2021-03; `xmr-btc-swap` unmaintained per repo notice, last release v1.0.0-rc.1 on 2024-11-15. Maintenance has migrated to community-led `eigenwallet/core`. Source: [github.com/comit-network/xmr-btc-swap](https://github.com/comit-network/xmr-btc-swap) (accessed 2026-05-19). +- **Farcaster Project** (`farcaster-project/farcaster-node`). Independent BTC-XMR implementation. Still listed as actively maintained as of 2026, with Lightning BTC support added to reduce BTC-side confirmation time. Community-scale rather than volume-scale operation. Sources: [xgram.io: Best Monero atomic swap platforms 2026](https://xgram.io/blog/best-xmr-atomic-swaps-and-community-services-2026) (accessed 2026-05-19); [github.com/farcaster-project](https://github.com/farcaster-project) (accessed 2026-05-19). +- **AtomicDEX / Komodo Wallet.** Rebranded to "Komodo Wallet" in 2025. Public trackers report no recent volume: BitDegree's listing notes "no data available for AtomicDEX because of exchange inactivity"; Nomics' last published 24-hour volume is approximately USD 5,737 from November 2021. Not wound down, but has not produced competitive volumes. Sources: [Komodo Platform Roadmap](https://roadmap.komodoplatform.com/) (accessed 2026-05-19); [BitDegree: AtomicDEX trading data](https://www.bitdegree.org/top-crypto-exchanges/atomicdex) (accessed 2026-05-19); [Nomics: AtomicDEX](https://nomics.com/exchanges/atomicdex) (accessed 2026-05-19). +- **Liquality.** Consumer atomic-swap wallet extension discontinued effective 2024-06-15. Company pivoted to in-app wallet and SDK products. Sources: [Liquality on X, 2024-05-20](https://x.com/Liquality_io/status/1792678368694985162) (accessed 2026-05-19); [Rootstock Helpdesk: Liquality](https://helpdesk.rootstock.io/solutions/liquality.html) (accessed 2026-05-19). -#### The free-option problem in concrete form - -Standard adaptor-signature swap. Alice locks first (XMR or BTC) into a 2-of-2 output. Bob then locks Logos in an LEZ contract conditioned on secret `s`. To claim Logos, Alice publishes a signature that reveals `s` to Bob; Bob uses `s` to sweep Alice's lock. - -- Between Lock-Logos and Reveal, Alice holds a free option on the price. -- Between Alice's first lock and Bob's Logos lock, Bob can refuse to lock if the price moved. - -#### Why slashing only works on the LEZ side - -Monero has no scripting. Bitcoin has scripting too limited to hold a bond conditioned on protocol behaviour. The only place a slash can be enforced is on a smart-contract chain. LEZ is the right host for both bonds, but the LEZ contract needs to verify the preconditions (the locks) before applying any slash. This verification primitive splits cleanly into two tiers. - -#### Tier 1: symmetric bonding for LEZ to BTC and LEZ to ETH - -Both sides' locks are verifiable on LEZ via a chain-watching light-client module: BTC via a Risc0 header-chain light client (forkable from ZeroSync or Citrea Clementine LCP); ETH via existing Ethereum light-client work (e.g. Nimbus-derived). The locker's outputs on these chains are publicly identifiable to a known scriptpubkey or address, so an inclusion proof on LEZ leaks nothing the locker relied on as private. Both Alice's and Bob's bonds are slashable on default: full bilateral free-option mitigation. - -Phases and slash conditions (LEZ to BTC example): - -| Phase | What happens | Slash condition | -|-------|--------------|-----------------| -| 0. Quote | Bob signs quote (price, expiry, swap_id, refund_pubkeys); Alice and Bob run joint-key setup for the BTC 2-of-2 Taproot output | none | -| 1. Commit | Alice posts `B_alice` on LEZ referencing swap_id | none | -| 2. Lock-BTC | Alice constructs and signs the BTC lock tx, sends raw bytes to Bob over Waku; Bob verifies and broadcasts to Bitcoin (if Bob stalls, Alice broadcasts herself). Once confirmed, anyone submits `{btc_block_headers, merkle_proof, raw_tx}` to the LEZ swap contract, which verifies PoW, inclusion, scriptpubkey, and amount | If lock is confirmed on BTC but Bob does not advance to Lock-Logos within window: `B_bob_slice` goes to Alice | -| 3. Lock-Logos | Bob locks `trade_amount` plus `B_bob_slice` in LEZ contract conditioned on `s` | none | -| 4. Reveal | Alice publishes adaptor signature, revealing `s` to Bob | If Alice does not reveal within window: `B_alice` goes to Bob | -| 5. Settle | Bob claims BTC using `s`; Alice's bond and Bob's bond slice released | If Bob does not claim before deadline: no slash (capital loss is on Bob); Alice's bond auto-refunds | - -The unauthenticated proof-submitter property: Bob can broadcast Alice's signed lock tx himself (broadcasting is permissionless on every chain); the LEZ inclusion-proof submitter is also unauthenticated. This eliminates a class of grief vectors: if Alice signs a malformed lock tx (wrong amount, wrong scriptpubkey), Bob simply does not broadcast it, the tx never lands on Bitcoin, the inclusion proof never materialises, and the LEZ state machine quietly times out. There is no "attest or be slashed" dispute to adjudicate, because the precondition for state advancement (a real BTC lock) never holds. - -Same reasoning applies symmetrically to ETH. - -#### Tier 2: asymmetric bonding for LEZ to XMR - -Alice's XMR lock cannot be proven on LEZ without view-key disclosure to public state, per the impossibility result above (Monero stealth addresses plus RingCT defeat external observation; `check_tx_proof` lifted to a public contract is equivalent to view-key disclosure for the swap output). Consequence: - -- **Bob's bond is slashable on default.** Bob's lock is on LEZ and fully observable. Bond mechanic works exactly as in Tier 1 for Bob's side. -- **Alice's bond is slashable only on LEZ-observable abandonment.** It cannot be slashed for "failing to lock XMR" because LEZ cannot verify whether she did. It *can* be slashed for failing to reveal the secret on LEZ after Bob has locked Logos, because both the reveal and Bob's lock are LEZ-observable. -- **Residual free option Alice keeps.** Alice can refuse to lock XMR after Commit without on-chain consequence (her bond is gated by the reveal-after-Bob-lock event, which never occurs in this branch). Bob detects this off-chain by not seeing the XMR lock arrive and walks away without locking Logos; no slash on either side. Alice keeps a pre-XMR-lock free option but loses the post-Bob-lock free option. The residual option is smaller (it is the option to walk away from a quote before any meaningful commitment) but it is real. - -Tier 2 user experience: "Bob is bonded; Alice is reputation-gated only" under the current cryptography. When FCMP++ ships, Alice's lock becomes verifiable on LEZ without view-key disclosure and Tier 2 collapses into Tier 1; the RFP should carry an explicit upgrade clause. - -#### What both tiers fix - -- Con (1), the free option, partially or fully depending on tier. In Tier 1 the slash makes both parties' optionality strictly EV-negative when bonds are sized above option value (`σ × √T × notional`, so 2-5% of trade notional for 1-hour windows). In Tier 2 only Bob's optionality is closed. - -#### What neither tier fixes - -- Con (2): settlement time. Still bounded by source-chain finality plus LEZ finality plus the timelock window. The bond does not accelerate cryptographic settlement. -- Con (3): interactivity. Both parties must be online to lock, reveal, and (if the other side defaults) submit the slash claim. The bond removes the incentive to grief but not the requirement to participate. -- Cross-chain bond correlation: if Bob is matched against N concurrent swaps and LEZ re-orgs or his observer crashes, all N swaps slash him. Per-maker concurrency caps or bond scaling with active-swap count are needed. - -### Mitigation 3: maker and taker reputation - -A maker is a repeat participant; a long history of completed swaps is itself a slashable asset because losing the reputation forfeits all future fee revenue. The closest deployed instance of reputation substituting for bonded stake is Wormhole's Guardian set, which operates as a Proof-of-Authority committee of named validator companies; the framing applies *the economic argument* (reputation can substitute for bond) to a different mechanism (a permissionless maker registry that accrues reputation per swap, rather than a governance-curated whitelist). The proposed primitive is the subject of RFP-023. - -#### Maker reputation: trivially linkable - -Bob already wants a persistent identity on LEZ to receive quote requests, accumulate fee revenue, amortise bond posting, and signal trustworthiness. Layering reputation (count of completed swaps, slash history, time-in-protocol, total fee revenue) on top of (or instead of) a bond compounds the cost of defection. A maker with 10,000 completed swaps walking away from a single griefable trade is an irrational actor; the reputation acts as a long-tailed bond that the protocol cannot directly slash but the market does. - -#### Taker reputation: the privacy tension - -Takers are the population a privacy-positioned cross-chain DEX specifically wants to keep anonymous. A persistent on-chain taker identity that accumulates reputation is at direct odds with the privacy positioning, because reputation requires linkability across swaps by definition. - -Two design paths the proposed RFPs require applicants to consider: +What the user trusts: nothing beyond the soundness of the cryptographic construction and the liveness of the two parties for the duration of the swap. -- **Capped anonymous takers.** First-swap takers size-capped (US$100 notional) without reputation; the cap relaxes after N successful completions under the same persistent pseudonym. Linkability is opt-in: a taker who wants larger size accepts linkability as the cost. -- **Zero-knowledge reputation.** Takers prove "I have completed at least N swaps with zero slashes" without revealing *which* swaps, via a Sparse Merkle Tree of swap outcomes maintained by the LEZ escrow program plus a zk membership proof. Preserves unlinkability across swaps while letting the taker borrow against accumulated reputation. Engineering-expensive; reuses the LEZ zkVM (Risc0) that RFP-003 already establishes. +Pros: -#### Threat model +- No custody risk. Funds never leave control of one of the two participants. No validator set to slash, no vault to drain. +- No signer federation: no n-of-m threshold to compromise, no per-chain observer to censor. +- No pre-economic-security window. Cryptographic security is full from day one because there is no bond-to-custody ratio to bootstrap. -- Sybil attacks: cheap to mint new pseudonyms. Mitigation: reputation accrual is rate-limited by completed-swap throughput and notional caps. Cost of building reputation equals the cost of N honest swaps plus the bond-equivalent capital tied up over the accrual window. -- Maker griefing under multiple identities: a maker who slashes one identity can spin up another. Same mitigation: reputation accrual takes time and capital. -- Sidechannel deanonymisation: even zk reputation has timing, notional, and maker-side-view sidechannels. The privacy claim is "unlinkable across the public ledger" not "unlinkable to a maker who actively profiles its counterparties". This distinction must be documented for users. -- Bootstrap problem: the protocol has zero reputation at launch, so the first cohort of swaps has the strongest free-option exposure. Mitigation: start with caps plus RFP-022 bonds for early adopters; transition to reputation-only as reputation accrues. +Cons (intrinsic to atomicity, not implementation defects): -## The bondless-taker capped-entry mechanic +1. **Free option on both sides.** Once one party has locked, the other can wait and observe price movement before completing or walking away. See the [free-option section in the primer](./atomic-swaps-primer.md#the-free-option-problem) and [Han et al., IACR 2019/896](https://eprint.iacr.org/2019/896) (accessed 2026-05-19) for the literature reference. +2. **Settlement time dominated by the slowest chain.** Confirmations stack across both chains. Third-party documentation of atomic-swap practice notes that "a single swap can take 30 minutes to several hours to finalise". Source: [xgram.io: Best Monero atomic swap platforms 2026](https://xgram.io/blog/best-xmr-atomic-swaps-and-community-services-2026) (accessed 2026-05-19). +3. **Mandatory interactivity for both parties.** Both must be online for lock, reveal, and (in adversarial paths) refund. +4. **Per-trade matching.** No protocol-owned liquidity. Each swap requires a willing counterparty for the exact pair and size. Third-party summary: "you cannot easily swap large amounts because you need to find a specific peer willing to take the other side of that exact trade" ([xgram.io, 2026](https://xgram.io/blog/best-xmr-atomic-swaps-and-community-services-2026), accessed 2026-05-19). +5. **Pair coverage.** HTLC requires compatible scripting; adaptor signatures generalise this but each new pair requires cross-curve cryptographic work. BTC-XMR specifically took years of work between first published research and production implementation; see the primer for sourcing. -A cross-cutting onboarding constraint that every bonding RFP in this bundle adopts (RFP-022, RFP-025). +## Adoption record -The problem: a privacy-seeking taker arriving from XMR or BTC has no LEZ-denominated assets yet. Requiring them to acquire LEZ assets before their first swap, then lock those assets as a bond, is exactly the chicken-and-egg the cross-chain DEX is supposed to solve. +The two camps have produced very different volume outcomes. -The mechanic: +Federated-signer middle chains: -- First swap is capped at a small notional (worked example: US$100 equivalent), with no taker bond required. -- The cap is enforceable by the LEZ escrow program directly; no reputation registry needed. -- After completing the first swap, the taker has LEZ-denominated assets in their account. They can post these as a bond against larger swap sizes (or, if RFP-023 reputation is available, accrue reputation in lieu of bond). -- The cap value (US$100) is illustrative; applicants size it against expected free-option value at the protocol's typical lock window. +- **Thorchain cumulative swap volume** $112.201B as of 2026-05-19 (DefiLlama). 30-day volume $1.632B; annualised fees $29.76M; current TVL $70.24M. Source: [DefiLlama Thorchain DEX dashboard](https://defillama.com/protocol/thorchain-dex) (accessed 2026-05-19). +- **Wormhole cumulative transfer volume** $58.95B all-time (claimed); Portal Bridge DefiLlama figure $58.19B; 30-day volume $1.169B. Sources: [Connecting the Internet Economy (Wormhole blog, 2025-04-03)](https://wormhole.com/blog/connecting-the-internet-economy-wormhole-and-the-w-tokens-past-present-and) (accessed 2026-05-19); [Portal TVL on DefiLlama](https://defillama.com/protocol/portal) (accessed 2026-05-19). -Why this matters: it is the only way the bonding designs (RFP-022, RFP-025) provide a viable entry path for first-time takers without making them custody-tolerating or KYC-tolerating to acquire LEZ assets out of band. +Atomic-swap protocols: -## Synthesis +- **Liquality** reported "$35M in cross-chain atomic swaps facilitated through its wallet and interface" lifetime. Source: [defiprime.com: Liquality](https://defiprime.com/liquality) (accessed 2026-05-19). +- COMIT, Farcaster, AtomicDEX: no comparable cumulative-volume figure published. Recent activity in all three is community-scale rather than volume-scale. -The three mitigations combine, with each RFP in the bundle picking a different combination: +The gap is four orders of magnitude on cumulative volume in the published evidence. -| RFP | Mitigation 1 | Mitigation 2 | Mitigation 3 | Bondless taker | -|-----|--------------|--------------|--------------|----------------| -| RFP-021 (federated middle chain) | not applicable | not applicable | not applicable | not applicable | -| RFP-022 (bonded atomic swaps) | complementary (BTC, ETH) | core mechanic (two tiers) | maker side | yes | -| RFP-023 (reputation-based) | not applicable | not applicable | core mechanic | inherits via cap | -| RFP-024 (sXMR pure) | not applicable | not applicable | not applicable | not applicable | -| RFP-025 (sXMR with SLA) | not applicable | LP-side bond (2a) or reserve (2b) | LP side | yes | +### Stated rationale from the projects themselves -The federated middle chain (RFP-021) sidesteps the free-option problem entirely by removing atomicity in favour of AMM-style execution. The bonded and reputation designs attack the free-option problem directly. The sXMR designs use atomic swaps as the redemption settlement layer rather than the DEX trading primitive, so the free-option problem appears in a different form (LP unavailability rather than counterparty defection). +The Thorchain account published a 2019-07-02 Medium post arguing that "bridges are superior to atomic swaps", citing liquidity gravity (peer-to-peer matching requires a counterparty per trade), user experience (multi-hour timelocks and CLI tooling), and pair coverage. Source: [Thorchain Medium, "Why Cross-Chain bridges are superior to Atomic Swaps" (2019-07-02)](https://medium.com/thorchain/why-cross-chain-bridges-are-superior-to-atomic-swaps-aebde263103c) (accessed 2026-05-19). -A reader choosing between the RFPs should ask: +Luke Parker (Serai lead developer) said directly in a MoneroTalk interview: "while I do love atomic swaps [..] I don't feel the community actually wants atomic swaps, which is a brutal truth" (timestamp 35:50). Parker explicitly groups Serai with Thorchain, Maya, and Chainflip rather than with Farcaster or COMIT. Source: [Monero Observer: MoneroTalk interview with kayabaNerve on Serai DEX](https://monero.observer/monerotalk-kayabanerve-interview-serai-dex/) (accessed 2026-05-19). -- Is custody acceptable in exchange for AMM liquidity and one-step UX? RFP-021. -- Is non-custody worth multi-hour settlement and interactivity, for BTC and ETH at scale? RFP-022 Tier 1. -- Is non-custody worth multi-hour settlement and interactivity for XMR specifically, accepting that Alice retains a residual pre-lock free option? RFP-022 Tier 2 plus RFP-023. -- Is reputation as economic gravity preferable to bonded collateral for the trust gradient? RFP-023. -- Is the requirement "synthetic XMR exposure inside LEZ DeFi composability" rather than "real XMR settlement"? RFP-024 (no SLA) or RFP-025 (with SLA). +The COMIT design corpus (RFC series, 25+ ADR-style spike documents, public blog) makes no mention of staking, reputation, or counterparty accountability mechanisms; the project relied entirely on timelock refund paths and adaptor-signature secrecy. Source: [comit-network/spikes/0017-negotiation-and-execution-protocol.adoc](https://github.com/comit-network/spikes/blob/master/0017-negotiation-and-execution-protocol.adoc) (accessed 2026-05-20). ## References -- [Bitcoin to Monero atomic swaps are now live (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) (accessed 2026-05-21) -- [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) (accessed 2026-05-21) -- [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332 (2021-01-29)](https://arxiv.org/abs/2101.12332) (accessed 2026-05-21) -- [Decred blog: On-Chain Atomic Swaps, 2017-09-20 (first on-chain atomic swap, Decred-Litecoin)](https://blog.decred.org/2017/09/20/On-Chain-Atomic-Swaps/) (accessed 2026-05-21) -- [comit-network/xmr-btc-swap (unmaintained since 2024-11; archival pending per issue #1791)](https://github.com/comit-network/xmr-btc-swap) (accessed 2026-05-21) -- [Thorchain Medium: Why Cross-Chain bridges are superior to Atomic Swaps (2019-07-02)](https://medium.com/thorchain/why-cross-chain-bridges-are-superior-to-atomic-swaps-aebde263103c) (accessed 2026-05-21) -- [Thorchain docs: Continuous Liquidity Pools](https://docs.thorchain.org/technical-documentation/thorchain-finance/continuous-liquidity-pools) (accessed 2026-05-21) -- [Thorchain docs: RUNE (bond-to-pooled ratio)](https://docs.thorchain.org/understanding-thorchain/rune) (accessed 2026-05-21) -- [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md) (accessed 2026-05-21) -- [Serai AMM docs](https://docs.serai.exchange/amm/) (accessed 2026-05-21) -- [Halborn: Wormhole Hack February 2022 (technical analysis)](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) (accessed 2026-05-21) -- [Crypto Times: $10.8M drained from Thorchain on 2026-05-15](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) (accessed 2026-05-21) -- [Monero, Zero to Monero 2.0 (whitepaper)](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) (accessed 2026-05-21) -- [Monero, FCMP++ announcement (2024-04-27)](https://www.getmonero.org/2024/04/27/fcmps.html) (accessed 2026-05-21) -- [defiprime.com: Liquality](https://defiprime.com/liquality) (accessed 2026-05-21) -- [Liquality discontinuation announcement (2024-05-20)](https://x.com/Liquality_io/status/1792678368694985162) (accessed 2026-05-21) +- [Thorchain DEX dashboard, DefiLlama](https://defillama.com/protocol/thorchain-dex) (accessed 2026-05-19) +- [Thorchain State of the Network February 2026](https://blog.thorchain.org/state-of-the-network-february-2026/) (accessed 2026-05-19) +- [Thorchain Bifrost TSS docs](https://dev.thorchain.org/bifrost/tss.html) (accessed 2026-05-19) +- [Thorchain RUNE bond-to-pooled docs](https://docs.thorchain.org/understanding-thorchain/rune) (accessed 2026-05-19) +- [Thorchain post-mortem: 2021 ETH router exploits](https://medium.com/thorchain/post-mortem-eth-router-exploits-1-2-and-premature-return-to-trading-incident-2908928c5fb) (accessed 2026-05-19) +- [Thorchain Medium: "Why Cross-Chain bridges are superior to Atomic Swaps" (2019-07-02)](https://medium.com/thorchain/why-cross-chain-bridges-are-superior-to-atomic-swaps-aebde263103c) (accessed 2026-05-19) +- [Crypto Times: $10.8M Thorchain GG20/TSSHOCK exploit (2026-05-17)](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) (accessed 2026-05-19) +- [AMBCrypto: Thorchain MPC wallet concerns](https://ambcrypto.com/thorchain-exploit-raises-fresh-concerns-over-mpc-wallet-security/) (accessed 2026-05-19) +- [serai.exchange](https://serai.exchange/) (accessed 2026-05-19) +- [Audit of Serai's Substrate Blockchain (2026-04-15)](https://serai.exchange/2026/04/15/serai-blockchain-audited.html) (accessed 2026-05-19) +- [Announcing monero-oxide / FROSTLASS CLSAGs (2025-09-09)](https://serai.exchange/2025/09/09/monero-serai-oxide.html) (accessed 2026-05-19) +- [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md) (accessed 2026-05-19) +- [Monero Observer: MoneroTalk interview with kayabaNerve on Serai DEX](https://monero.observer/monerotalk-kayabanerve-interview-serai-dex/) (accessed 2026-05-19) +- [Wormhole Guardians docs](https://wormhole.com/docs/protocol/infrastructure/guardians/) (accessed 2026-05-19) +- [Portal TVL on DefiLlama](https://defillama.com/protocol/portal) (accessed 2026-05-19) +- [Connecting the Internet Economy (Wormhole, 2025-04-03)](https://wormhole.com/blog/connecting-the-internet-economy-wormhole-and-the-w-tokens-past-present-and) (accessed 2026-05-19) +- [Halborn: Wormhole Hack February 2022](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) (accessed 2026-05-19) +- [Han et al., On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) (accessed 2026-05-19) +- [comit-network/spikes/0017-negotiation-and-execution-protocol.adoc](https://github.com/comit-network/spikes/blob/master/0017-negotiation-and-execution-protocol.adoc) (accessed 2026-05-20) +- [github.com/comit-network/xmr-btc-swap](https://github.com/comit-network/xmr-btc-swap) (accessed 2026-05-19) +- [github.com/farcaster-project](https://github.com/farcaster-project) (accessed 2026-05-19) +- [xgram.io: Best Monero atomic swap platforms 2026](https://xgram.io/blog/best-xmr-atomic-swaps-and-community-services-2026) (accessed 2026-05-19) +- [Komodo Platform Roadmap](https://roadmap.komodoplatform.com/) (accessed 2026-05-19) +- [BitDegree: AtomicDEX trading data](https://www.bitdegree.org/top-crypto-exchanges/atomicdex) (accessed 2026-05-19) +- [Nomics: AtomicDEX](https://nomics.com/exchanges/atomicdex) (accessed 2026-05-19) +- [Liquality on X: discontinuation (2024-05-20)](https://x.com/Liquality_io/status/1792678368694985162) (accessed 2026-05-19) +- [Rootstock Helpdesk: Liquality](https://helpdesk.rootstock.io/solutions/liquality.html) (accessed 2026-05-19) +- [defiprime.com: Liquality cross-chain atomic swaps](https://defiprime.com/liquality) (accessed 2026-05-19) diff --git a/appendix/sxmr-design-space.md b/appendix/sxmr-design-space.md deleted file mode 100644 index 0152c09..0000000 --- a/appendix/sxmr-design-space.md +++ /dev/null @@ -1,247 +0,0 @@ -# sXMR Design Space: Synthetic XMR on LEZ - -Background appendix for RFP-024 (sXMR pure non-custodial) and RFP-025 (sXMR with redemption SLA). Establishes the three design goals these RFPs partition between and the trade-offs that distinguish them. - -## What sXMR is - -A synthetic Monero token deployed as a program on the canonical Logos Execution Zone (LEZ). Oracle-priced for trading and composability inside LEZ; redeemed to real XMR via peer-to-peer atomic swap with no central custodian, no bridge, and no protocol-held reserves. - -The wedge: the only currently published, live synthetic whose redemption deposits real XMR on Monero L1 *non-custodially, via peer-to-peer atomic swap*. sBTC (Stacks) redeems to public BTC, leaving the destination on a transparent ledger. Every other commodity synthetic (sBTC variants, sETH, sLINK) redeems to traceable transparent assets. The closest prior art is custodial: Synthetix's historical sXMR token paired with the Secret Network Monero Bridge offered XMR-L1 redemption under signer-set custody (the same trust model Goal 2b accepts); Haven Protocol's xAsset family offered synthetics on a dedicated privacy chain but closed in December 2024 and never offered xXMR. This design is the first where the redemption path itself preserves privacy *and* avoids custody. - -Honest framing: this is a synthetic with a soft, market-clearing peg, not a hard-redeemable synthetic. The oracle is the *quoted* price; the *achievable* price is whatever an XMR LP will swap for, when one is willing. Structurally closer to a DEX trading pair than to sBTC (Stacks). - -The RFP set picks one of two product directions before specifying further. They are incompatible at the architectural level: - -- **Non-custodial, mostly-works** (RFP-024). Pure atomic-swap design ships. Soft peg, market-dependent exit. The interesting product for privacy maximalists. -- **Always real XMR at oracle price** (RFP-025). Requires bonded LPs (slashable stable collateral on LEZ) or a protocol XMR reserve. Custody or solvency risk returns. The marketable product for SLA-needing audiences. - -## Goal 1: non-custodial, mostly-works - -The premise of RFP-024. - -### Properties - -- **Non-custodial.** No vault holds XMR. No signer set. No bridge. -- **Soft peg.** Oracle is a reference; achievable redemption price is whatever an LP quotes. Spread widens under stress without bound. -- **No redemption guarantee.** Counterparty may not exist when you want to exit. -- **Composable on LEZ.** sXMR is a vanilla LEZ token, callable by any other LEZ program (lending, DEX, governance). -- **Private exit.** Successful redemption deposits real XMR on Monero L1, severing the public trail. -- **Open LP set.** Anyone with XMR can quote; no permission required. -- **Regulatory minimalism.** Protocol does not handle XMR; arguably just a price feed plus a matching board. - -### High-level flow - -``` - sXMR LEZ program oracle (XMR/USD) Oracle program on LEZ - (token + stable vault) <----------------- - - mint | burn - - Intent gossip match Open XMR LPs - (off-chain, via Logos (anonymous, free - Delivery) to enter/exit) - sXMR <--> XMR quotes - - atomic swap (adaptor-sig) - LEZ <----------------------> Monero L1 - - sXMR holder gets XMR XMR LP gets sXMR, - on Monero L1 burns for stable -``` - -### Failure modes - -1. **LP exodus.** All XMR holders stop quoting. sXMR trades at an indefinite discount to oracle. -2. **Adverse selection.** LPs only show up when oracle is below true XMR price (free money for them) and vanish when oracle is above (would-be loss). Redemption is asymmetric across regimes. -3. **Demand asymmetry.** Easy to mint sXMR (privacy-curious DeFi users want it); harder to source LPs (XMR maximalists may not want a public LP role at all). -4. **User experience cost.** Monero atomic swap windows are dominated by Monero block confirmations, typically under an hour but with variance from network conditions; both parties must be online unless an intent layer is built on top. - -### When this fits - -- Privacy-maximalist user base willing to accept variable redemption. -- Use cases that need sXMR for trading exposure rather than guaranteed redemption (DeFi composability, hedging, speculation). -- Builders willing to ship the cryptographically pure version and let the market clear. - -## Cross-cutting design challenge - -Two questions that affect both Goal 1 and Goal 2. - -### The orderbook probably should not be on-chain - -An on-chain orderbook (whether on the canonical LEZ or anywhere else) is expensive, leaks intent publicly (which undermines the privacy story), and provides no security benefit: the atomic swap is what makes settlement trustless, not the matching layer. A better split: - -- **Off-chain matching via Logos Delivery.** LPs broadcast quotes; redeemers broadcast intents; parties pair up bilaterally. Quotes and intents never hit chain state. -- **On-chain settlement only.** A minimal LEZ program that verifies the atomic-swap primitive (lock, reveal, refund) on the LEZ side. It knows nothing about prices, identities, or who matched with whom. - -This also aligns better with the privacy proposition: an on-chain orderbook would be a public registry of "everyone trying to acquire real XMR right now." - -### Atomic-swap execution is hard to enforce on-chain - -Atomic swaps are deliberately symmetric: either party can refuse the next message at any stage, and both sides refund at timeout. On-chain evidence cannot distinguish: - -- An LP maliciously refusing to proceed. -- An LP whose node went down or lost connectivity. -- A redeemer never locking their side, making the LP's non-lock correct behaviour. -- A redeemer locking and then refusing to reveal, blaming the LP. - -This is the whole point of an atomic swap: nobody can be forced to complete, and nobody loses funds if they walk away. - -Critically, this means an atomic swap behaves like a free option for whichever party acts next. Stage by stage: - -1. **Alice (redeemer) locks sXMR on LEZ.** Bob (LP) now holds a free option: if the XMR price has moved in his favour since the quote, he locks his XMR and the swap proceeds; if it has moved against him, he simply does not lock. Alice's sXMR refunds at timeout. Bob has paid only the cost of waiting and gained the optionality of letting an adverse swap expire. -2. **Bob (LP) locks XMR on Monero.** Alice now holds the same free option in reverse. If the price has moved in her favour, she completes the swap by revealing the secret; if it has moved against her, she does not reveal. Both sides refund. Alice has paid only fees. -3. **Secret reveal.** Once the secret is revealed by either side, the swap completes; this is the only stage where the protocol is no longer optional. - -So at every stage before completion, the next party to act has a no-cost-beyond-fees option to abandon the swap based on price movement during the lock window. The "swap" is in effect a short-dated American option that either party can let expire. - -This is well-known in the atomic-swap literature (the "free option problem"). It is not a bug in any particular implementation; it is the cost of atomicity itself. The cross-cutting [trust-model contrast appendix](./cross-chain-trust-model-contrast.md) covers the mitigations in depth. - -Consequently, **a clean "LP defaulted, slash the bond" rule is not enforceable from on-chain state alone.** Refusing to proceed is *valid behaviour* under the protocol, not a default. Any slashing or "punishment" mechanism needs an off-chain attestation of who refused, which means one of: - -- A trusted attestor or committee deciding default, which reintroduces centralised trust. -- A reputation system, which is only useful at scale and cannot enforce against first-time defection. -- A multi-attestor oracle quorum watching both chains, which adds its own trust assumption and liveness requirement. - -Without one of those, the on-chain program can only do one thing: deny future LP slots, queue priority, or fee tiers. It cannot slash collateral with cryptographic certainty. - -### Implication for Goal 2 - -- **Goal 2a (bonded LPs)** is structurally weaker than its description suggests. The bond cannot be slashed on a simple "LP refused" condition; any real slashing requires a reputation or attestor system layered on top. Read the design as best-effort with a reputation layer (consuming the primitive from RFP-023), not as cryptographically guaranteed redemption. -- **Goal 2b (protocol reserve)** is unaffected by the symmetry problem; trust simply lives in the signer set instead. - -## Goal 2: always real XMR at oracle price - -The premise of RFP-025. sXMR must be redeemable for real XMR at (or very near) the oracle price, on demand. The atomic swap is still the settlement primitive, but counterparty availability is no longer left to the open market. The protocol either commits LPs to honour redemption or holds an XMR reserve itself. - -Two sub-designs, each restoring some trust that Goal 1 deliberately avoided. RFP-025 puts the choice between them to applicants. - -### Sub-design 2a: bonded LP set - -LPs join a registered set. Each LP posts stable collateral on LEZ equal to (or some multiple of) their XMR commitment. When a redemption request is routed to an LP, they must complete the atomic swap within a window. If they default, their bond is slashed and paid to the redeemer. LPs may leave the set, but only after a notice period that exceeds the redemption SLA. - -Enforceability caveat (see the cross-cutting section above): "LP defaulted" is not a verdict an on-chain program can render from atomic-swap state alone. Any slashing rule needs an off-chain attestor or a reputation system to attribute fault. Without one, the bond can be used to gate participation (priority, fee tiers, future-slot access) but not slashed with cryptographic certainty on a single failed swap. The realistic implementation consumes the RFP-023 reputation primitive as the attribution layer. - -``` - sXMR LEZ program - + LP registry - + slashing logic - - redemption request LP bond - - sXMR holder Bonded LP - burns sXMR, <----- atomic swap posts stable bond, - receives XMR (adaptor-sig, delivers XMR or - SLA) forfeits bond - - if LP defaults: bond is paid out as compensation, - reputation attests non-delivery -``` - -### Sub-design 2b: protocol XMR reserve - -The protocol accumulates an XMR reserve from mint fees, a yield programme, or a one-time treasury seed. Reserve is held in a threshold-signer multisig or analogous custody arrangement on Monero. Redemption draws from the reserve directly, with the atomic swap acting as the settlement rail between the reserve custodian and the redeemer. - -``` - sXMR LEZ program - + reserve accounting - - burn sXMR trigger swap - - Reserve module - (LEZ program) - - atomic swap - - Threshold-signer reserve on Monero - (n-of-m, bonded signers) -``` - -At this point the design has reinvented sBTC (Stacks) with an oracle bolted on. The atomic swap is just the wire format; trust lives in the signer set. The same view-key-shared TSS custody constraint applies as in RFP-021 (Serai-like federated middle chain): honest-but-curious signers learn the protocol-side deposit history. This is the structural trade-off Goal 2b accepts in exchange for the redemption SLA. - -### Properties comparison - -| Property | 2a Bonded LPs | 2b Protocol reserve | -|----------|---------------|---------------------| -| Custodian | None (LPs custody their own XMR) | Yes (signer set) | -| Redemption guarantee | Up to total bonded capacity | Up to reserve size | -| Slashing surface | Yes (bond slashed on default, attested via reputation) | No (reserve is the slashing) | -| Oracle role | Pricing plus default attestation | Pricing only | -| LP economics | Yield from spreads plus protocol incentives, less bond opportunity cost | Not applicable (no third-party LPs) | -| Decentralisation | High (anyone can be a bonded LP if they post the bond) | Low (signer set is gated) | -| Censorship resistance | Medium (LP set is registered) | Low (signers are known) | -| Best-case redemption speed | Atomic swap (Monero-confirmation-bound; typically under an hour) | Atomic swap (Monero-confirmation-bound; typically under an hour) | -| Failure mode | Bond runs out under coordinated default | Signer collusion or custody breach | - -### When this fits - -- Audiences that need a redemption SLA (institutions, market makers, structured products). -- Use cases where sXMR is collateral inside other protocols and a stable peg matters more than purist non-custody. -- Regulatory contexts where "guaranteed redemption" is a feature, not a liability. - -### Failure modes - -- **Bonded LPs (2a):** coordinated default exceeds bonded capacity; the slashing oracle for default attestation is itself a trusted component; bond opportunity cost limits LP supply. -- **Protocol reserve (2b):** signer set is a target; if reserve is undercollateralised, peg breaks; effectively recreates sBTC (Stacks) custody risk. The TSS custody also leaks deposit history to signers (the Monero privacy break called out in the [trust-model contrast appendix](./cross-chain-trust-model-contrast.md)). - -## Property matrix across goals - -| Property | Goal 1 (pure) | Goal 2a (bonded LPs) | Goal 2b (reserve) | sBTC (reference) | -|----------|---------------|----------------------|-------------------|------------------| -| Custodian | None | None (LPs self-custody) | Yes | Yes | -| Reserve | None | None | Yes | Yes | -| Redemption guarantee | None | Bounded by bonds | Bounded by reserve | Bounded by reserve | -| Peg type | Soft | Hard within capacity | Hard within capacity | Hard 1:1 | -| Oracle dependency | Pricing | Pricing plus default attestation | Pricing | None for peg | -| LP role | Optional, open | Registered, bonded | None | None | -| Privacy on redemption | Yes (XMR L1) | Yes (XMR L1) | Yes (XMR L1) | No (BTC L1) | -| Worst-case failure | Indefinite discount, no exit | Bond depleted, partial exit | Signer compromise, full loss | Signer compromise, full loss | -| Closest existing analogue | DEX trading pair | Bonded relay (no direct analogue) | sBTC (Stacks) | sBTC (Stacks) | - -## Decision tree - -``` - Does the design need a redemption SLA? - - no yes - - - Goal 1 (pure) Does the protocol accept custody risk? - RFP-024 - no yes - - - Goal 2a (bonded LPs) Goal 2b (reserve) - RFP-025 option (a) RFP-025 option (b) - (oracle-priced sBTC) -``` - -## Pre-spec validation - -Before committing to either goal, applicants should validate: - -1. **Atomic swap UX with Monero today.** Live protocols (eigenwallet/unstoppableswap fork of comit-network/xmr-btc-swap, Farcaster) impose settlement times dominated by Monero block confirmations, typically under an hour but with variance, and require both parties online. Applicants should measure the actual distribution against a recent client release rather than rely on the indicative range. Confirm async or intent-based variants are production-grade before designing UX around them. -2. **LP supply.** Will XMR holders actually LP? They self-select for privacy maximalism and may not want a public on-chain LP role. The LP side is the bottleneck; validate before designing the rest. -3. **Bond economics (Goal 2a only).** Required bond size as a multiple of XMR notional; opportunity cost of locked stable collateral on LEZ; expected APY needed to attract bonded LPs. -4. **Signer set sourcing (Goal 2b only).** Same problem space as sBTC (Stacks); revisit that project's trust assumptions before reinventing them. Also revisit RFP-021's federated-middle-chain trust analysis, which covers the same TSS custody design space. -5. **Regulatory.** A synthetic that terminates in a privacy coin will draw scrutiny under any of the three designs. Goal 1 has the cleanest defence (protocol is a price feed and a matching board); Goal 2b has the weakest (protocol custodies XMR). - -## Bottom line - -- **Goal 1 (RFP-024)** is the most interesting design and the one with the strongest privacy story. It will not satisfy users who expect a redemption SLA. -- **Goal 2a (RFP-025 option a)** is the most novel of the SLA-bearing designs: non-custodial, atomic-swap-settled, but with bonded LPs underwriting redemption capacity. No direct analogue exists in the published landscape. Depends on RFP-023 reputation for default attribution. -- **Goal 2b (RFP-025 option b)** is a real product but, structurally, an oracle-priced sBTC (Stacks) for Monero. The atomic swap is cosmetic; the trust assumption is the signer set. - -Pick the goal before writing the spec. The three designs have different threat models, different LP economics, and different regulatory exposures. - -## References - -- [sBTC (Stacks) Bitcoin layer documentation](https://docs.stacks.co/learn/sbtc) (accessed 2026-05-21) -- [Synthetix SIP-302: V3 collateral and snxUSD minting (CDP reference)](https://sips.synthetix.io/sips/sip-302/) (accessed 2026-05-21) -- [eigenwallet/core (XMR atomic swap, active fork of comit-network/xmr-btc-swap; v4.6.1, 2026-05-15)](https://github.com/eigenwallet/core) (accessed 2026-05-21) -- [Farcaster project (XMR atomic swap; low-velocity, last release v0.8.4 on 2023-01-16)](https://github.com/farcaster-project/farcaster-node) (accessed 2026-05-21) -- [Bitcoin to Monero atomic swaps (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) (accessed 2026-05-21) -- [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) (accessed 2026-05-21) -- [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332](https://arxiv.org/abs/2101.12332) (accessed 2026-05-21) -- [Secret Network Monero Bridge (custodial XMR-to-Secret Network bridge, structural counter-example for the "only synthetic terminating in XMR L1" wedge)](https://docs.scrt.network/secret-network-documentation/development/snip-20-secret-tokens/snip-721-secret-nfts) (accessed 2026-05-21) -- [Haven Protocol shutdown notice (December 2024; historical xAsset family of privacy-chain synthetics)](https://havenprotocol.org/) (accessed 2026-05-21) -- [Han et al., On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) (accessed 2026-05-21) diff --git a/appendix/synthetics-design-space.md b/appendix/synthetics-design-space.md new file mode 100644 index 0000000..e74454e --- /dev/null +++ b/appendix/synthetics-design-space.md @@ -0,0 +1,89 @@ +# Synthetics Design Space + +Survey appendix on deployed synthetic-asset designs and what each protocol commits to (and trusts) at the redemption boundary. Pure survey of deployed and historical synthetics; no design choices made here. + +A "synthetic" in this appendix means a token on chain A that tracks the price of an asset on chain B (or an off-chain reference) without being a direct wrapping of that asset. Pure wrapped tokens (one-to-one custody-backed representations) are out of scope. + +## Taxonomy + +Deployed synthetic designs differ on two axes: + +1. **What backs the synthetic.** Stable collateral (over-collateralised CDP), the underlying asset itself (custody-backed), or no backing at all (pure pegged float). +2. **What redemption means.** Convertible to the underlying asset at oracle price, convertible to the collateral at oracle price, or not redeemable but freely tradable. + +The deployed examples populate three corners of this space: + +### Oracle-priced over-collateralised synthetics + +Synthetics minted against stable collateral, valued by oracle, settled in collateral rather than the tracked asset. + +- **Haven Protocol (XHV / xUSD / other xAssets).** Monero-forked L1 launched 2018. Users lock XHV to mint xAssets at oracle price; conversion between xAssets burns the source and mints the destination. Over-collateralised. xUSD has depegged multiple times (notably 2022-2023) due to low liquidity, oracle delays, and market stress. As of 2026-05-22, XHV market cap is approximately $5.5M and xUSD supply approximately $1.2M; daily transactions approximately 50-100. Sources: [Haven Protocol Documentation](https://docs.havenprotocol.org) (accessed 2026-05-22); [CoinGecko: Haven (XHV)](https://www.coingecko.com/en/coins/haven) (accessed 2026-05-22); [Haven Explorer](https://explorer.havenprotocol.org) (accessed 2026-05-22). Note: prior PR-57 appendix text stated Haven shut down in December 2024; this claim has been flagged for vault verification as it does not match the current explorer/market-cap data above. +- **Synthetix.** SNX stakers mint sUSD and other synthetic equivalents against SNX collateral, debt pooled across all stakers. Used as a reference for "oracle-priced over-collateralised synth" rather than for a specific Monero-relevant property here. Note: prior PR-57 appendix text cited SIP-302 as the canonical reference for V3 collateral and snxUSD minting; this citation has been flagged for vault verification. + +What you trust in this design family: + +- The oracle. A compromised oracle is an infinite-mint vulnerability. +- The collateralisation ratio holds under price-of-collateral stress (otherwise the protocol becomes insolvent against outstanding synthetics). +- The liquidation mechanism executes faster than collateral price collapse. + +Privacy properties (Haven specifically): Monero-style ring signatures and stealth addresses protect transfers of xAssets, but Haven has no smart-contract layer, so xAssets cannot be used in DeFi outside Haven itself. + +### Redeem-to-underlying with custody + +Synthetics minted against the underlying asset held by a custodial bridge, valued by direct redemption. + +- **sBTC (Stacks).** Synthetic BTC on Stacks, redeemable to native BTC. The custody arrangement (signer set, threshold scheme, redemption SLA) has been flagged for vault verification before specific claims are made here. Canonical docs page: [docs.stacks.co/learn/sbtc](https://docs.stacks.co/learn/sbtc). This claim and its specific trust-shape characterisation have been added to the pending-research request for PR #57. +- **Secret Monero Bridge** (Secret Network). Mainnet launched August 2021. Multi-signature Monero wallet operated by consensus-node signers (MSCNOs) communicating over I2P; users deposit XMR, receive sXMR (a SNIP-20 token on Secret Network) usable in Secret DeFi (e.g. SecretSwap). Source: [Bitcoin Insider: Secret Monero Bridge mainnet launch](https://www.bitcoininsider.org/article/123189/secret-network-announces-launch-secret-monero-bridge-mainnet) (accessed 2026-05-22); [github.com/maxkoda-cpu/Secret-Monero-Bridge](https://github.com/maxkoda-cpu/Secret-Monero-Bridge) (accessed 2026-05-22). + +What you trust in this design family: + +- The custodian (signer set, multisig threshold). +- The cryptographic primitive combining signer contributions (TSS, multisig, FROST). +- The off-chain coordination among signers does not produce a censorship chokepoint or collusion path. + +This trust shape is structurally identical to a federated-signer middle chain (see the [trust-model contrast appendix](./cross-chain-trust-model-contrast.md)); the synthetic-token wrapper is cosmetic relative to the trust assumption. + +### Redeem-to-underlying without custody + +This design corner has no fully deployed example in the published landscape as of 2026-05. The Secret Monero Bridge above is custodial; the BTC-XMR atomic-swap projects (COMIT, Farcaster) execute peer-to-peer swaps but do not issue a synthetic token at all. A redeem-to-underlying synthetic where redemption itself is peer-to-peer-atomic and the protocol never custodies the underlying is a published design space but not a published implementation. + +## Privacy-coin specific constraints + +Synthetic designs that target Monero (or other privacy coins) inherit constraints from the underlying: + +- **No SPV-style proof of state.** Monero has no proof primitive that can demonstrate "address Y received amount X" to a third party without view-key disclosure. Bilateral proofs (`check_tx_proof` family) exist but lifting them to public on-chain state is equivalent to view-key disclosure for the swap output, which deanonymises the swap. Sources: [Monero, Zero to Monero 2.0 §Payment Proofs](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) (accessed 2026-05-21). +- **Custody-side privacy leak.** Threshold custody of XMR requires view-key sharing among signers. Honest-but-curious signers learn the deposit history of the synthetic-side mint and burn flow. This is a property of any TSS custody of XMR, including the most advanced production design (Serai's FROSTLASS over CLSAG); see the [trust-model contrast appendix](./cross-chain-trust-model-contrast.md). +- **No native smart contracts on Monero.** Designs that want programmability over a Monero-backed synthetic must run that programmability on a separate chain; the synthetic and its DeFi context are necessarily off Monero. +- **Future cryptographic primitives.** The FCMP++ (full-chain membership and metadata-private proofs) research direction may unlock new non-disclosing proof variants; it is pre-production. Source: [Monero, FCMP++ announcement (2024-04-27)](https://www.getmonero.org/2024/04/27/fcmps.html) (accessed 2026-05-21). + +## Negative example: Secret Monero Bridge + +The Secret Monero Bridge is the closest deployed prior art for bridging XMR into a programmable privacy ecosystem. The documented launch reception is instructive: + +1. **Trusted operator model without economic security.** The bridge used a multi-signature Monero wallet controlled by consensus-node operators. There was no bonded collateral, no slashing, and no cryptographic proof of correctness. Security relied on social trust plus I2P anonymisation of the operator network. Source: [`maxkoda-cpu/Secret-Monero-Bridge`](https://github.com/maxkoda-cpu/Secret-Monero-Bridge) (accessed 2026-05-22). +2. **Privacy-hostile onboarding UX.** The mainnet release required users to provide an email address and use Discord for support tickets; the Monero community viewed this as antithetical to privacy principles and widely refused to use the bridge. Source: vault note `projects/secret-network.md` documents this controversy; the primary documentation is Bitcoin Insider's launch coverage and contemporary Monero-community forum discussions, both available via the cited launch announcement. +3. **Unclear current status.** As of 2025-2026 the GitHub repository has limited recent activity and community forum posts question whether the bridge is still maintained. Source: [`maxkoda-cpu/Secret-Monero-Bridge`](https://github.com/maxkoda-cpu/Secret-Monero-Bridge) (accessed 2026-05-22). + +These are properties of the bridge's design and reception; whether any specific lesson applies to a future synthetic depends on the future synthetic's own choices and is left to the relevant RFPs. + +## How minting works in deployed synthetic protocols + +Common patterns across the deployed examples: + +- **Lock collateral, mint synthetic at oracle price** (Haven xAssets, Synthetix sUSD). The collateral is the protocol's native token (or a basket); the synthetic is valued by oracle at mint. Over-collateralisation absorbs price moves. +- **Deposit underlying, mint synthetic 1:1 minus fees** (Secret Monero Bridge sXMR, sBTC on Stacks). The synthetic is a wrapped representation; mint is custodial, burn unlocks the underlying. +- **No deployed example exists** for a synthetic that mints against stable collateral *and* redeems to the underlying via peer-to-peer atomic swap. This is the design space targeted by the bundle's sXMR RFPs. + +## References + +- [Haven Protocol Documentation](https://docs.havenprotocol.org) (accessed 2026-05-22) +- [Haven Protocol Whitepaper](https://havenprotocol.org/whitepaper/) (accessed 2026-05-22) +- [CoinGecko: Haven (XHV)](https://www.coingecko.com/en/coins/haven) (accessed 2026-05-22) +- [Haven Explorer](https://explorer.havenprotocol.org) (accessed 2026-05-22) +- [Secret Network documentation](https://docs.scrt.network) (accessed 2026-05-22) +- [Bitcoin Insider: Secret Monero Bridge mainnet launch](https://www.bitcoininsider.org/article/123189/secret-network-announces-launch-secret-monero-bridge-mainnet) (accessed 2026-05-22) +- [`maxkoda-cpu/Secret-Monero-Bridge`](https://github.com/maxkoda-cpu/Secret-Monero-Bridge) (accessed 2026-05-22) +- [Secret Monero Bridge Devpost](https://devpost.com/software/secret-monero-bridge) (accessed 2026-05-22) +- [Monero, Zero to Monero 2.0 (whitepaper)](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) (accessed 2026-05-21) +- [Monero, FCMP++ announcement (2024-04-27)](https://www.getmonero.org/2024/04/27/fcmps.html) (accessed 2026-05-21) +- [docs.stacks.co/learn/sbtc](https://docs.stacks.co/learn/sbtc) (referenced; specific trust-shape claims pending vault verification) From d67958a343974a39bce2ba5ff2067559128ffc0a Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 22 May 2026 16:51:14 +1000 Subject: [PATCH 08/17] rfp: move bundle design content into RFPs; apply PR-57 review fixes Completes the appendix/RFP split started in the previous commit. RFP-022 (Bonded Atomic Swaps): - Reframe bonds as the *price of the free option* at each phase boundary (per the comment-7 walk-through). Bond is sized at or above sigma*sqrt(T)*notional; bond posts at Commit; refunds on honest completion or slashes on default. - Drop the B_bob_slice slicing concept (comments 3, 5). Use full B_alice and B_bob bonds posted atomically at Commit. - Drop the Bob-broadcasts-BTC hop (comment 4). Alice broadcasts the BTC lock directly; inclusion-proof submitter remains unauthenticated. - Fix Phase 3 row to lock only trade_amount, not the bond (comment 5). - Add an option-pricing audit subsection naming, per phase boundary, who is short the option, who is long, and which bond prices it. - Add a direction-symmetry note (comment 6): for LEZ-XMR, the protocol- level asymmetry is direction-independent; XMR-side party always holds the unverifiable lock; roles flip across taker/maker. - Add a Tier 2 option-pricing audit and explicitly mark the Phase 2 boundary as non-bond-priceable (trigger event off-LEZ); reputation plus maker market competition only. - Defer the off-chain verifiable maker reputation question to RFP-023 with a one-paragraph pointer. - Update appendix links to point at atomic-swaps-primer.md and cross-chain-trust-model-contrast.md (the survey appendix). RFP-023 (Reputation-Based Atomic Swaps): - Add a Slashable-event matrix and reputation counter design section (comment 8): per-event matrix showing LEZ-observable / slashable / reputation-counter triples. "Zero slashes" is too crude for LEZ-XMR; registry must track completed_count, slashed_count, abandoned_pre_xmr_lock_count, and disputed_attestation_count separately. zk membership proofs claim against per-counter thresholds. - Add Off-chain verifiable maker reputation section: open question about whether the non-slashable abandonment paths can be made third-party-verifiable via a proof bundle (signed quote + Monero lock + view-key material + LEZ no-show). Sub-questions: privacy cost, distribution, aggregation, spam resistance, defense, threshold. RFP-024 (sXMR Pure): - Rewrite the wedge paragraph to remove unverifiable claims (Synthetix-sXMR-paired-with-Secret-Monero-Bridge, Haven shutdown date, sBTC public-BTC-redemption specifics). Replaced with what is sourced in the vault: Secret Monero Bridge as deployed custodial prior art; Haven xAssets as a Monero-forked privacy-chain synth family without an xXMR product; sBTC and sETH-family synths as redeem-to-transparent-assets. - Update appendix references; remove stale Farcaster v0.8.4 citation (already documented in research vault as misleading). - Point references at atomic-swaps-primer.md, synthetics-design-space.md (renamed), and cross-chain-trust-model-contrast.md. RFP-025 (sXMR with SLA): - Update appendix references to point at synthetics-design-space.md and atomic-swaps-primer.md. The Option 2a (bonded LPs) and Option 2b (protocol reserve) design content was already in this RFP and remains unchanged. - Flag the sBTC trust-shape citation as pending vault verification. Appendix touch-ups: - atomic-swaps-primer.md: minor formatting from mdformat. - cross-chain-trust-model-contrast.md: mdformat reflow. - synthetics-design-space.md: mdformat reflow. All sourcing gaps are tracked in marclawclaw/research-cross-chain-dex/projects/PENDING-atomic-swap-protocol-details.md for a researcher pass; flagged annotations in the appendices will be cleaned up once the pending claims are verified. Co-Authored-By: Claude Opus 4.7 (1M context) --- RFPs/RFP-022-bonded-atomic-swaps.md | 404 +++++++++++++++---- RFPs/RFP-023-reputation-atomic-swaps.md | 329 ++++++++++++--- RFPs/RFP-024-synthetic-xmr-pure.md | 246 ++++++++--- RFPs/RFP-025-synthetic-xmr-sla.md | 321 +++++++++++---- appendix/atomic-swaps-primer.md | 213 +++++++--- appendix/cross-chain-trust-model-contrast.md | 329 +++++++++++---- appendix/synthetics-design-space.md | 197 +++++++-- 7 files changed, 1624 insertions(+), 415 deletions(-) diff --git a/RFPs/RFP-022-bonded-atomic-swaps.md b/RFPs/RFP-022-bonded-atomic-swaps.md index e07a449..f823a6a 100644 --- a/RFPs/RFP-022-bonded-atomic-swaps.md +++ b/RFPs/RFP-022-bonded-atomic-swaps.md @@ -9,33 +9,107 @@ category: Applications & Integrations # RFP-022 — Bonded Atomic Swaps (Two Tiers) -> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos team and the community compare cross-chain DEX designs across RFP-021 through RFP-025. Hard requirements, team profile, timeline, and contracting details are deliberately omitted; they will be filled in if the design is selected for funding. +> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos +> team and the community compare cross-chain DEX designs across RFP-021 through +> RFP-025. Hard requirements, team profile, timeline, and contracting details +> are deliberately omitted; they will be filled in if the design is selected for +> funding. ## 🧭 Overview -Extend RFP-003 (Atomic Swaps with LEZ, open) with a maker/taker bond layer on LEZ that constrains the free-option problem inherent to atomic swaps. Bonds are posted on LEZ in stables or LEZ-native assets; slashing is conditioned on LEZ-observable failures to advance through the swap state machine. - -The design splits into two tiers that reflect a structural asymmetry in the underlying cryptography: - -- **Tier 1 (LEZ to BTC, LEZ to ETH).** Both sides' locks are verifiable on LEZ via a chain-watching light-client module. Both Alice's and Bob's bonds are slashable on default; full bilateral free-option mitigation. -- **Tier 2 (LEZ to XMR).** Alice's XMR lock cannot be proven on LEZ without revealing either the per-tx private key or the recipient view key (plus the output blinding factor), each of which is sufficient to deanonymise the swap output once submitted to world-readable LEZ state. Monero's bilateral `check_tx_proof` (OutProofV2 or InProofV2 variants per [Zero to Monero 2.0 §Payment Proofs](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf)) is the canonical disclosure-requiring proof; no SPV-style alternative exists pre-FCMP++. Bob's lock (on LEZ) remains observable, so Bob's bond is slashable; Alice's bond is slashable only on her LEZ-observable abandonment (failure to reveal after Bob has locked Logos). Alice keeps a residual pre-XMR-lock free option that only reputation (RFP-023) can constrain. - -The Bond layer is a strict superset of RFP-003. Builders should consume the per-pair SDKs from RFP-003 unchanged; this RFP adds the bond escrow contract, the bond accounting, and the LEZ-side proof verification primitives. +Extend RFP-003 (Atomic Swaps with LEZ, open) with a maker/taker bond layer on +LEZ that constrains the free-option problem inherent to atomic swaps. Bonds are +posted on LEZ in stables or LEZ-native assets; slashing is conditioned on +LEZ-observable failures to advance through the swap state machine. + +The bond is the **price of the free option** the protocol structurally creates +at each phase boundary. The locker is short an option (their leg is committed +for a window during which the counterparty can observe the market); the +counterparty is long the option. The bond is posted by the long-option party; on +default (exercising the abort branch) it slashes to the locker, settling the +option premium. On honest completion the bond refunds (option expired worthless, +no premium owed). Bond sized at or above option value (`σ × √T × notional`; see +[atomic-swaps primer](../appendix/atomic-swaps-primer.md#notation-for-option-value)) +makes the abort branch EV-negative and closes the free option. + +Locking order is fixed by the cryptographic primitive, not by design choice. The +[atomic-swaps primer §Generalising the locks-first rule across pairs](../appendix/atomic-swaps-primer.md#generalising-the-locks-first-rule-across-pairs) +sets out the rule; the specific lock-ordering for LEZ↔BTC and LEZ↔XMR is part of +the applicant's design output and must be justified against the primer's +framing. In the worked examples below, Alice locks first on the external chain +and Bob locks second on LEZ; this is the BTC-XMR convention lifted directly. +Applicants targeting other pairs (LEZ↔ETH especially, where both chains have +full scripting) must state the locking-order choice explicitly. + +The design splits into two tiers that reflect a structural asymmetry in the +underlying cryptography: + +- **Tier 1 (LEZ to BTC, LEZ to ETH).** Both sides' locks are verifiable on LEZ + via a chain-watching light-client module. Both Alice's and Bob's bonds are + slashable on default; full bilateral free-option mitigation. +- **Tier 2 (LEZ to XMR).** Alice's XMR lock cannot be proven on LEZ without + revealing either the per-tx private key or the recipient view key (plus the + output blinding factor), each of which is sufficient to deanonymise the swap + output once submitted to world-readable LEZ state. Monero's bilateral + `check_tx_proof` (OutProofV2 or InProofV2 variants per + [Zero to Monero 2.0 §Payment Proofs](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf)) + is the canonical disclosure-requiring proof; no SPV-style alternative exists + pre-FCMP++. Bob's lock (on LEZ) remains observable, so Bob's bond is + slashable; Alice's bond is slashable only on her LEZ-observable abandonment + (failure to reveal after Bob has locked Logos). Alice keeps a residual + pre-XMR-lock free option that only reputation (RFP-023) can constrain. + +The Bond layer is a strict superset of RFP-003. Builders should consume the +per-pair SDKs from RFP-003 unchanged; this RFP adds the bond escrow contract, +the bond accounting, and the LEZ-side proof verification primitives. ## Desired properties -- **Non-custodial.** No vault holds external assets; no signer set. Bonds live in LEZ-native assets on LEZ. -- **Free-option mitigation (Tier 1).** Symmetric bonding makes both sides' optionality strictly EV-negative when bonds are sized above the option value (`σ × √T × notional` is the standard option-pricing heuristic; an indicative range is 2 to 5% of trade notional for 1-hour windows, to be validated by applicants against actual observed BTC/ETH volatility). -- **Free-option mitigation (Tier 2).** Bob's optionality is closed by his slashable bond. Alice's post-Bob-lock optionality is closed by her bond. Alice's pre-XMR-lock optionality is *not* closed; this is the structural limit of the asymmetry. -- **Unauthenticated proof submitter.** Either party can broadcast the other's signed lock transaction (broadcasting is permissionless on every supported chain). The LEZ inclusion-proof submitter is also unauthenticated. This eliminates "attest or be slashed" grief vectors: a malformed lock simply never lands, the state machine times out, no slashing dispute occurs. -- **Bondless taker entry path.** First-time takers can complete a capped first swap (worked example: US$100 equivalent notional) without posting a taker bond. After the first swap, the taker has LEZ-denominated assets they can post as bond against larger swap sizes. This is enforceable by the LEZ escrow program directly; no reputation registry needed. -- **Upgrade clause for Tier 2.** When a non-disclosing Monero proof primitive becomes production-ready (FCMP++ or equivalent; in specification phase per [Monero, FCMP++ announcement, 2024-04-27](https://www.getmonero.org/2024/04/27/fcmps.html), accessed 2026-05-21), Tier 2 collapses into Tier 1: Alice's XMR lock becomes verifiable on LEZ without view-key disclosure, and the residual free option closes. -- **Composes with RFP-023 reputation.** Maker reputation (and zk-membership-proof taker reputation if available) compounds the cost of defection. In Tier 2 specifically, taker reputation is load-bearing because it is the only restraint on Alice's pre-lock free option. +- **Non-custodial.** No vault holds external assets; no signer set. Bonds live + in LEZ-native assets on LEZ. +- **Free-option mitigation (Tier 1).** Symmetric bonding makes both sides' + optionality strictly EV-negative when bonds are sized above the option value + (`σ × √T × notional` is the standard option-pricing heuristic; an indicative + range is 2 to 5% of trade notional for 1-hour windows, to be validated by + applicants against actual observed BTC/ETH volatility). +- **Free-option mitigation (Tier 2).** Bob's optionality is closed by his + slashable bond. Alice's post-Bob-lock optionality is closed by her bond. + Alice's pre-XMR-lock optionality is *not* closed; this is the structural limit + of the asymmetry. +- **Unauthenticated proof submitter.** Either party can broadcast the other's + signed lock transaction (broadcasting is permissionless on every supported + chain). The LEZ inclusion-proof submitter is also unauthenticated. This + eliminates "attest or be slashed" grief vectors: a malformed lock simply never + lands, the state machine times out, no slashing dispute occurs. +- **Bondless taker entry path.** First-time takers can complete a capped first + swap (worked example: US$100 equivalent notional) without posting a taker + bond. After the first swap, the taker has LEZ-denominated assets they can post + as bond against larger swap sizes. This is enforceable by the LEZ escrow + program directly; no reputation registry needed. +- **Upgrade clause for Tier 2.** When a non-disclosing Monero proof primitive + becomes production-ready (FCMP++ or equivalent; in specification phase per + [Monero, FCMP++ announcement, 2024-04-27](https://www.getmonero.org/2024/04/27/fcmps.html), + accessed 2026-05-21), Tier 2 collapses into Tier 1: Alice's XMR lock becomes + verifiable on LEZ without view-key disclosure, and the residual free option + closes. +- **Composes with RFP-023 reputation.** Maker reputation (and + zk-membership-proof taker reputation if available) compounds the cost of + defection. In Tier 2 specifically, taker reputation is load-bearing because it + is the only restraint on Alice's pre-lock free option. ## High-level functionality and flow ### Tier 1: LEZ to BTC (example) +Bond notation: + +- `B_alice` = Alice's full bond, posted on LEZ at Commit. +- `B_bob` = Bob's full bond, posted on LEZ at Commit. + +Both bonds are posted before any external-chain lock, so the bonds are always +already on LEZ when slash conditions trigger. No phase-by-phase bond slicing; +each phase boundary creates an option that one of the two bonds prices. + ```mermaid sequenceDiagram participant Alice @@ -48,18 +122,18 @@ sequenceDiagram Bob->>Alice: Signed quote (price, expiry, swap_id, refund_pubkeys) Note over Alice,Bob: Joint-key setup for 2-of-2 Taproot output - Note over Alice,LEZ: Phase 1 - Commit - Alice->>LEZ: Post B_alice referencing swap_id + Note over Alice,LEZ: Phase 1 - Commit (atomic, joint signature) + Alice->>LEZ: Post B_alice + Bob->>LEZ: Post B_bob - Note over Alice,Bob: Phase 2 - Lock-BTC - Alice->>Bob: Signed BTC lock tx bytes (over Waku) - Bob->>BTC: Broadcast lock tx (or Alice broadcasts herself if Bob stalls) + Note over Alice,BTC: Phase 2 - Lock-BTC + Alice->>BTC: Broadcast BTC lock tx directly BTC-->>LEZ: Inclusion proof (submitted by anyone:
headers + merkle + raw_tx) LEZ->>LEZ: Verify PoW, inclusion, scriptpubkey, amount - Note over LEZ: Slash window opens
If Bob does not advance:
B_bob_slice -> Alice + Note over LEZ: Slash window opens
If Bob does not advance in window:
B_bob -> Alice Note over LEZ,Bob: Phase 3 - Lock-Logos - Bob->>LEZ: Lock trade_amount + B_bob_slice conditioned on s + Bob->>LEZ: Lock trade_amount conditioned on s Note over Alice,LEZ: Phase 4 - Reveal Alice->>LEZ: Publish adaptor signature (reveals s) @@ -68,79 +142,265 @@ sequenceDiagram Note over Bob,BTC: Phase 5 - Settle Bob->>BTC: Claim BTC using s LEZ-->>Alice: Refund B_alice - LEZ-->>Bob: Release B_bob_slice + LEZ-->>Bob: Refund B_bob ``` -The unauthenticated proof submitter property: Bob can broadcast Alice's signed BTC lock himself; the LEZ inclusion-proof submitter is also unauthenticated (Bob, Alice, or a watchtower service can post the proof). If Alice signs a malformed lock (wrong amount, wrong scriptpubkey), Bob does not broadcast; the tx never lands on Bitcoin; the inclusion proof never materialises; the LEZ state machine quietly times out. No slashing dispute, no fraud-proof window. The swap fails closed because the precondition for state advancement (a real BTC lock) never holds. +Notes on the table: + +- **Phase 1 is atomic.** Both bonds are posted in the same LEZ transaction, + jointly signed. Abandonment at this point looks like abandoning a quote: + nobody is committed yet, no on-chain advancement occurred, no slash applies. + This eliminates a 1a/1b split where one party posts and the other doesn't. +- **Phase 2 has no Bob-broadcasts hop.** Alice broadcasts the BTC lock directly. + The LEZ inclusion-proof submitter remains unauthenticated (Bob, Alice, or a + watchtower service can post the proof once the BTC tx confirms). If Alice + signs and broadcasts a malformed lock (wrong amount, wrong scriptpubkey), the + LEZ contract rejects the inclusion proof, the state machine times out, both + bonds refund. No slashing dispute, no fraud-proof window. The swap fails + closed because the precondition for state advancement (a real BTC lock + matching the swap parameters) never holds. +- **Phase 3 locks only `trade_amount`.** Bob's bond `B_bob` was posted at Phase + 1 and remains in the bond escrow; Phase 3 is a separate lock of trade capital, + not the bond. This resolves an earlier draft where `B_bob` appeared both + spendable (slashable in Phase 2) and locked (Phase 3) in the same model. + +### Option-pricing audit + +For each phase boundary, name (a) who is short the option, (b) who is long the +option, (c) the premium instrument that prices it: + +| Boundary | Short the option (waiting) | Long the option (deciding) | Premium instrument | +| --------------------------------------- | ------------------------------------------------- | ----------------------------------------- | ---------------------------------------------- | +| After Phase 2 (BTC locked, Logos not) | Alice (her BTC is wedged for the timelock window) | Bob (he chooses whether to lock Logos) | `B_bob`, slashes to Alice on Bob's no-advance | +| After Phase 3 (Logos locked, no reveal) | Bob (his Logos is wedged) | Alice (she chooses whether to reveal `s`) | `B_alice`, slashes to Bob on Alice's no-reveal | +| After Phase 4 (reveal published) | nobody (settlement is deterministic) | n/a | n/a | + +Bond sizing must satisfy +`B_bob ≥ option_value(σ_BTC/Logos × √T_phase2 × notional)` and +`B_alice ≥ option_value(σ_BTC/Logos × √T_phase3 × notional)`. See the primer for +the notation. + +The audit closes the structural worry "are we adding new free options with each +phase?" by accounting for them: every boundary is named, the option holder is +named, and the bond pricing it is named. Phases without a one-sided commitment +(Phase 0 Quote, Phase 1 atomic Commit, Phase 5 Settle) create no option and need +no premium. + +### Direction symmetry + +The same phase table runs for the LEZ→BTC direction (a user wanting BTC +initiates against a BTC-holding maker) and the BTC→LEZ direction (a user with +BTC initiates against a Logos-holding maker). The locking order (BTC first, then +LEZ) is fixed by the cryptographic primitive (see overview); only the +taker/maker labels move. Bond sizing and slash conditions are +direction-symmetric. The same applies to LEZ↔ETH once the lock-ordering choice +is fixed for that pair. ### Tier 2: LEZ to XMR -Same phase structure, with the following differences: - -- Phase 2 (Lock-XMR): Alice's XMR lock is *not* verifiable on LEZ. The state machine cannot transition from Commit to Lock-Logos based on observation of Alice's Monero lock. Bob detects Alice's lock by running a Monero wallet himself (the bilateral `check_tx_proof` she sends him privately, which does *not* go on LEZ). Bob's decision to advance to Lock-Logos is off-chain. -- If Alice never locks XMR after Commit, the state machine times out; both bonds refund (no LEZ-observable default). Alice has paid only gas; she keeps her pre-XMR-lock free option. -- Phase 3 onwards: Bob's lock on LEZ is observable. From this point forward, Tier 2 matches Tier 1: Alice's bond is slashable on failure to reveal; Bob's bond is slashable on failure to complete after the reveal. +Same phase structure as Tier 1, with the following differences driven by +Monero's unverifiable lock state on LEZ: + +- **Phase 2 (Lock-XMR) is not LEZ-observable.** The state machine cannot + auto-transition from Commit to Lock-Logos based on Alice's Monero lock. Bob + detects Alice's lock by running a Monero wallet himself (Alice sends him the + bilateral `check_tx_proof` privately; this does *not* go on LEZ). Bob's + decision to advance to Lock-Logos is off-chain. +- **If Alice never locks XMR after Commit**, the state machine times out and + both bonds refund. There is no LEZ-observable default, so no slash applies. + Alice has paid only gas; she keeps her pre-XMR-lock free option. **This is the + residual asymmetry of Tier 2:** the option Bob bears at this boundary cannot + be priced by a bond, because the trigger event (Alice's XMR lock) is not + LEZ-observable. Maker market competition and reputation (RFP-023) are the only + available premium instruments. See "Open question" below. +- **Phase 3 onwards is identical to Tier 1.** Bob's lock on LEZ is observable. + Alice's bond `B_alice` slashes on failure to reveal after Bob's lock; Bob's + bond `B_bob` slashes on failure to complete after the reveal (per Tier 1 + mechanics). + +#### Option-pricing audit (Tier 2) + +| Boundary | Short the option | Long the option | Premium instrument | +| ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | -------------------------------------------- | ------------------------------------------------------------------------------------------- | +| After Phase 2 (XMR locked off-LEZ, Logos not locked) | Bob (he committed in good faith to source XMR; if Alice never locked, Bob saw nothing and waits out the timer) | Alice (chooses whether to actually lock XMR) | **None**. Trigger event not LEZ-observable. Reputation + market competition only (RFP-023). | +| After Phase 3 (Logos locked, no reveal) | Bob (his Logos is wedged) | Alice (chooses whether to reveal `s`) | `B_alice`, slashes to Bob on Alice's no-reveal | +| After Phase 4 (reveal published) | nobody | n/a | n/a | + +#### Direction symmetry (XMR↔LEZ) + +The same Tier-2 phase structure runs for both XMR→LEZ and LEZ→XMR. In both +directions, **the XMR-side party holds the unverifiable lock**: that's the +cryptographic constraint (Monero outputs cannot be proven to LEZ without +view-key disclosure). The roles flip relative to taker/maker but the +protocol-level asymmetry is the same: the XMR-side party is reputation-gated; +the LEZ-side party is bonded. + +For XMR→LEZ (a user wanting Logos pays in XMR): Alice in the table holds XMR; +the residual unpriced option is held by Alice; Bob (LEZ-side) is the party with +the on-chain bond that can be slashed if he fails to advance after Alice's XMR +lock — but Bob's failure-to-advance is what's not provable on LEZ. Same +asymmetry, mirrored. + +#### Open question: off-chain verifiable maker reputation + +Tier 2's residual unpriced option (Phase 2 boundary) is reputation-only. A +natural follow-up is whether the reputation signal can be made *verifiable* by +third parties off-chain, rather than relying purely on on-chain attestation plus +dispute fallback. This is treated as a reputation-mechanism question and the +discussion lives in +[RFP-023 §Off-chain verifiable maker reputation](./RFP-023-reputation-atomic-swaps.md#off-chain-verifiable-maker-reputation-lezxmr-open-question). +RFP-022 applicants should ensure the protocol primitives (anchored quote +signatures, deterministic stealth-address derivation, joint-key transcript +retention) make such a layer possible, even if the layer itself is left to +RFP-023. ### Bondless taker entry path -A taker without LEZ-denominated assets initiates a "first-swap" mode flagged in the LEZ escrow program: +A taker without LEZ-denominated assets initiates a "first-swap" mode flagged in +the LEZ escrow program: -- Trade notional capped at a small value (worked example: US$100 equivalent), sized against expected free-option value at the protocol's typical lock window. +- Trade notional capped at a small value (worked example: US$100 equivalent), + sized against expected free-option value at the protocol's typical lock + window. - No taker bond required. -- After completion, the taker has LEZ-denominated assets in their account from the swap proceeds. They can post these as bond against subsequent larger swaps. -- The cap is enforced by the LEZ escrow program; no reputation registry is required to make the cap binding. This decouples the bondless entry path from the (more complex) reputation infrastructure in RFP-023. +- After completion, the taker has LEZ-denominated assets in their account from + the swap proceeds. They can post these as bond against subsequent larger + swaps. +- The cap is enforced by the LEZ escrow program; no reputation registry is + required to make the cap binding. This decouples the bondless entry path from + the (more complex) reputation infrastructure in RFP-023. ## Pros -- **Closes the free-option problem cryptoeconomically for BTC and ETH (Tier 1).** No bilateral counterparty trust, no third-party attestation, no validator federation. The slash is enforced by the LEZ smart contract directly off the on-chain state of both chains. -- **Preserves the non-custodial property of atomic swaps.** No vault to drain, no TSS to break, no validator set to compromise. Funds never leave Alice's or Bob's control during the swap. -- **Builds cleanly on RFP-003.** Per-pair SDKs and the LEZ-side Risc0 escrow programs from RFP-003 are reused; this RFP layers on the bond escrow and the proof verification primitives. The dependency chain is clean. -- **Material improvement for the LEZ to XMR pair (Tier 2) on the maker side.** Bob's free option is closed even though Alice's lock is not verifiable on LEZ. This unblocks a category of makers who today refuse to post against atomic-swap takers because they can be free-optioned. -- **Bondless taker entry path solves the onboarding chicken-and-egg.** A privacy-seeking taker arriving from XMR or BTC does not need to acquire LEZ assets before their first swap. They complete a small first swap, accumulate LEZ assets, and bond from there. No KYC-tolerant on-ramp required. -- **Upgrade-clean for FCMP++.** When the non-disclosing Monero proof primitive ships, Tier 2 collapses into Tier 1 with no protocol-level rewrite. The RFP carries an explicit upgrade clause. +- **Closes the free-option problem cryptoeconomically for BTC and ETH (Tier + 1).** No bilateral counterparty trust, no third-party attestation, no + validator federation. The slash is enforced by the LEZ smart contract directly + off the on-chain state of both chains. +- **Preserves the non-custodial property of atomic swaps.** No vault to drain, + no TSS to break, no validator set to compromise. Funds never leave Alice's or + Bob's control during the swap. +- **Builds cleanly on RFP-003.** Per-pair SDKs and the LEZ-side Risc0 escrow + programs from RFP-003 are reused; this RFP layers on the bond escrow and the + proof verification primitives. The dependency chain is clean. +- **Material improvement for the LEZ to XMR pair (Tier 2) on the maker side.** + Bob's free option is closed even though Alice's lock is not verifiable on LEZ. + This unblocks a category of makers who today refuse to post against + atomic-swap takers because they can be free-optioned. +- **Bondless taker entry path solves the onboarding chicken-and-egg.** A + privacy-seeking taker arriving from XMR or BTC does not need to acquire LEZ + assets before their first swap. They complete a small first swap, accumulate + LEZ assets, and bond from there. No KYC-tolerant on-ramp required. +- **Upgrade-clean for FCMP++.** When the non-disclosing Monero proof primitive + ships, Tier 2 collapses into Tier 1 with no protocol-level rewrite. The RFP + carries an explicit upgrade clause. ## Cons -- **Does not fix settlement time.** Settlement is still bounded by source-chain finality plus LEZ finality plus the timelock window. Hours, not minutes. The bond does not accelerate cryptographic settlement. -- **Does not fix interactivity.** Both parties must be online to lock, reveal, and (if the other side defaults) submit the slash claim. The bond removes the incentive to grief but not the requirement to participate. -- **Per-trade matching, no AMM.** No protocol-owned liquidity, no AMM pricing. Each swap requires a willing counterparty for the exact pair and exact size. RFP-021 wins decisively on liquidity gravity. -- **Bond opportunity cost.** Makers must lock LEZ-denominated bond capital, which yields nothing during the lock window. This raises maker spreads relative to the unbonded (free-option) atomic swap of RFP-003. -- **Bond denomination friction.** First-time takers need LEZ-denominated bond assets. The bondless-taker capped-entry path mitigates this but only for the first swap. -- **Tier 2 is structurally weaker.** Alice retains a pre-XMR-lock free option on the LEZ to XMR pair. Reputation (RFP-023) is the only available restraint on this option under current Monero cryptography. Users must understand the asymmetry. -- **More complex than RFP-003.** Bond accounting, slash conditions, light-client modules, dispute windows. The protocol surface and audit surface both grow. +- **Does not fix settlement time.** Settlement is still bounded by source-chain + finality plus LEZ finality plus the timelock window. Hours, not minutes. The + bond does not accelerate cryptographic settlement. +- **Does not fix interactivity.** Both parties must be online to lock, reveal, + and (if the other side defaults) submit the slash claim. The bond removes the + incentive to grief but not the requirement to participate. +- **Per-trade matching, no AMM.** No protocol-owned liquidity, no AMM pricing. + Each swap requires a willing counterparty for the exact pair and exact size. + RFP-021 wins decisively on liquidity gravity. +- **Bond opportunity cost.** Makers must lock LEZ-denominated bond capital, + which yields nothing during the lock window. This raises maker spreads + relative to the unbonded (free-option) atomic swap of RFP-003. +- **Bond denomination friction.** First-time takers need LEZ-denominated bond + assets. The bondless-taker capped-entry path mitigates this but only for the + first swap. +- **Tier 2 is structurally weaker.** Alice retains a pre-XMR-lock free option on + the LEZ to XMR pair. Reputation (RFP-023) is the only available restraint on + this option under current Monero cryptography. Users must understand the + asymmetry. +- **More complex than RFP-003.** Bond accounting, slash conditions, light-client + modules, dispute windows. The protocol surface and audit surface both grow. ## Risks -- **Cross-chain bond correlation.** If Bob is matched against N concurrent swaps and the LEZ chain re-orgs or his observer crashes, all N swaps may slash him. Mitigation: per-maker concurrency caps; bond scaling with active-swap count; explicit re-org tolerance windows. -- **Light-client implementation risk (Tier 1).** The BTC and ETH light-client modules are the load-bearing primitive. A bug that lets an attacker submit a false inclusion proof is a direct theft vector. Mitigation: fork from well-audited references (ZeroSync, Citrea Clementine LCP for BTC; Nimbus-derived for ETH); independent audit budget. -- **Bond sizing parameter risk.** Bond too small leaves residual optionality; bond too large prices honest makers out of the market. Volatility regime changes (e.g. XMR price moves of 20% in a session) widen the option value. Mitigation: protocol-adjustable bond parameters; optional volatility-indexed bond sizing. -- **Adversarial bond-bootstrap attack.** An attacker who controls the first set of makers can credibly claim "reputation-rich" status and capture taker flow. Mitigation: combine bond requirements with reputation accrual (RFP-023) so reputation cannot be purchased without time-and-capital cost. -- **FCMP++ upgrade slippage (Tier 2).** If the non-disclosing Monero proof primitive does not ship on the expected horizon, Tier 2 remains permanently asymmetric. Mitigation: design the protocol assuming Tier 2 is the steady state; treat FCMP++ as an optional improvement, not a dependency. -- **First-swap cap evasion.** A taker could split a large trade into many capped first swaps under fresh pseudonyms. Mitigation: cap by IP, device fingerprint (weak), or by Sybil-resistant identity proof (stronger); combine with rate limits enforced at the LEZ escrow program. +- **Cross-chain bond correlation.** If Bob is matched against N concurrent swaps + and the LEZ chain re-orgs or his observer crashes, all N swaps may slash him. + Mitigation: per-maker concurrency caps; bond scaling with active-swap count; + explicit re-org tolerance windows. +- **Light-client implementation risk (Tier 1).** The BTC and ETH light-client + modules are the load-bearing primitive. A bug that lets an attacker submit a + false inclusion proof is a direct theft vector. Mitigation: fork from + well-audited references (ZeroSync, Citrea Clementine LCP for BTC; + Nimbus-derived for ETH); independent audit budget. +- **Bond sizing parameter risk.** Bond too small leaves residual optionality; + bond too large prices honest makers out of the market. Volatility regime + changes (e.g. XMR price moves of 20% in a session) widen the option value. + Mitigation: protocol-adjustable bond parameters; optional volatility-indexed + bond sizing. +- **Adversarial bond-bootstrap attack.** An attacker who controls the first set + of makers can credibly claim "reputation-rich" status and capture taker flow. + Mitigation: combine bond requirements with reputation accrual (RFP-023) so + reputation cannot be purchased without time-and-capital cost. +- **FCMP++ upgrade slippage (Tier 2).** If the non-disclosing Monero proof + primitive does not ship on the expected horizon, Tier 2 remains permanently + asymmetric. Mitigation: design the protocol assuming Tier 2 is the steady + state; treat FCMP++ as an optional improvement, not a dependency. +- **First-swap cap evasion.** A taker could split a large trade into many capped + first swaps under fresh pseudonyms. Mitigation: cap by IP, device fingerprint + (weak), or by Sybil-resistant identity proof (stronger); combine with rate + limits enforced at the LEZ escrow program. ## Relationship to other RFPs in this bundle -- **RFP-003 (Atomic Swaps with LEZ, open)** is the foundation this RFP extends. The per-pair SDKs (LEZ-BTC, LEZ-XMR, LEZ-ETH), the Risc0 LEZ-side escrow, and the custom-LEZ-token support (RFP-003 hard requirement 7) are dependencies. RFP-022 layers bond escrow, slash conditions, and chain-watching light-client modules on top. -- **RFP-021 (cross-chain privacy DEX)** is the federated-custody alternative. RFP-021 sacrifices non-custody for AMM liquidity and one-step UX; RFP-022 sacrifices liquidity gravity for non-custody. The two coexist in a complete cross-chain DEX strategy. -- **RFP-023 (reputation-based atomic swaps)** is the bonding alternative. RFP-022 consumes the maker-reputation primitive from RFP-023; in Tier 2 specifically, the taker-reputation primitive is the only restraint on Alice's residual pre-XMR-lock free option. If RFP-023 ships later, RFP-022 specifies a stub interface and degrades to "count of completed swaps" reputation in the interim. -- **RFP-024 (sXMR pure)** and **RFP-025 (sXMR with SLA)** are orthogonal. They target synthetic XMR exposure inside LEZ DeFi; this RFP targets real-asset atomic swaps. They could be deployed alongside. - -See [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) for the full mitigation-2 design analysis and the impossibility argument for the LEZ to XMR Tier 2 asymmetry. +- **RFP-003 (Atomic Swaps with LEZ, open)** is the foundation this RFP extends. + The per-pair SDKs (LEZ-BTC, LEZ-XMR, LEZ-ETH), the Risc0 LEZ-side escrow, and + the custom-LEZ-token support (RFP-003 hard requirement 7) are dependencies. + RFP-022 layers bond escrow, slash conditions, and chain-watching light-client + modules on top. +- **RFP-021 (cross-chain privacy DEX)** is the federated-custody alternative. + RFP-021 sacrifices non-custody for AMM liquidity and one-step UX; RFP-022 + sacrifices liquidity gravity for non-custody. The two coexist in a complete + cross-chain DEX strategy. +- **RFP-023 (reputation-based atomic swaps)** is the bonding alternative. + RFP-022 consumes the maker-reputation primitive from RFP-023; in Tier 2 + specifically, the taker-reputation primitive is the only restraint on Alice's + residual pre-XMR-lock free option. If RFP-023 ships later, RFP-022 specifies a + stub interface and degrades to "count of completed swaps" reputation in the + interim. +- **RFP-024 (sXMR pure)** and **RFP-025 (sXMR with SLA)** are orthogonal. They + target synthetic XMR exposure inside LEZ DeFi; this RFP targets real-asset + atomic swaps. They could be deployed alongside. + +See [appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) for +the underlying cryptographic mechanics, the free-option framing, and the +`σ × √T × notional` notation. See +[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) +for the federated-signer-vs-atomic-swap trust contrast that motivates this RFP. ## References - [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) -- [eth-lez-atomic-swaps reference implementation](https://github.com/logos-co/eth-lez-atomic-swaps) (accessed 2026-05-21) -- [Bitcoin to Monero atomic swaps (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) (accessed 2026-05-21) -- [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) (accessed 2026-05-21) -- [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332 (2021-01-29)](https://arxiv.org/abs/2101.12332) (accessed 2026-05-21) -- [comit-network/xmr-btc-swap (BTC-XMR adaptor-signature reference implementation; unmaintained since 2024-11)](https://github.com/comit-network/xmr-btc-swap) (accessed 2026-05-21) -- [eigenwallet/core (active fork of comit-network/xmr-btc-swap; v4.6.1, 2026-05-15)](https://github.com/eigenwallet/core) (accessed 2026-05-21) -- [LLFourn one-time-VES: Verifiably Encrypted Signatures (Lloyd Fournier, adaptor signatures)](https://github.com/LLFourn/one-time-VES/blob/master/main.pdf) (accessed 2026-05-21) -- [apoelstra/scriptless-scripts: atomic-swap protocol notes (Andrew Poelstra)](https://github.com/apoelstra/scriptless-scripts/blob/master/md/atomic-swap.md) (accessed 2026-05-21) -- [BIP-340: Schnorr signatures for secp256k1](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) (accessed 2026-05-21) -- [BIP-341: Taproot](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) (accessed 2026-05-21) -- [Citrea Clementine: Trust-Minimized Bitcoin Bridge](https://docs.citrea.xyz/essentials/clementine-trust-minimized-bitcoin-bridge) (accessed 2026-05-21) +- [eth-lez-atomic-swaps reference implementation](https://github.com/logos-co/eth-lez-atomic-swaps) + (accessed 2026-05-21) +- [Bitcoin to Monero atomic swaps (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) + (accessed 2026-05-21) +- [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) + (accessed 2026-05-21) +- [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332 (2021-01-29)](https://arxiv.org/abs/2101.12332) + (accessed 2026-05-21) +- [comit-network/xmr-btc-swap (BTC-XMR adaptor-signature reference implementation; unmaintained since 2024-11)](https://github.com/comit-network/xmr-btc-swap) + (accessed 2026-05-21) +- [eigenwallet/core (active fork of comit-network/xmr-btc-swap; v4.6.1, 2026-05-15)](https://github.com/eigenwallet/core) + (accessed 2026-05-21) +- [LLFourn one-time-VES: Verifiably Encrypted Signatures (Lloyd Fournier, adaptor signatures)](https://github.com/LLFourn/one-time-VES/blob/master/main.pdf) + (accessed 2026-05-21) +- [apoelstra/scriptless-scripts: atomic-swap protocol notes (Andrew Poelstra)](https://github.com/apoelstra/scriptless-scripts/blob/master/md/atomic-swap.md) + (accessed 2026-05-21) +- [BIP-340: Schnorr signatures for secp256k1](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) + (accessed 2026-05-21) +- [BIP-341: Taproot](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) + (accessed 2026-05-21) +- [Citrea Clementine: Trust-Minimized Bitcoin Bridge](https://docs.citrea.xyz/essentials/clementine-trust-minimized-bitcoin-bridge) + (accessed 2026-05-21) - [ZeroSync](https://zerosync.org/) (accessed 2026-05-21) -- [Monero, Zero to Monero 2.0 (whitepaper, §Payment Proofs)](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) (accessed 2026-05-21) -- [Monero, FCMP++ announcement (2024-04-27)](https://www.getmonero.org/2024/04/27/fcmps.html) (accessed 2026-05-21) +- [Monero, Zero to Monero 2.0 (whitepaper, §Payment Proofs)](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) + (accessed 2026-05-21) +- [Monero, FCMP++ announcement (2024-04-27)](https://www.getmonero.org/2024/04/27/fcmps.html) + (accessed 2026-05-21) diff --git a/RFPs/RFP-023-reputation-atomic-swaps.md b/RFPs/RFP-023-reputation-atomic-swaps.md index 4851e9d..3b96b79 100644 --- a/RFPs/RFP-023-reputation-atomic-swaps.md +++ b/RFPs/RFP-023-reputation-atomic-swaps.md @@ -9,28 +9,76 @@ category: Applications & Integrations # RFP-023 — Reputation-Based Atomic Swaps (Bonding Alternative) -> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos team and the community compare cross-chain DEX designs across RFP-021 through RFP-025. Hard requirements, team profile, timeline, and contracting details are deliberately omitted; they will be filled in if the design is selected for funding. +> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos +> team and the community compare cross-chain DEX designs across RFP-021 through +> RFP-025. Hard requirements, team profile, timeline, and contracting details +> are deliberately omitted; they will be filled in if the design is selected for +> funding. ## 🧭 Overview -Extend RFP-003 (Atomic Swaps with LEZ, open) with an on-chain reputation registry that constrains the free-option problem inherent to atomic swaps, *without* requiring bonded collateral as the primary cost-of-defection. - -The premise (a design conjecture to be validated in implementation, not a proven theorem): a maker who has completed N successful swaps with zero defections has built up a reputation asset whose net present value (discounted future fee revenue) plausibly exceeds the expected value of any single grief attack. The protocol does not need to slash bonded collateral; the *market* effectively slashes the maker by refusing future trades. Reputation is therefore a long-tailed bond the protocol does not have to size, hold, or directly enforce. The closest deployed instance is Wormhole's Guardian set (Proof-of-Authority committee), which operates on the same economic argument under a different mechanism. - -The cryptographic challenge is taker reputation. Takers should be unlinkable across swaps (a privacy-positioned cross-chain DEX should not require its users to maintain a persistent on-chain identity that can be deanonymised). The RFP requires applicants to address two complementary design paths: a capped-pseudonym path (linkable, simple) and a zero-knowledge reputation path (unlinkable, complex, reusing the LEZ Risc0 zkVM that RFP-003 already establishes). - -Reputation as a primitive is consumed by other RFPs in the bundle: RFP-022 (bonded atomic swaps) uses maker reputation to compound the cost of defection on top of bonded collateral; RFP-025 (sXMR with SLA, option 2a) uses LP reputation as the attestation layer for default attribution (because "LP defaulted" cannot be rendered from atomic-swap state alone, per the cross-cutting analysis in the trust-model contrast appendix). +Extend RFP-003 (Atomic Swaps with LEZ, open) with an on-chain reputation +registry that constrains the free-option problem inherent to atomic swaps, +*without* requiring bonded collateral as the primary cost-of-defection. + +The premise (a design conjecture to be validated in implementation, not a proven +theorem): a maker who has completed N successful swaps with zero defections has +built up a reputation asset whose net present value (discounted future fee +revenue) plausibly exceeds the expected value of any single grief attack. The +protocol does not need to slash bonded collateral; the *market* effectively +slashes the maker by refusing future trades. Reputation is therefore a +long-tailed bond the protocol does not have to size, hold, or directly enforce. +The closest deployed instance is Wormhole's Guardian set (Proof-of-Authority +committee), which operates on the same economic argument under a different +mechanism. + +The cryptographic challenge is taker reputation. Takers should be unlinkable +across swaps (a privacy-positioned cross-chain DEX should not require its users +to maintain a persistent on-chain identity that can be deanonymised). The RFP +requires applicants to address two complementary design paths: a +capped-pseudonym path (linkable, simple) and a zero-knowledge reputation path +(unlinkable, complex, reusing the LEZ Risc0 zkVM that RFP-003 already +establishes). + +Reputation as a primitive is consumed by other RFPs in the bundle: RFP-022 +(bonded atomic swaps) uses maker reputation to compound the cost of defection on +top of bonded collateral; RFP-025 (sXMR with SLA, option 2a) uses LP reputation +as the attestation layer for default attribution (because "LP defaulted" cannot +be rendered from atomic-swap state alone, per the cross-cutting analysis in the +trust-model contrast appendix). ## Desired properties -- **Maker reputation primitive.** A registry on LEZ that tracks per-maker (count of completed swaps, slash history, time-in-protocol, total fee revenue, optional liveness signals). Public read; write access gated by the LEZ atomic-swap escrow program. -- **Taker reputation primitive with privacy options.** Two paths the RFP requires applicants to consider and ship at least one of: - - **Capped anonymous takers.** First-swap takers are size-capped (worked example: US$100 notional). Cap relaxes after N successful completions under the same persistent pseudonym. Linkability is opt-in: a taker who wants larger size accepts linkability as the cost. - - **Zero-knowledge reputation.** Takers prove "I have completed at least N swaps with zero slashes" without revealing *which* swaps, via a Sparse Merkle Tree of swap outcomes maintained by the LEZ escrow program plus a zk membership proof generated by the taker. Preserves unlinkability across swaps while letting the taker borrow against accumulated reputation. -- **Sybil-resistance by accrual rate.** Reputation accrual is rate-limited by completed-swap throughput and per-pseudonym notional caps, so spinning up fresh identities is bounded by the cost of N honest swaps over the accrual window. -- **No protocol-held bond required for the core design.** The reputation asset is the cost of defection; the protocol does not custody slashable collateral as a precondition of participation. Bonds can be layered on top (per RFP-022) but are not the load-bearing mechanism here. -- **Bootstrap path.** Reputation has zero value at launch. The protocol must specify a bootstrap path: a combination of bondless capped entry (same mechanic as RFP-022's first-swap cap) and RFP-022 bonds for early adopters, transitioning to reputation-only as reputation accrues. -- **Maker exit.** A maker can withdraw from the protocol by transferring their identity (selling the reputation as an asset, if the registry permits) or by abandoning it (accepting reputation loss). Reputation is not refundable. +- **Maker reputation primitive.** A registry on LEZ that tracks per-maker (count + of completed swaps, slash history, time-in-protocol, total fee revenue, + optional liveness signals). Public read; write access gated by the LEZ + atomic-swap escrow program. +- **Taker reputation primitive with privacy options.** Two paths the RFP + requires applicants to consider and ship at least one of: + - **Capped anonymous takers.** First-swap takers are size-capped (worked + example: US$100 notional). Cap relaxes after N successful completions under + the same persistent pseudonym. Linkability is opt-in: a taker who wants + larger size accepts linkability as the cost. + - **Zero-knowledge reputation.** Takers prove "I have completed at least N + swaps with zero slashes" without revealing *which* swaps, via a Sparse + Merkle Tree of swap outcomes maintained by the LEZ escrow program plus a zk + membership proof generated by the taker. Preserves unlinkability across + swaps while letting the taker borrow against accumulated reputation. +- **Sybil-resistance by accrual rate.** Reputation accrual is rate-limited by + completed-swap throughput and per-pseudonym notional caps, so spinning up + fresh identities is bounded by the cost of N honest swaps over the accrual + window. +- **No protocol-held bond required for the core design.** The reputation asset + is the cost of defection; the protocol does not custody slashable collateral + as a precondition of participation. Bonds can be layered on top (per RFP-022) + but are not the load-bearing mechanism here. +- **Bootstrap path.** Reputation has zero value at launch. The protocol must + specify a bootstrap path: a combination of bondless capped entry (same + mechanic as RFP-022's first-swap cap) and RFP-022 bonds for early adopters, + transitioning to reputation-only as reputation accrues. +- **Maker exit.** A maker can withdraw from the protocol by transferring their + identity (selling the reputation as an asset, if the registry permits) or by + abandoning it (accepting reputation loss). Reputation is not refundable. ## High-level functionality and flow @@ -54,7 +102,11 @@ Reputation as a primitive is consumed by other RFPs in the bundle: RFP-022 (bond decide whether to swap ``` -Maker identity is a persistent on-chain pseudonym, publicly readable. Makers want this property: it lets them receive quote requests over Logos Delivery, accumulate fee revenue, amortise gas, and signal trustworthiness. Reputation as a public good for makers maps cleanly to the existing maker daemon shape in RFP-003. +Maker identity is a persistent on-chain pseudonym, publicly readable. Makers +want this property: it lets them receive quote requests over Logos Delivery, +accumulate fee revenue, amortise gas, and signal trustworthiness. Reputation as +a public good for makers maps cleanly to the existing maker daemon shape in +RFP-003. ### Taker reputation: capped-pseudonym path @@ -72,7 +124,9 @@ Maker identity is a persistent on-chain pseudonym, publicly readable. Makers wan - linkability across swaps is intrinsic to using the same Pi ``` -Trade-off: simple to implement and easy for users to reason about. But large-volume takers expose a linkable identity across all their swaps; an adversary who profiles makers can deanonymise large traders' patterns. +Trade-off: simple to implement and easy for users to reason about. But +large-volume takers expose a linkable identity across all their swaps; an +adversary who profiles makers can deanonymise large traders' patterns. ### Taker reputation: zero-knowledge path @@ -93,57 +147,228 @@ Trade-off: simple to implement and easy for users to reason about. But large-vol notional cap tier ``` -Trade-off: preserves unlinkability across swaps (the taker uses a fresh pseudonym per swap, joined only by the zk proof of accumulated reputation). Engineering-expensive: requires a circuit-friendly execution layer on LEZ (the Risc0 zkVM from RFP-003) and careful side-channel analysis. Reuses the same proof infrastructure RFP-021's shielded swap intents and RFP-004's private-account pattern depend on. +Trade-off: preserves unlinkability across swaps (the taker uses a fresh +pseudonym per swap, joined only by the zk proof of accumulated reputation). +Engineering-expensive: requires a circuit-friendly execution layer on LEZ (the +Risc0 zkVM from RFP-003) and careful side-channel analysis. Reuses the same +proof infrastructure RFP-021's shielded swap intents and RFP-004's +private-account pattern depend on. + +### Slashable-event matrix and reputation counter design + +"Zero slashes" as a single counter is too crude in the LEZ↔XMR context (RFP-022 +Tier 2) because Monero's unverifiable lock state means several abandonment paths +are not slashable but are still reputation-relevant. The reputation registry +must distinguish: + +| Event | LEZ-observable? | Slashable? | Reputation counter | +| ----------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------- | +| Successful swap completion | yes (reveal + claim) | n/a | `completed_count` | +| Reveal-failure after counterparty Logos lock (LEZ↔BTC/ETH and Tier 2 post-Logos-lock) | yes | yes (`B_alice` slashes) | `slashed_count` | +| Post-Logos-lock no-claim (locker walks at Phase 5) | partially (Logos-side is on LEZ; external-chain claim is not) | no (capital loss is on the locker) | `no_claim_count` (low signal) | +| XMR-side party never locks XMR after Commit (RFP-022 Tier 2 Phase 2) | **no** | **no** (LEZ can't tell whether locking happened) | `abandoned_pre_xmr_lock_count` (maker-attested via complaint) | +| LEZ-side party never advances despite counterparty XMR lock (RFP-022 Tier 2 Phase 2-3 boundary, attestation flow) | partial (Logos-lock absence is on-LEZ; the trigger event is off-LEZ) | only with an on-LEZ attestation from the locker (see RFP-022 Tier 2 Open question) | `disputed_attestation_count` | + +A taker proving "I have completed at least N swaps with zero slashes" via zk +membership proof must specify *which counters the claim is over*. A meaningful +claim for the LEZ↔XMR pair would be "`completed_count ≥ N` and +`slashed_count = 0` and `abandoned_pre_xmr_lock_count ≤ K`" for tunable +thresholds — not a single zero-slash claim. The SMT keying must support these +per-counter membership / non-membership proofs. + +### Off-chain verifiable maker reputation (LEZ↔XMR open question) + +The non-slashable abandonment path in RFP-022 Tier 2 Phase 2 (the maker walks +after a taker's off-LEZ XMR lock; equivalently the taker walks pre-Phase-3 in +mirrored direction) cannot be priced by a bond, because the trigger event is not +LEZ-observable. The protocol's only response is to record the abandonment as a +reputation event. But the LEZ contract cannot itself verify the event (it cannot +see the XMR side); it depends on the counterparty posting an attestation. + +A natural follow-up: can the attestation be made *verifiable* by third parties +off-chain, rather than relying purely on on-chain claim plus dispute fallback? + +Concretely: could the complainant publish a proof bundle containing (a) the +counterparty's signed quote anchored on LEZ, (b) the Monero transaction(s) +locking the quoted amount to the shared stealth address derived from the quote, +(c) sufficient view-key material for a third party to verify the lock against +the quote, and (d) the absence of the counterparty's Logos lock on LEZ for that +`swap_id` within window — such that any party with both LEZ and Monero +blockchain access can verify the bundle and conclude "this maker received a +valid lock under its quote and did not advance"? + +Open sub-questions for the applicant: + +1. **Privacy cost.** A naive proof bundle leaks the shared view key, which + deanonymises the swap output to any holder of the bundle. Can the disclosure + be narrowed (a non-interactive zk proof over the Monero output structure that + proves "an output of the quoted amount exists at the stealth address matching + the quote" without exposing the view key)? FCMP++ may help; current Monero + proof primitives (`check_tx_proof`, OutProofV2/InProofV2) do not. +2. **Distribution.** Where does the complainant publish the bundle? LEZ + calldata? IPFS with a hash on LEZ? Logos Delivery? Each has different + censorship-resistance and durability tradeoffs. +3. **Aggregation.** Does the reputation system aggregate complaints across + complainants, weighting by complainant reputation, to produce a score? Or + does each maker carry an unaggregated list of verifiable complaints that + takers inspect directly? +4. **Spam resistance.** A malicious complainant could fabricate quote-shaped + artifacts and pair them with unrelated Monero outputs. The bundle must bind + the Monero output to *this specific swap's* stealth-address derivation in a + way the verifier can re-check from the joint-key transcript without trusting + the complainant. +5. **Defense.** Can the accused party rebut a false complaint with a proof of + its own (e.g. that the claimed Monero output is not the one corresponding to + the swap's stealth-address derivation, or that its on-LEZ behaviour did in + fact match)? +6. **Threshold for "valid complaint".** Off-chain reputation requires a + third-party verifier to make a judgement; the protocol itself does not + decide. Applicants should be honest that this is a social-layer construct + *enabled by* but not enforced by the protocol. + +The protocol can support such a reputation layer cheaply by ensuring (a) quote +signatures are anchored on LEZ with deterministic stealth-address derivation, +and (b) the joint-key transcript is preserved long enough that the bundle can +re-derive the stealth address from public components. Whether to design the +verifiable-complaint layer itself, or expose only the primitives that make it +possible, is part of this RFP's output. ### Reputation primitive consumed by other RFPs -- **RFP-022** consumes the maker reputation primitive to compound cost of defection above the bond. In Tier 2 (LEZ to XMR) specifically, the taker reputation primitive is the only restraint on Alice's pre-XMR-lock free option (because her XMR lock cannot be proven on LEZ). -- **RFP-025** option 2a (bonded LP set) consumes LP reputation as the default-attribution layer, because "LP defaulted" is not a verdict an on-chain program can render from atomic-swap state alone (per the cross-cutting analysis in [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md)). +- **RFP-022** consumes the maker reputation primitive to compound cost of + defection above the bond. In Tier 2 (LEZ to XMR) specifically, the taker + reputation primitive is the only restraint on Alice's pre-XMR-lock free option + (because her XMR lock cannot be proven on LEZ). The off-chain verifiable + complaint mechanism described above is the specific mechanism RFP-022 calls + out for that gap. +- **RFP-025** option 2a (bonded LP set) consumes LP reputation as the + default-attribution layer, because "LP defaulted" is not a verdict an on-chain + program can render from atomic-swap state alone (per the cross-cutting + analysis in + [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md)). ## Pros -- **No protocol-held bond required for the core mechanic.** Capital efficiency is highest among the free-option mitigations: no LEZ-denominated bond locks up maker capital during swap windows. -- **Scales with maker career.** Reputation accrues over many swaps; a maker who has completed 10,000 swaps has a far larger implicit bond than any reasonable explicit bond size. The mechanism strengthens as the protocol matures. -- **Closer to the cypherpunk "no third-party trust" ideal than RFP-022.** No bond escrow contract holds funds; no LEZ-side slashing logic enforces collateral forfeit. The only on-chain artefact is the reputation registry, which records outcomes but does not custody assets. -- **Composable with bond designs.** RFP-022 can layer reputation on top of bonds for compounded defection cost. The two are not exclusive. -- **Unlinkable taker reputation is genuinely novel.** The zk membership proof path, if shipped, is one of the first deployable instances of "I have reputation but you cannot tell which swaps built it". The privacy positioning of Logos benefits directly. -- **Solves the LEZ to XMR Tier 2 gap (with RFP-022).** Where RFP-022 alone leaves Alice with a pre-XMR-lock free option, RFP-023 taker reputation constrains it by making defection cost reputation rather than collateral. +- **No protocol-held bond required for the core mechanic.** Capital efficiency + is highest among the free-option mitigations: no LEZ-denominated bond locks up + maker capital during swap windows. +- **Scales with maker career.** Reputation accrues over many swaps; a maker who + has completed 10,000 swaps has a far larger implicit bond than any reasonable + explicit bond size. The mechanism strengthens as the protocol matures. +- **Closer to the cypherpunk "no third-party trust" ideal than RFP-022.** No + bond escrow contract holds funds; no LEZ-side slashing logic enforces + collateral forfeit. The only on-chain artefact is the reputation registry, + which records outcomes but does not custody assets. +- **Composable with bond designs.** RFP-022 can layer reputation on top of bonds + for compounded defection cost. The two are not exclusive. +- **Unlinkable taker reputation is genuinely novel.** The zk membership proof + path, if shipped, is one of the first deployable instances of "I have + reputation but you cannot tell which swaps built it". The privacy positioning + of Logos benefits directly. +- **Solves the LEZ to XMR Tier 2 gap (with RFP-022).** Where RFP-022 alone + leaves Alice with a pre-XMR-lock free option, RFP-023 taker reputation + constrains it by making defection cost reputation rather than collateral. ## Cons -- **Bootstrap problem is real.** At launch, reputation has zero value, so the first cohort of swaps has the strongest free-option exposure. The protocol must combine reputation with bondless caps (this RFP) plus optional RFP-022 bonds for the bootstrap phase. The early protocol experience is worse than the steady-state. -- **Zero-knowledge path is engineering-expensive.** Circuit design, side-channel analysis, audit, and ongoing performance work. The capped-pseudonym path is simpler but exposes linkability. -- **Sybil mitigation requires careful parametrisation.** If the per-pseudonym accrual rate is too generous, attackers can mint reputation cheaply. If too restrictive, honest takers cannot accumulate reputation fast enough to access the trade sizes they need. -- **Maker reputation does not protect against first-time defection.** A new maker with zero reputation can grief and walk away at no reputation cost. The first swap any taker does with any new maker is unprotected. Mitigation: combine with RFP-022 bonds during the maker's reputation-building phase. -- **Reputation transfer mechanics are governance-sensitive.** If reputation is transferable (a maker can sell their identity), an attacker can purchase a high-reputation identity and grief immediately. If non-transferable, maker exit is painful (no salvage value). Both directions require careful policy. -- **Maker reputation is publicly linkable, by design.** This is the right trade-off for the maker role (they want a persistent identity) but it must be documented honestly: makers are deanonymised by the protocol. +- **Bootstrap problem is real.** At launch, reputation has zero value, so the + first cohort of swaps has the strongest free-option exposure. The protocol + must combine reputation with bondless caps (this RFP) plus optional RFP-022 + bonds for the bootstrap phase. The early protocol experience is worse than the + steady-state. +- **Zero-knowledge path is engineering-expensive.** Circuit design, side-channel + analysis, audit, and ongoing performance work. The capped-pseudonym path is + simpler but exposes linkability. +- **Sybil mitigation requires careful parametrisation.** If the per-pseudonym + accrual rate is too generous, attackers can mint reputation cheaply. If too + restrictive, honest takers cannot accumulate reputation fast enough to access + the trade sizes they need. +- **Maker reputation does not protect against first-time defection.** A new + maker with zero reputation can grief and walk away at no reputation cost. The + first swap any taker does with any new maker is unprotected. Mitigation: + combine with RFP-022 bonds during the maker's reputation-building phase. +- **Reputation transfer mechanics are governance-sensitive.** If reputation is + transferable (a maker can sell their identity), an attacker can purchase a + high-reputation identity and grief immediately. If non-transferable, maker + exit is painful (no salvage value). Both directions require careful policy. +- **Maker reputation is publicly linkable, by design.** This is the right + trade-off for the maker role (they want a persistent identity) but it must be + documented honestly: makers are deanonymised by the protocol. ## Risks -- **Sybil attacks at scale.** Cheap to mint new pseudonyms; defection from a low-reputation identity is consequence-free. Mitigation: reputation accrual rate-limited by completed-swap throughput and notional caps; cost of building reputation equals the cost of N honest swaps plus the bond-equivalent capital tied up over the accrual window. -- **Sidechannel deanonymisation of zk-reputation takers.** Even unlinkable proofs leak via timing, notional distribution, maker-side counterparty profiling, and (if poorly implemented) proof-construction telemetry. The privacy claim is "unlinkable across the public ledger", not "unlinkable to a maker who actively profiles its counterparties". This distinction must be documented for users. -- **Reputation-purchase attack.** An attacker buys a high-reputation maker identity (if transferable) and grief-attacks. Mitigation: non-transferable reputation, or transfer with a notice period and a "decayed-reputation" cooling window. -- **Bootstrap free-option exposure.** Until reputation accumulates, the protocol depends on RFP-022 bonds for first-cohort security. If RFP-022 ships later than RFP-023, the bootstrap window is unprotected. Mitigation: ship together, or include a stub bond mechanism in RFP-023 itself. -- **zkVM proof cost regression.** If proof generation cost regresses (e.g. due to LEZ zkVM upgrade), zk-reputation takers face a sudden cost increase. Mitigation: proof-cost monitoring; protocol-adjustable proof-generation parameters. -- **Privacy-positioning narrative risk.** "Reputation" reads to some users as the opposite of "privacy". The communication challenge is real: explaining that the protocol records *outcomes* (which can be private under zk proofs) without recording *identities* (which it explicitly does not). Documentation budget required. -- **Governance attack on the registry.** If the reputation registry is upgradeable, an attacker who captures the upgrade key can wipe reputation or insert false reputation. Mitigation: immutable registry contract, with explicit migration path if upgrade is ever required. +- **Sybil attacks at scale.** Cheap to mint new pseudonyms; defection from a + low-reputation identity is consequence-free. Mitigation: reputation accrual + rate-limited by completed-swap throughput and notional caps; cost of building + reputation equals the cost of N honest swaps plus the bond-equivalent capital + tied up over the accrual window. +- **Sidechannel deanonymisation of zk-reputation takers.** Even unlinkable + proofs leak via timing, notional distribution, maker-side counterparty + profiling, and (if poorly implemented) proof-construction telemetry. The + privacy claim is "unlinkable across the public ledger", not "unlinkable to a + maker who actively profiles its counterparties". This distinction must be + documented for users. +- **Reputation-purchase attack.** An attacker buys a high-reputation maker + identity (if transferable) and grief-attacks. Mitigation: non-transferable + reputation, or transfer with a notice period and a "decayed-reputation" + cooling window. +- **Bootstrap free-option exposure.** Until reputation accumulates, the protocol + depends on RFP-022 bonds for first-cohort security. If RFP-022 ships later + than RFP-023, the bootstrap window is unprotected. Mitigation: ship together, + or include a stub bond mechanism in RFP-023 itself. +- **zkVM proof cost regression.** If proof generation cost regresses (e.g. due + to LEZ zkVM upgrade), zk-reputation takers face a sudden cost increase. + Mitigation: proof-cost monitoring; protocol-adjustable proof-generation + parameters. +- **Privacy-positioning narrative risk.** "Reputation" reads to some users as + the opposite of "privacy". The communication challenge is real: explaining + that the protocol records *outcomes* (which can be private under zk proofs) + without recording *identities* (which it explicitly does not). Documentation + budget required. +- **Governance attack on the registry.** If the reputation registry is + upgradeable, an attacker who captures the upgrade key can wipe reputation or + insert false reputation. Mitigation: immutable registry contract, with + explicit migration path if upgrade is ever required. ## Relationship to other RFPs in this bundle -- **RFP-003 (Atomic Swaps with LEZ, open)** is the foundation. The per-pair SDKs, Risc0 escrow programs, and Logos Delivery / Logos Chat coordination are dependencies. RFP-023 layers the reputation registry and (in the zk path) the SMT-of-outcomes infrastructure on top. -- **RFP-022 (bonded atomic swaps)** consumes the maker reputation primitive defined here. In Tier 2 (LEZ to XMR), taker reputation is the only restraint on Alice's residual pre-XMR-lock free option. RFP-022 and RFP-023 can be implemented as a single workstream or sequenced (RFP-023 first to provide the primitive, then RFP-022 consumes it). -- **RFP-021 (cross-chain privacy DEX)** is the federated-custody alternative. Orthogonal: RFP-021 sacrifices non-custody for AMM-style liquidity; RFP-023 sacrifices throughput for reputation-as-bond non-custody. -- **RFP-025 (sXMR with SLA, option 2a)** consumes LP reputation as the default-attribution layer for slashing, because "LP defaulted" cannot be rendered from atomic-swap state alone. RFP-023 is a prerequisite for the credible deployment of RFP-025 option 2a. -- **RFP-024 (sXMR pure)** does not require reputation (the pure design has no SLA to enforce), but could optionally consume maker reputation for the LP-discovery UX. -- **RFP-004 (Privacy-Preserving DEX, open)** does not have a reputation primitive; RFP-023's reputation registry is a distinct artefact and does not collide. - -See [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) for the full reputation-as-bond analysis (mitigation 3) and the taker-privacy-tension discussion. +- **RFP-003 (Atomic Swaps with LEZ, open)** is the foundation. The per-pair + SDKs, Risc0 escrow programs, and Logos Delivery / Logos Chat coordination are + dependencies. RFP-023 layers the reputation registry and (in the zk path) the + SMT-of-outcomes infrastructure on top. +- **RFP-022 (bonded atomic swaps)** consumes the maker reputation primitive + defined here. In Tier 2 (LEZ to XMR), taker reputation is the only restraint + on Alice's residual pre-XMR-lock free option. RFP-022 and RFP-023 can be + implemented as a single workstream or sequenced (RFP-023 first to provide the + primitive, then RFP-022 consumes it). +- **RFP-021 (cross-chain privacy DEX)** is the federated-custody alternative. + Orthogonal: RFP-021 sacrifices non-custody for AMM-style liquidity; RFP-023 + sacrifices throughput for reputation-as-bond non-custody. +- **RFP-025 (sXMR with SLA, option 2a)** consumes LP reputation as the + default-attribution layer for slashing, because "LP defaulted" cannot be + rendered from atomic-swap state alone. RFP-023 is a prerequisite for the + credible deployment of RFP-025 option 2a. +- **RFP-024 (sXMR pure)** does not require reputation (the pure design has no + SLA to enforce), but could optionally consume maker reputation for the + LP-discovery UX. +- **RFP-004 (Privacy-Preserving DEX, open)** does not have a reputation + primitive; RFP-023's reputation registry is a distinct artefact and does not + collide. + +See +[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) +for the full reputation-as-bond analysis (mitigation 3) and the +taker-privacy-tension discussion. ## References - [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) -- [Wormhole Guardian set (reputation-substituting-for-bond under Proof-of-Authority)](https://wormhole.com/docs/protocol/infrastructure/guardians/) (accessed 2026-05-21) -- [Wormhole 101: Guardians (supporting context)](https://wormhole.com/blog/wormhole-101-guardians) (accessed 2026-05-21) -- [Sparse Merkle Tree (Vitalik Buterin, "Optimizing sparse Merkle trees", ethresear.ch, 2018-10-09)](https://ethresear.ch/t/optimizing-sparse-merkle-trees/3751) (accessed 2026-05-21) +- [Wormhole Guardian set (reputation-substituting-for-bond under Proof-of-Authority)](https://wormhole.com/docs/protocol/infrastructure/guardians/) + (accessed 2026-05-21) +- [Wormhole 101: Guardians (supporting context)](https://wormhole.com/blog/wormhole-101-guardians) + (accessed 2026-05-21) +- [Sparse Merkle Tree (Vitalik Buterin, "Optimizing sparse Merkle trees", ethresear.ch, 2018-10-09)](https://ethresear.ch/t/optimizing-sparse-merkle-trees/3751) + (accessed 2026-05-21) - [Risc0 zkVM](https://dev.risczero.com/) (accessed 2026-05-21) -- [Logos Delivery and Logos Chat (referenced from RFP-003)](https://github.com/logos-co/logos-docs) (accessed 2026-05-21) +- [Logos Delivery and Logos Chat (referenced from RFP-003)](https://github.com/logos-co/logos-docs) + (accessed 2026-05-21) diff --git a/RFPs/RFP-024-synthetic-xmr-pure.md b/RFPs/RFP-024-synthetic-xmr-pure.md index 01ebcd0..a5733ee 100644 --- a/RFPs/RFP-024-synthetic-xmr-pure.md +++ b/RFPs/RFP-024-synthetic-xmr-pure.md @@ -9,26 +9,68 @@ category: Applications & Integrations # RFP-024 — Synthetic XMR (sXMR), Pure Non-Custodial Design -> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos team and the community compare cross-chain DEX designs across RFP-021 through RFP-025. Hard requirements, team profile, timeline, and contracting details are deliberately omitted; they will be filled in if the design is selected for funding. +> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos +> team and the community compare cross-chain DEX designs across RFP-021 through +> RFP-025. Hard requirements, team profile, timeline, and contracting details +> are deliberately omitted; they will be filled in if the design is selected for +> funding. ## 🧭 Overview -Build a synthetic XMR token (sXMR) on LEZ that tracks the XMR price via oracle, is composable across LEZ DeFi, and redeems to real XMR via peer-to-peer atomic swap. The protocol holds no XMR, runs no signer set, and offers no redemption SLA. +Build a synthetic XMR token (sXMR) on LEZ that tracks the XMR price via oracle, +is composable across LEZ DeFi, and redeems to real XMR via peer-to-peer atomic +swap. The protocol holds no XMR, runs no signer set, and offers no redemption +SLA. -The wedge: this is the only currently published, live synthetic whose redemption deposits real XMR on Monero L1 *non-custodially, via peer-to-peer atomic swap*. sBTC (Stacks) redeems to a user-supplied public Bitcoin address (per [docs.stacks.co: sBTC-to-BTC withdrawal](https://docs.stacks.co/more-guides/sbtc/bridging-bitcoin/sbtc-to-btc), accessed 2026-05-21); every other commodity synthetic (sETH, sLINK, perpetuals-collateralised positions) redeems to traceable transparent assets. The closest prior art is custodial: Synthetix's historical sXMR token paired with the Secret Network Monero Bridge offered XMR-L1 redemption under signer-set custody (the same trust model RFP-025 option 2b accepts); Haven Protocol's xAsset family offered synthetics on a dedicated privacy chain but closed in December 2024 and never offered xXMR. RFP-024 is the first design where the redemption path itself preserves privacy *and* avoids custody. +The wedge: no published, live synthetic redeems to real XMR on Monero L1 +*non-custodially, via peer-to-peer atomic swap*. The closest deployed prior art +is **custodial**: Secret Network's Secret Monero Bridge (live since August 2021) +ran sXMR as a SNIP-20 token bridged via a multi-signature Monero wallet operated +by consensus-node operators; the trust shape is a signer set, not peer-to-peer +atomicity. Other commodity-tracking synthetics (sBTC on Stacks, sETH-style +synths) redeem to transparent assets, leaving the destination on a public +ledger. The Haven Protocol xAsset family (xUSD and other privacy-preserving +xAssets) runs on a Monero-forked L1 but does not include an xXMR product; its +design is over-collateralised synthetics minted against XHV, not peer-to-peer +atomic-swap redemption. -The honest framing: this is a synthetic with a soft, market-clearing peg, not a hard-redeemable synthetic. The oracle is the *quoted* price; the *achievable* price is whatever an XMR LP will swap for, when one is willing. Structurally closer to a DEX trading pair than to sBTC (Stacks). The product fits a privacy-maximalist audience that wants XMR-shaped exposure inside LEZ DeFi without depending on protocol-held custody. +This RFP positions itself as the first design where the redemption path itself +is both privacy-preserving (deposits real XMR on Monero L1) and non-custodial +(atomic-swap rather than signer-set bridge). See +[appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) +for the deployed-synthetics survey including the Secret Monero Bridge negative +case, and +[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) +for the federated-signer-vs-atomic-swap trust contrast. + +The honest framing: this is a synthetic with a soft, market-clearing peg, not a +hard-redeemable synthetic. The oracle is the *quoted* price; the *achievable* +price is whatever an XMR LP will swap for, when one is willing. Structurally +closer to a DEX trading pair than to sBTC (Stacks). The product fits a +privacy-maximalist audience that wants XMR-shaped exposure inside LEZ DeFi +without depending on protocol-held custody. ## Desired properties - **Non-custodial.** No vault holds XMR. No signer set. No bridge. -- **Soft peg.** The oracle is a reference price; the achievable redemption price is whatever an LP quotes. Spread widens under stress without bound. -- **No redemption guarantee.** A counterparty may not exist when the user wants to exit. The protocol does not commit to availability. -- **Composable on LEZ.** sXMR is a vanilla LEZ token (the LEZ token program standard from RFP-003 hard requirement 7), callable by any other LEZ program: lending markets, DEXes, governance, structured products. -- **Private exit.** Successful redemption deposits real XMR on Monero L1, severing the public trail. The XMR side never touches LEZ. -- **Open LP set.** Anyone with XMR can quote. No permission required; no LP registry; no bond. -- **Regulatory minimalism.** The protocol does not handle XMR; it is, in defensible terms, a price feed plus a matching board for users to find each other. -- **Off-chain orderbook.** Quotes and intents flow over Logos Delivery (the same coordination primitive RFP-003 uses for maker advertisement). The on-chain artefact is the atomic-swap settlement program; the matching itself is bilateral and off-chain. +- **Soft peg.** The oracle is a reference price; the achievable redemption price + is whatever an LP quotes. Spread widens under stress without bound. +- **No redemption guarantee.** A counterparty may not exist when the user wants + to exit. The protocol does not commit to availability. +- **Composable on LEZ.** sXMR is a vanilla LEZ token (the LEZ token program + standard from RFP-003 hard requirement 7), callable by any other LEZ program: + lending markets, DEXes, governance, structured products. +- **Private exit.** Successful redemption deposits real XMR on Monero L1, + severing the public trail. The XMR side never touches LEZ. +- **Open LP set.** Anyone with XMR can quote. No permission required; no LP + registry; no bond. +- **Regulatory minimalism.** The protocol does not handle XMR; it is, in + defensible terms, a price feed plus a matching board for users to find each + other. +- **Off-chain orderbook.** Quotes and intents flow over Logos Delivery (the same + coordination primitive RFP-003 uses for maker advertisement). The on-chain + artefact is the atomic-swap settlement program; the matching itself is + bilateral and off-chain. ## High-level functionality and flow @@ -52,70 +94,168 @@ The honest framing: this is a synthetic with a soft, market-clearing peg, not a ### Mint -A user deposits a stable (or other LEZ-accepted asset) into the sXMR collateral vault on LEZ; the protocol mints sXMR to the user at the current oracle price (with a configurable mint fee). The vault holds the collateral; sXMR circulates freely. +A user deposits a stable (or other LEZ-accepted asset) into the sXMR collateral +vault on LEZ; the protocol mints sXMR to the user at the current oracle price +(with a configurable mint fee). The vault holds the collateral; sXMR circulates +freely. ### Redemption (the privacy-preserving exit) 1. Alice (sXMR holder) signals intent to redeem over Logos Delivery. -2. Bob (open-set XMR LP) sees the intent, computes his quote (oracle price plus his spread), and replies bilaterally. -3. Alice accepts; Alice and Bob execute an atomic swap using the RFP-003 LEZ-XMR SDK. Alice's sXMR is burned on LEZ; Bob's XMR arrives on Monero at an address Alice controls. The matching, the quote, and the bilateral acknowledgement happen off-chain over Logos Delivery and Logos Chat. -4. Bob's swapped sXMR is burned by Bob; the released stable collateral becomes Bob's payout (less any protocol fee). +2. Bob (open-set XMR LP) sees the intent, computes his quote (oracle price plus + his spread), and replies bilaterally. +3. Alice accepts; Alice and Bob execute an atomic swap using the RFP-003 LEZ-XMR + SDK. Alice's sXMR is burned on LEZ; Bob's XMR arrives on Monero at an address + Alice controls. The matching, the quote, and the bilateral acknowledgement + happen off-chain over Logos Delivery and Logos Chat. +4. Bob's swapped sXMR is burned by Bob; the released stable collateral becomes + Bob's payout (less any protocol fee). ### Failure modes (no protocol enforcement) -- If Bob walks away mid-swap, the atomic-swap timelock returns Alice's sXMR; she retains her position. -- If no Bob exists, Alice's sXMR trades at a discount to oracle until a Bob shows up or Alice gives up. There is no protocol-side compensation for redemption delay. +- If Bob walks away mid-swap, the atomic-swap timelock returns Alice's sXMR; she + retains her position. +- If no Bob exists, Alice's sXMR trades at a discount to oracle until a Bob + shows up or Alice gives up. There is no protocol-side compensation for + redemption delay. ## Pros -- **Cleanest privacy story in the bundle.** Successful redemption ends with real XMR on Monero L1. No protocol-side custody, no signer-set deposit-history leak (the RFP-021 and RFP-025 option 2b weakness), no view-key disclosure (the RFP-022 Tier 2 constraint). -- **Cryptographic non-custody is full.** No vault, no bond, no SLA. The trust assumption is the oracle (for pricing) and the soundness of the RFP-003 atomic-swap protocol. The protocol cannot lose user funds in a custody breach because it does not have custody. -- **Composable from day one.** sXMR is a vanilla LEZ token; lending markets and DEXes can integrate without coordinating with the sXMR team. The product surface scales with the rest of LEZ DeFi. -- **Regulatory defensibility is highest.** The protocol does not handle XMR. Operators of price feeds and matching boards have meaningfully different exposure from operators of XMR-custodying bridges. -- **Lowest engineering cost in the bundle's synthetics line.** No SLA enforcement; no LP registry; no slashing logic; no signer-set custody. The core deliverable is a token, a collateral vault, an oracle integration, and an intent layer over Logos Delivery. -- **Open LP set is censorship-resistant.** No permissioned set; no KYC; no operator that can be coerced into refusing service. +- **Cleanest privacy story in the bundle.** Successful redemption ends with real + XMR on Monero L1. No protocol-side custody, no signer-set deposit-history leak + (the RFP-021 and RFP-025 option 2b weakness), no view-key disclosure (the + RFP-022 Tier 2 constraint). +- **Cryptographic non-custody is full.** No vault, no bond, no SLA. The trust + assumption is the oracle (for pricing) and the soundness of the RFP-003 + atomic-swap protocol. The protocol cannot lose user funds in a custody breach + because it does not have custody. +- **Composable from day one.** sXMR is a vanilla LEZ token; lending markets and + DEXes can integrate without coordinating with the sXMR team. The product + surface scales with the rest of LEZ DeFi. +- **Regulatory defensibility is highest.** The protocol does not handle XMR. + Operators of price feeds and matching boards have meaningfully different + exposure from operators of XMR-custodying bridges. +- **Lowest engineering cost in the bundle's synthetics line.** No SLA + enforcement; no LP registry; no slashing logic; no signer-set custody. The + core deliverable is a token, a collateral vault, an oracle integration, and an + intent layer over Logos Delivery. +- **Open LP set is censorship-resistant.** No permissioned set; no KYC; no + operator that can be coerced into refusing service. ## Cons -- **Soft peg widens under stress without bound.** The achievable redemption price is the marginal LP quote. If LPs vanish, sXMR can trade at any discount to oracle; the protocol cannot intervene. -- **No redemption SLA.** Users who want guaranteed redemption (institutions, market makers, structured products) cannot use sXMR directly under Goal 1; they need RFP-025. -- **Predicted demand asymmetry.** Mint demand is expected to be easy (privacy-curious DeFi users want XMR exposure inside LEZ); LP supply is expected to be harder to source (XMR maximalists may not want a public LP role at all, even pseudonymous). The LP side is the predicted structural bottleneck; applicants should validate against early LP onboarding before scaling. -- **Predicted adverse selection of LPs.** LPs are expected to show up when oracle is below true market XMR price (free money for them on the redemption leg) and to vanish when oracle is above (would-be loss). Redemption availability is expected to be asymmetric across regimes; analogous to uncollateralised peer-to-peer market-making in other venues but unverified for this product. -- **Atomic-swap UX inherited.** Settlement time is dominated by Monero block confirmations, typically under an hour but with variance from network conditions; both parties online for the duration. The intent layer over Logos Delivery softens this but cannot remove it. -- **No protocol-side enforcement of LP behaviour.** Refusing to proceed is *valid behaviour* under the atomic-swap protocol; the protocol cannot distinguish malicious refusal from connectivity loss. Reputation (RFP-023) is the only available restraint, and even then it operates as soft pressure, not enforcement. -- **Oracle dependency.** The oracle is the only price signal; oracle attack or stale price degrades minting accuracy. Mitigation lives outside this RFP (existing oracle RFPs in the bundle, or oracle aggregation patterns). +- **Soft peg widens under stress without bound.** The achievable redemption + price is the marginal LP quote. If LPs vanish, sXMR can trade at any discount + to oracle; the protocol cannot intervene. +- **No redemption SLA.** Users who want guaranteed redemption (institutions, + market makers, structured products) cannot use sXMR directly under Goal 1; + they need RFP-025. +- **Predicted demand asymmetry.** Mint demand is expected to be easy + (privacy-curious DeFi users want XMR exposure inside LEZ); LP supply is + expected to be harder to source (XMR maximalists may not want a public LP role + at all, even pseudonymous). The LP side is the predicted structural + bottleneck; applicants should validate against early LP onboarding before + scaling. +- **Predicted adverse selection of LPs.** LPs are expected to show up when + oracle is below true market XMR price (free money for them on the redemption + leg) and to vanish when oracle is above (would-be loss). Redemption + availability is expected to be asymmetric across regimes; analogous to + uncollateralised peer-to-peer market-making in other venues but unverified for + this product. +- **Atomic-swap UX inherited.** Settlement time is dominated by Monero block + confirmations, typically under an hour but with variance from network + conditions; both parties online for the duration. The intent layer over Logos + Delivery softens this but cannot remove it. +- **No protocol-side enforcement of LP behaviour.** Refusing to proceed is + *valid behaviour* under the atomic-swap protocol; the protocol cannot + distinguish malicious refusal from connectivity loss. Reputation (RFP-023) is + the only available restraint, and even then it operates as soft pressure, not + enforcement. +- **Oracle dependency.** The oracle is the only price signal; oracle attack or + stale price degrades minting accuracy. Mitigation lives outside this RFP + (existing oracle RFPs in the bundle, or oracle aggregation patterns). ## Risks -- **LP exodus.** All XMR holders stop quoting. sXMR trades at an indefinite discount to oracle until LPs return. Mitigation: design the protocol to survive long discount regimes without auto-liquidation; let the discount be the market signal that restores LP supply. -- **Oracle manipulation.** A manipulated XMR/USD oracle lets an attacker mint sXMR cheaply or under-collateralise existing positions. Mitigation: use a redundant oracle stack with median-of-N pricing; impose configurable price-deviation guards on minting. -- **Collateral solvency.** If the collateral asset (stables or otherwise) is itself compromised (depeg, exploit, regulatory freeze), sXMR backing degrades. Mitigation: accept only collateral with documented threat models; cap protocol-wide collateral concentration by asset. -- **Privacy-claim overreach.** sXMR itself is *not* a private asset on LEZ (the token program is public state). The privacy property applies *only* to the redemption-to-XMR path. If users mint sXMR from a public LEZ account and never redeem, no privacy is conferred. The communication challenge is non-trivial; documentation must be honest. -- **Regulatory inflection on Monero.** If a jurisdiction outlaws Monero entirely, the redemption path becomes legally fraught for LPs in that jurisdiction. The protocol itself is insulated (it does not handle XMR) but the LP economy may concentrate in friendlier jurisdictions. Strategic, not technical. -- **Atomic-swap maker burnout.** The free-option problem RFP-022 addresses applies here too: LPs can be free-optioned by takers. Without bonds (Goal 1's premise), this can drive LPs away. Mitigation: optional layered consumption of RFP-022 Tier 2 (bonded XMR atomic swaps) or RFP-023 (reputation) for the redemption leg, as separate products on top of the same sXMR token. -- **No protocol-side fee revenue capture.** Open LP set means LPs capture the spread; the protocol's only revenue is mint and burn fees on sXMR itself. Sustainability depends on mint/burn volume, which depends on LEZ DeFi composability adoption. +- **LP exodus.** All XMR holders stop quoting. sXMR trades at an indefinite + discount to oracle until LPs return. Mitigation: design the protocol to + survive long discount regimes without auto-liquidation; let the discount be + the market signal that restores LP supply. +- **Oracle manipulation.** A manipulated XMR/USD oracle lets an attacker mint + sXMR cheaply or under-collateralise existing positions. Mitigation: use a + redundant oracle stack with median-of-N pricing; impose configurable + price-deviation guards on minting. +- **Collateral solvency.** If the collateral asset (stables or otherwise) is + itself compromised (depeg, exploit, regulatory freeze), sXMR backing degrades. + Mitigation: accept only collateral with documented threat models; cap + protocol-wide collateral concentration by asset. +- **Privacy-claim overreach.** sXMR itself is *not* a private asset on LEZ (the + token program is public state). The privacy property applies *only* to the + redemption-to-XMR path. If users mint sXMR from a public LEZ account and never + redeem, no privacy is conferred. The communication challenge is non-trivial; + documentation must be honest. +- **Regulatory inflection on Monero.** If a jurisdiction outlaws Monero + entirely, the redemption path becomes legally fraught for LPs in that + jurisdiction. The protocol itself is insulated (it does not handle XMR) but + the LP economy may concentrate in friendlier jurisdictions. Strategic, not + technical. +- **Atomic-swap maker burnout.** The free-option problem RFP-022 addresses + applies here too: LPs can be free-optioned by takers. Without bonds (Goal 1's + premise), this can drive LPs away. Mitigation: optional layered consumption of + RFP-022 Tier 2 (bonded XMR atomic swaps) or RFP-023 (reputation) for the + redemption leg, as separate products on top of the same sXMR token. +- **No protocol-side fee revenue capture.** Open LP set means LPs capture the + spread; the protocol's only revenue is mint and burn fees on sXMR itself. + Sustainability depends on mint/burn volume, which depends on LEZ DeFi + composability adoption. ## Relationship to other RFPs in this bundle -- **RFP-003 (Atomic Swaps with LEZ, open)** is the foundation: the LEZ-XMR atomic-swap SDK is the redemption settlement layer. RFP-024 does not modify RFP-003; it builds the sXMR product on top of it. -- **RFP-025 (sXMR with SLA)** is the complementary design. RFP-024 targets the privacy-maximalist audience accepting market-clearing redemption; RFP-025 targets the SLA-needing audience accepting custody risk. The two together cover the synthetics design space. A reader should pick one or both based on which user segment they want to serve. -- **RFP-022 (bonded atomic swaps)** could optionally be consumed by RFP-024 as the redemption-leg primitive: instead of bare atomic swaps, redemption uses bonded atomic swaps. This compounds LP commitment but adds bond friction on the LP side. The pure design in this RFP does not require this layering. -- **RFP-023 (reputation-based atomic swaps)** could optionally be consumed for LP-discovery UX (takers see LP reputation before initiating). Not strictly required for the core product. -- **RFP-021 (cross-chain privacy DEX)** is orthogonal. RFP-021 offers real-XMR cross-chain swaps with federated custody; RFP-024 offers synthetic-XMR exposure with atomic-swap redemption. Different products; same broad audience can use both. -- **RFP-004 (Privacy-Preserving DEX, open)** is the natural single-chain trading venue for sXMR once minted. Trade sXMR against stables on RFP-004's AMM pools under the deshield-swap-reshield pattern; redeem to real XMR via RFP-024. +- **RFP-003 (Atomic Swaps with LEZ, open)** is the foundation: the LEZ-XMR + atomic-swap SDK is the redemption settlement layer. RFP-024 does not modify + RFP-003; it builds the sXMR product on top of it. +- **RFP-025 (sXMR with SLA)** is the complementary design. RFP-024 targets the + privacy-maximalist audience accepting market-clearing redemption; RFP-025 + targets the SLA-needing audience accepting custody risk. The two together + cover the synthetics design space. A reader should pick one or both based on + which user segment they want to serve. +- **RFP-022 (bonded atomic swaps)** could optionally be consumed by RFP-024 as + the redemption-leg primitive: instead of bare atomic swaps, redemption uses + bonded atomic swaps. This compounds LP commitment but adds bond friction on + the LP side. The pure design in this RFP does not require this layering. +- **RFP-023 (reputation-based atomic swaps)** could optionally be consumed for + LP-discovery UX (takers see LP reputation before initiating). Not strictly + required for the core product. +- **RFP-021 (cross-chain privacy DEX)** is orthogonal. RFP-021 offers real-XMR + cross-chain swaps with federated custody; RFP-024 offers synthetic-XMR + exposure with atomic-swap redemption. Different products; same broad audience + can use both. +- **RFP-004 (Privacy-Preserving DEX, open)** is the natural single-chain trading + venue for sXMR once minted. Trade sXMR against stables on RFP-004's AMM pools + under the deshield-swap-reshield pattern; redeem to real XMR via RFP-024. -See [appendix/sxmr-design-space.md](../appendix/sxmr-design-space.md) for the full Goal 1 / Goal 2a / Goal 2b design analysis and the pre-spec validation list. +See +[appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) +for the deployed-synthetics survey (Haven, Synthetix, sBTC, Secret Monero +Bridge) and the privacy-coin specific constraints. See +[appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) for +atomic-swap mechanics and the free-option framing relevant to the redemption-leg +LP economics. ## References - [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) -- [appendix/sxmr-design-space.md](../appendix/sxmr-design-space.md) +- [appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) +- [appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) - [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) -- [Synthetix SIP-302: V3 collateral and snxUSD minting (CDP-style reference)](https://sips.synthetix.io/sips/sip-302/) (accessed 2026-05-21) -- [Bitcoin to Monero atomic swaps (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) (accessed 2026-05-21) -- [eigenwallet/core (XMR atomic swap, active fork of comit-network/xmr-btc-swap; v4.6.1, 2026-05-15)](https://github.com/eigenwallet/core) (accessed 2026-05-21) -- [Stacks docs: sBTC overview](https://docs.stacks.co/learn/sbtc) (accessed 2026-05-21) -- [Stacks docs: sBTC-to-BTC withdrawal](https://docs.stacks.co/more-guides/sbtc/bridging-bitcoin/sbtc-to-btc) (accessed 2026-05-21) -- [Secret Network Monero Bridge (custodial XMR-to-Secret Network reference, structural counter-example for the wedge)](https://docs.scrt.network/) (accessed 2026-05-21) -- [Haven Protocol shutdown notice (December 2024)](https://havenprotocol.org/) (accessed 2026-05-21) -- [Farcaster project (XMR atomic swap; low-velocity, last release v0.8.4 on 2023-01-16, last `farcaster-node` commit Aug 2024)](https://github.com/farcaster-project/farcaster-node) (accessed 2026-05-21) +- [Bitcoin to Monero atomic swaps (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) + (accessed 2026-05-21) +- [eigenwallet/core (active fork of comit-network/xmr-btc-swap; v4.6.1, 2026-05-15)](https://github.com/eigenwallet/core) + (accessed 2026-05-21) +- [Secret Network Monero Bridge (custodial XMR-to-Secret Network bridge, deployed prior art)](https://github.com/maxkoda-cpu/Secret-Monero-Bridge) + (accessed 2026-05-22) +- [Haven Protocol documentation](https://docs.havenprotocol.org) (accessed + 2026-05-22) +- [Stacks docs: sBTC overview](https://docs.stacks.co/learn/sbtc) (specific + trust-shape claims pending vault verification; see + PENDING-atomic-swap-protocol-details.md in the research vault) diff --git a/RFPs/RFP-025-synthetic-xmr-sla.md b/RFPs/RFP-025-synthetic-xmr-sla.md index 09738f9..22c40ee 100644 --- a/RFPs/RFP-025-synthetic-xmr-sla.md +++ b/RFPs/RFP-025-synthetic-xmr-sla.md @@ -9,32 +9,68 @@ category: Applications & Integrations # RFP-025 — Synthetic XMR (sXMR) with Redemption SLA -> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos team and the community compare cross-chain DEX designs across RFP-021 through RFP-025. Hard requirements, team profile, timeline, and contracting details are deliberately omitted; they will be filled in if the design is selected for funding. +> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos +> team and the community compare cross-chain DEX designs across RFP-021 through +> RFP-025. Hard requirements, team profile, timeline, and contracting details +> are deliberately omitted; they will be filled in if the design is selected for +> funding. ## 🧭 Overview -Build a synthetic XMR token (sXMR) on LEZ with a redemption SLA: users can redeem sXMR for real XMR at oracle price, on demand, up to the protocol's committed capacity. The atomic swap is still the settlement primitive, but counterparty availability is no longer left to the open market. +Build a synthetic XMR token (sXMR) on LEZ with a redemption SLA: users can +redeem sXMR for real XMR at oracle price, on demand, up to the protocol's +committed capacity. The atomic swap is still the settlement primitive, but +counterparty availability is no longer left to the open market. The RFP requires applicants to commit to one of two sub-designs: -- **Option 2a: Bonded LP set.** LPs join a registered set on LEZ, post stable collateral as bond, and are obligated to honour redemption requests within a window. Default triggers bond slashing paid to the redeemer. Non-custodial in the strict sense (LPs hold their own XMR) but bonded for performance. -- **Option 2b: Protocol XMR reserve.** The protocol accumulates an XMR reserve (from mint fees, a yield programme, or a one-time treasury seed) held in a threshold-signer multisig on Monero. Redemption draws directly from the reserve. Custodial: trust lives in the signer set. - -The RFP exists so applicants can argue for one of the two and the Logos team can pick. The two options have different threat models, different LP economics, and different regulatory exposures. They cannot be combined cleanly: option 2b's reserve and option 2a's open-but-bonded LP set are different protocols sharing only the sXMR token name. - -This RFP is the marketable companion to RFP-024 (sXMR pure non-custodial). A reader should pick at least one of the two, and may pick both, depending on which user segment they want to serve. +- **Option 2a: Bonded LP set.** LPs join a registered set on LEZ, post stable + collateral as bond, and are obligated to honour redemption requests within a + window. Default triggers bond slashing paid to the redeemer. Non-custodial in + the strict sense (LPs hold their own XMR) but bonded for performance. +- **Option 2b: Protocol XMR reserve.** The protocol accumulates an XMR reserve + (from mint fees, a yield programme, or a one-time treasury seed) held in a + threshold-signer multisig on Monero. Redemption draws directly from the + reserve. Custodial: trust lives in the signer set. + +The RFP exists so applicants can argue for one of the two and the Logos team can +pick. The two options have different threat models, different LP economics, and +different regulatory exposures. They cannot be combined cleanly: option 2b's +reserve and option 2a's open-but-bonded LP set are different protocols sharing +only the sXMR token name. + +This RFP is the marketable companion to RFP-024 (sXMR pure non-custodial). A +reader should pick at least one of the two, and may pick both, depending on +which user segment they want to serve. ## Desired properties (both options) -- **Redemption SLA.** A user redeeming sXMR for XMR receives real XMR on Monero L1 within a documented window (e.g. 60 minutes for option 2a; instant settlement subject to atomic-swap timelock for option 2b). -- **Oracle-priced redemption.** Redemption price is within a documented tolerance of the oracle reference; not subject to LP-quote dispersion. -- **Composable sXMR token on LEZ.** Vanilla LEZ token (the LEZ token program standard from RFP-003 hard requirement 7), callable by lending, DEXes, governance, structured products. -- **Private exit.** Successful redemption ends with real XMR on Monero L1. The XMR side never leaks the redeemer's LEZ-side identity beyond the redemption flow itself. -- **Bondless taker entry path.** First-time redeemers (the taker side, from the atomic-swap perspective) are not required to post a LEZ-denominated bond for the first redemption up to a capped notional (worked example: US$100 equivalent). After the first redemption, the taker has LEZ-denominated assets they can post against subsequent redemptions. The bond on the *LP side* (option 2a) or the *reserve* (option 2b) is unaffected; those are maker-side or protocol-side constructs. +- **Redemption SLA.** A user redeeming sXMR for XMR receives real XMR on Monero + L1 within a documented window (e.g. 60 minutes for option 2a; instant + settlement subject to atomic-swap timelock for option 2b). +- **Oracle-priced redemption.** Redemption price is within a documented + tolerance of the oracle reference; not subject to LP-quote dispersion. +- **Composable sXMR token on LEZ.** Vanilla LEZ token (the LEZ token program + standard from RFP-003 hard requirement 7), callable by lending, DEXes, + governance, structured products. +- **Private exit.** Successful redemption ends with real XMR on Monero L1. The + XMR side never leaks the redeemer's LEZ-side identity beyond the redemption + flow itself. +- **Bondless taker entry path.** First-time redeemers (the taker side, from the + atomic-swap perspective) are not required to post a LEZ-denominated bond for + the first redemption up to a capped notional (worked example: US$100 + equivalent). After the first redemption, the taker has LEZ-denominated assets + they can post against subsequent redemptions. The bond on the *LP side* + (option 2a) or the *reserve* (option 2b) is unaffected; those are maker-side + or protocol-side constructs. ## Option 2a: bonded LP set -LPs join a registered set on LEZ. Each LP posts stable collateral on LEZ equal to (or some multiple of) their XMR commitment. When a redemption request is routed to an LP, they must complete the atomic swap within a window. If they default, their bond is slashed and paid to the redeemer. LPs may leave the set, but only after a notice period that exceeds the redemption SLA. +LPs join a registered set on LEZ. Each LP posts stable collateral on LEZ equal +to (or some multiple of) their XMR commitment. When a redemption request is +routed to an LP, they must complete the atomic swap within a window. If they +default, their bond is slashed and paid to the redeemer. LPs may leave the set, +but only after a notice period that exceeds the redemption SLA. ``` sXMR LEZ program @@ -54,11 +90,24 @@ LPs join a registered set on LEZ. Each LP posts stable collateral on LEZ equal t attribution layered via RFP-023 reputation ``` -**Enforceability caveat.** "LP defaulted" is not a verdict an on-chain program can render from atomic-swap state alone (per the cross-cutting analysis in [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md)). Refusing to proceed is *valid behaviour* under the atomic-swap protocol; the LEZ contract cannot distinguish malicious refusal from connectivity loss. The realistic implementation consumes the RFP-023 reputation primitive as the attribution layer: an LP who repeatedly fails to honour redemptions loses reputation; the bond is slashed against the *attested* default condition, not against atomic-swap state directly. Without RFP-023 (or an equivalent attestor mechanism), the bond can be used only to gate participation (priority, fee tiers, future-slot access), not slashed with cryptographic certainty on a single failed swap. +**Enforceability caveat.** "LP defaulted" is not a verdict an on-chain program +can render from atomic-swap state alone (per the cross-cutting analysis in +[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md)). +Refusing to proceed is *valid behaviour* under the atomic-swap protocol; the LEZ +contract cannot distinguish malicious refusal from connectivity loss. The +realistic implementation consumes the RFP-023 reputation primitive as the +attribution layer: an LP who repeatedly fails to honour redemptions loses +reputation; the bond is slashed against the *attested* default condition, not +against atomic-swap state directly. Without RFP-023 (or an equivalent attestor +mechanism), the bond can be used only to gate participation (priority, fee +tiers, future-slot access), not slashed with cryptographic certainty on a single +failed swap. ## Option 2b: protocol XMR reserve -The protocol holds an XMR reserve in a threshold-signer multisig on Monero. Redemption draws from the reserve directly, with the atomic swap acting as the settlement rail between the reserve custodian and the redeemer. +The protocol holds an XMR reserve in a threshold-signer multisig on Monero. +Redemption draws from the reserve directly, with the atomic swap acting as the +settlement rail between the reserve custodian and the redeemer. ``` sXMR LEZ program @@ -76,109 +125,233 @@ The protocol holds an XMR reserve in a threshold-signer multisig on Monero. Rede (n-of-m, bonded signers, view-key-shared) ``` -At this point the design has adopted sBTC's (Stacks) threshold-signer custody model, with an oracle-priced peg layer replacing sBTC's 1:1 redemption peg. The structural overlap is the custody side (a bonded n-of-m signer set holding the underlying asset on its native chain); the peg semantics differ (sBTC is 1:1 redemption-backed, this design is oracle-priced). The atomic swap is the wire format; trust lives in the signer set. The same view-key-shared TSS custody constraint applies as in RFP-021: honest-but-curious signers learn the protocol-side deposit history. This is the structural trade-off option 2b accepts in exchange for the redemption SLA. The signer set must be bonded and slashable to make the trust assumption explicit. +At this point the design has adopted sBTC's (Stacks) threshold-signer custody +model, with an oracle-priced peg layer replacing sBTC's 1:1 redemption peg. The +structural overlap is the custody side (a bonded n-of-m signer set holding the +underlying asset on its native chain); the peg semantics differ (sBTC is 1:1 +redemption-backed, this design is oracle-priced). The atomic swap is the wire +format; trust lives in the signer set. The same view-key-shared TSS custody +constraint applies as in RFP-021: honest-but-curious signers learn the +protocol-side deposit history. This is the structural trade-off option 2b +accepts in exchange for the redemption SLA. The signer set must be bonded and +slashable to make the trust assumption explicit. ## High-level functionality and flow (common) ### Mint -Identical to RFP-024. User deposits accepted LEZ collateral; protocol mints sXMR at oracle price; collateral sits in vault. +Identical to RFP-024. User deposits accepted LEZ collateral; protocol mints sXMR +at oracle price; collateral sits in vault. ### Redemption (option 2a) 1. Alice (sXMR holder) submits a redemption request to the LEZ sXMR program. -2. Program routes the request to a bonded LP in the registry (round-robin, reputation-weighted, or auction-priced). -3. LP receives the request; LP and Alice execute an atomic swap via the RFP-003 LEZ-XMR SDK within the SLA window. -4. On success, Alice's sXMR is burned, LP claims the released collateral as their payout. -5. On failure (LP times out): bond slashing is triggered. RFP-023 reputation attestation establishes that the failure was the LP's fault (not the redeemer's); slashed bond is paid to the redeemer as compensation; LP's reputation is decremented. +2. Program routes the request to a bonded LP in the registry (round-robin, + reputation-weighted, or auction-priced). +3. LP receives the request; LP and Alice execute an atomic swap via the RFP-003 + LEZ-XMR SDK within the SLA window. +4. On success, Alice's sXMR is burned, LP claims the released collateral as + their payout. +5. On failure (LP times out): bond slashing is triggered. RFP-023 reputation + attestation establishes that the failure was the LP's fault (not the + redeemer's); slashed bond is paid to the redeemer as compensation; LP's + reputation is decremented. ### Redemption (option 2b) 1. Alice submits a redemption request. -2. Program signals the reserve module; threshold signers co-sign a Monero spend from the reserve to a destination Alice supplies. -3. Atomic-swap protocol enforces the conditional: Alice's sXMR is burned only if the Monero spend lands on chain. -4. Reserve accounting updates; if the reserve is depleted below a safety threshold, mints are paused until the reserve is replenished from mint fees or treasury. +2. Program signals the reserve module; threshold signers co-sign a Monero spend + from the reserve to a destination Alice supplies. +3. Atomic-swap protocol enforces the conditional: Alice's sXMR is burned only if + the Monero spend lands on chain. +4. Reserve accounting updates; if the reserve is depleted below a safety + threshold, mints are paused until the reserve is replenished from mint fees + or treasury. ## Pros (both options) -- **Redemption SLA is a real product feature.** Institutions, market makers, and structured-products integrators can underwrite sXMR positions because they have a documented exit window. -- **Hard peg within capacity.** Redemption price tracks oracle within a documented tolerance, not LP-quote dispersion. The sXMR token becomes usable as collateral inside other LEZ programs with predictable mark-to-market. -- **Composable from day one.** Vanilla LEZ token; the SLA is what makes downstream integrations viable. -- **Private exit preserved.** Successful redemption ends with real XMR on Monero L1, regardless of which option is chosen. Privacy on the destination chain is intact. -- **Bondless taker entry path.** Privacy-seeking redeemers without LEZ assets can complete a first capped redemption without bond friction. +- **Redemption SLA is a real product feature.** Institutions, market makers, and + structured-products integrators can underwrite sXMR positions because they + have a documented exit window. +- **Hard peg within capacity.** Redemption price tracks oracle within a + documented tolerance, not LP-quote dispersion. The sXMR token becomes usable + as collateral inside other LEZ programs with predictable mark-to-market. +- **Composable from day one.** Vanilla LEZ token; the SLA is what makes + downstream integrations viable. +- **Private exit preserved.** Successful redemption ends with real XMR on Monero + L1, regardless of which option is chosen. Privacy on the destination chain is + intact. +- **Bondless taker entry path.** Privacy-seeking redeemers without LEZ assets + can complete a first capped redemption without bond friction. ## Pros (option 2a-specific) -- **Non-custodial in the strict sense.** LPs custody their own XMR; the protocol does not hold the underlying asset. No vault to drain. -- **Decentralised LP set.** Anyone meeting the bond requirement can join the registered set. -- **Slashing bounds the loss.** A defaulting LP's bond becomes the redeemer's compensation; protocol-wide solvency is bounded by total bonded capacity. -- **No signer-set custody risk for sXMR holders.** Trust assumption is the bonded-LP set's collective behaviour, which is bounded by the bond size, not by signer-set integrity. +- **Non-custodial in the strict sense.** LPs custody their own XMR; the protocol + does not hold the underlying asset. No vault to drain. +- **Decentralised LP set.** Anyone meeting the bond requirement can join the + registered set. +- **Slashing bounds the loss.** A defaulting LP's bond becomes the redeemer's + compensation; protocol-wide solvency is bounded by total bonded capacity. +- **No signer-set custody risk for sXMR holders.** Trust assumption is the + bonded-LP set's collective behaviour, which is bounded by the bond size, not + by signer-set integrity. ## Pros (option 2b-specific) -- **Strongest SLA guarantee.** Redemption draws from a protocol-managed reserve; no LP discovery, no per-redemption matching. Settlement is deterministic up to the atomic-swap protocol's timelock. -- **Predictable redemption capacity.** Bounded by the reserve size; capacity planning is governance-driven rather than LP-supply-driven. -- **Lower operational complexity for redeemers.** Single counterparty (the reserve module), not a matched LP. +- **Strongest SLA guarantee.** Redemption draws from a protocol-managed reserve; + no LP discovery, no per-redemption matching. Settlement is deterministic up to + the atomic-swap protocol's timelock. +- **Predictable redemption capacity.** Bounded by the reserve size; capacity + planning is governance-driven rather than LP-supply-driven. +- **Lower operational complexity for redeemers.** Single counterparty (the + reserve module), not a matched LP. ## Cons (both options) -- **Some form of trust returns.** RFP-024 (pure) trusts only the oracle and the atomic-swap protocol; RFP-025 trusts additionally an LP set (option 2a) or a signer set (option 2b). The cypherpunk story is weaker. -- **Atomic-swap UX is still inherited.** Settlement time is dominated by Monero block confirmations, typically under an hour but with variance from network conditions; both parties online for the duration. The SLA constrains the *availability* of the counterparty but not the cryptographic settlement time. -- **Oracle dependency is sharper.** With an SLA on oracle-priced redemption, an oracle failure has SLA-breaking consequences, not just mint-side accuracy consequences. -- **Regulatory exposure is higher.** A protocol that commits to redeeming a privacy coin on demand draws more scrutiny than RFP-024's price-feed-plus-matching-board posture. +- **Some form of trust returns.** RFP-024 (pure) trusts only the oracle and the + atomic-swap protocol; RFP-025 trusts additionally an LP set (option 2a) or a + signer set (option 2b). The cypherpunk story is weaker. +- **Atomic-swap UX is still inherited.** Settlement time is dominated by Monero + block confirmations, typically under an hour but with variance from network + conditions; both parties online for the duration. The SLA constrains the + *availability* of the counterparty but not the cryptographic settlement time. +- **Oracle dependency is sharper.** With an SLA on oracle-priced redemption, an + oracle failure has SLA-breaking consequences, not just mint-side accuracy + consequences. +- **Regulatory exposure is higher.** A protocol that commits to redeeming a + privacy coin on demand draws more scrutiny than RFP-024's + price-feed-plus-matching-board posture. ## Cons (option 2a-specific) -- **Slashing requires off-chain attribution.** The LEZ contract cannot adjudicate "LP defaulted" from atomic-swap state. RFP-023 reputation is the realistic attribution mechanism; without it, the bond gates participation but does not slash on single defaults. -- **Bond opportunity cost limits LP supply.** Locking stable collateral against XMR commitment is expensive; LP yield must clear the opportunity cost. Realistic capacity is constrained by the LP economy's appetite for the bond/yield trade-off. -- **Coordinated default can exceed bonded capacity.** If many LPs default simultaneously (e.g. during a Monero price shock), aggregate slashing may not cover aggregate redemption demand. The peg breaks. -- **LP notice period limits flexibility.** LPs must wait out a notice period exceeding the SLA before exiting the set; this raises the cost of becoming an LP. +- **Slashing requires off-chain attribution.** The LEZ contract cannot + adjudicate "LP defaulted" from atomic-swap state. RFP-023 reputation is the + realistic attribution mechanism; without it, the bond gates participation but + does not slash on single defaults. +- **Bond opportunity cost limits LP supply.** Locking stable collateral against + XMR commitment is expensive; LP yield must clear the opportunity cost. + Realistic capacity is constrained by the LP economy's appetite for the + bond/yield trade-off. +- **Coordinated default can exceed bonded capacity.** If many LPs default + simultaneously (e.g. during a Monero price shock), aggregate slashing may not + cover aggregate redemption demand. The peg breaks. +- **LP notice period limits flexibility.** LPs must wait out a notice period + exceeding the SLA before exiting the set; this raises the cost of becoming an + LP. ## Cons (option 2b-specific) -- **Custodial.** A signer set holds real XMR on Monero. Custody risk is real: signer collusion, key compromise, or signing-software bug can drain the reserve. This is the failure mode that hit Thorchain on 2026-05-15 (TSS implementation weakness, $10.8M). The Wormhole February 2022 incident ($326M) is a related-but-distinct category: a per-chain bridge-contract bug (`load_instruction_at` on Solana) bypassed the signer set entirely rather than compromising it; the lesson is that per-chain contract surface adds attack vectors independent of the TSS itself. -- **View-key-shared custody leaks Monero deposit history to signers.** The same compromise RFP-021 makes. Honest-but-curious signers learn the protocol-side Monero deposit history; this is the structural cost of TSS custody of XMR with current cryptography. -- **Adopts sBTC (Stacks)'s threshold-signer custody model, with an oracle-priced peg replacing 1:1 redemption.** The custody novelty is small relative to existing custodial XMR wraps (the differentiator is the LEZ privacy execution on the sXMR token side, plus the explicit slashable-signer-bond posture). -- **Reserve undercollateralisation breaks the peg.** If the reserve is drawn down faster than it can be replenished from fees, redemption capacity goes to zero; sXMR loses its peg. -- **Signer-set membership is gated.** Lower decentralisation than option 2a; signer set is a censorship and coercion target. +- **Custodial.** A signer set holds real XMR on Monero. Custody risk is real: + signer collusion, key compromise, or signing-software bug can drain the + reserve. This is the failure mode that hit Thorchain on 2026-05-15 (TSS + implementation weakness, $10.8M). The Wormhole February 2022 incident ($326M) + is a related-but-distinct category: a per-chain bridge-contract bug + (`load_instruction_at` on Solana) bypassed the signer set entirely rather than + compromising it; the lesson is that per-chain contract surface adds attack + vectors independent of the TSS itself. +- **View-key-shared custody leaks Monero deposit history to signers.** The same + compromise RFP-021 makes. Honest-but-curious signers learn the protocol-side + Monero deposit history; this is the structural cost of TSS custody of XMR with + current cryptography. +- **Adopts sBTC (Stacks)'s threshold-signer custody model, with an oracle-priced + peg replacing 1:1 redemption.** The custody novelty is small relative to + existing custodial XMR wraps (the differentiator is the LEZ privacy execution + on the sXMR token side, plus the explicit slashable-signer-bond posture). +- **Reserve undercollateralisation breaks the peg.** If the reserve is drawn + down faster than it can be replenished from fees, redemption capacity goes to + zero; sXMR loses its peg. +- **Signer-set membership is gated.** Lower decentralisation than option 2a; + signer set is a censorship and coercion target. ## Risks (both options) -- **Oracle manipulation.** A manipulated XMR/USD oracle lets an attacker mint sXMR cheaply or extract reserve XMR (option 2b) at unfavourable rates. Mitigation: redundant oracle stack with median-of-N pricing; configurable price-deviation guards; SLA-aware oracle staleness checks. -- **Regulatory action.** Either option may attract jurisdiction-specific bans on the protocol, LP participation, or reserve custody. Mitigation: jurisdictional diversity in LP set or signer set; documented compliance posture; willingness to operate as a permissionless smart contract regardless of any single jurisdiction's stance. -- **First-swap cap evasion.** A redeemer could split a large redemption into many capped first-redemptions under fresh pseudonyms. Mitigation: rate limits enforced at the LEZ escrow program; combine with reputation gating (RFP-023) for higher tiers. +- **Oracle manipulation.** A manipulated XMR/USD oracle lets an attacker mint + sXMR cheaply or extract reserve XMR (option 2b) at unfavourable rates. + Mitigation: redundant oracle stack with median-of-N pricing; configurable + price-deviation guards; SLA-aware oracle staleness checks. +- **Regulatory action.** Either option may attract jurisdiction-specific bans on + the protocol, LP participation, or reserve custody. Mitigation: jurisdictional + diversity in LP set or signer set; documented compliance posture; willingness + to operate as a permissionless smart contract regardless of any single + jurisdiction's stance. +- **First-swap cap evasion.** A redeemer could split a large redemption into + many capped first-redemptions under fresh pseudonyms. Mitigation: rate limits + enforced at the LEZ escrow program; combine with reputation gating (RFP-023) + for higher tiers. ## Risks (option 2a-specific) -- **RFP-023 dependency.** Without a reputation primitive, the bond is not actually slashable on default. If RFP-023 ships later than RFP-025 option 2a, the protocol launches with a weaker enforcement story than its marketing implies. Mitigation: sequence RFP-023 first, or include a stub-reputation mechanism in RFP-025 itself. -- **Reputation gaming attacks on the LP side.** An LP can build reputation cheaply by completing many small redemptions then default on a large one. Mitigation: notional-weighted reputation; cap per-LP redemption size proportional to accumulated reputation and bond. -- **Bond denomination volatility.** If the bond asset (stables on LEZ) depegs, LPs become under-collateralised against their XMR commitments. Mitigation: cap protocol-wide LP collateral concentration by asset; require LPs to top up on bond-asset depeg events. +- **RFP-023 dependency.** Without a reputation primitive, the bond is not + actually slashable on default. If RFP-023 ships later than RFP-025 option 2a, + the protocol launches with a weaker enforcement story than its marketing + implies. Mitigation: sequence RFP-023 first, or include a stub-reputation + mechanism in RFP-025 itself. +- **Reputation gaming attacks on the LP side.** An LP can build reputation + cheaply by completing many small redemptions then default on a large one. + Mitigation: notional-weighted reputation; cap per-LP redemption size + proportional to accumulated reputation and bond. +- **Bond denomination volatility.** If the bond asset (stables on LEZ) depegs, + LPs become under-collateralised against their XMR commitments. Mitigation: cap + protocol-wide LP collateral concentration by asset; require LPs to top up on + bond-asset depeg events. ## Risks (option 2b-specific) -- **Signer-set compromise.** A captured signer set can drain the entire reserve. Mitigation: large signer set (Serai uses up to 600; Thorchain ~100); permissionless entry; high bond-to-custodied ratio; emergency halt mechanism; geographic diversity. -- **Signer-set offline event.** If the signer set cannot reach threshold to sign (network partition, mass node failure), redemption SLA breaks even with no malice. Mitigation: redundant signer geographic placement; documented signer SLOs; emergency-halt mechanism that pauses redemption gracefully rather than failing under load. -- **TSS implementation bug.** Thorchain's GG20 TSS exploit on 2026-05-15 ($10.8M) is the canonical example. Mitigation: choose FROST over GG20; budget for Cypher Stack-equivalent audit; isolate signer-software dependencies. +- **Signer-set compromise.** A captured signer set can drain the entire reserve. + Mitigation: large signer set (Serai uses up to 600; Thorchain ~100); + permissionless entry; high bond-to-custodied ratio; emergency halt mechanism; + geographic diversity. +- **Signer-set offline event.** If the signer set cannot reach threshold to sign + (network partition, mass node failure), redemption SLA breaks even with no + malice. Mitigation: redundant signer geographic placement; documented signer + SLOs; emergency-halt mechanism that pauses redemption gracefully rather than + failing under load. +- **TSS implementation bug.** Thorchain's GG20 TSS exploit on 2026-05-15 + ($10.8M) is the canonical example. Mitigation: choose FROST over GG20; budget + for Cypher Stack-equivalent audit; isolate signer-software dependencies. ## Relationship to other RFPs in this bundle -- **RFP-024 (sXMR pure non-custodial)** is the complementary design. RFP-025 trades non-custody for SLA. A reader should pick one or both based on the target audience: pure-cypherpunk users for RFP-024; SLA-needing users for RFP-025. -- **RFP-003 (Atomic Swaps with LEZ, open)** is the foundation: the LEZ-XMR atomic-swap SDK is the redemption settlement layer for both options. -- **RFP-023 (reputation-based atomic swaps)** is a hard dependency for option 2a's slashing mechanism. The reputation primitive is what makes "LP defaulted" attributable. -- **RFP-022 (bonded atomic swaps)** could optionally be consumed by either option as the bonded-redemption-leg primitive on the atomic-swap settlement, layered on top of the LP-side or reserve-side bond. -- **RFP-021 (cross-chain privacy DEX)** is orthogonal: it offers real-asset cross-chain swaps with federated custody; this RFP offers synthetic-XMR exposure with managed redemption. Option 2b shares the view-key-shared TSS custody trade-off with RFP-021's XMR support; the two RFPs could share signer-set infrastructure if both are funded. -- **RFP-004 (Privacy-Preserving DEX, open)** is the natural single-chain trading venue for sXMR. - -See [appendix/sxmr-design-space.md](../appendix/sxmr-design-space.md) for the Goal 2a vs Goal 2b property matrix and decision tree. +- **RFP-024 (sXMR pure non-custodial)** is the complementary design. RFP-025 + trades non-custody for SLA. A reader should pick one or both based on the + target audience: pure-cypherpunk users for RFP-024; SLA-needing users for + RFP-025. +- **RFP-003 (Atomic Swaps with LEZ, open)** is the foundation: the LEZ-XMR + atomic-swap SDK is the redemption settlement layer for both options. +- **RFP-023 (reputation-based atomic swaps)** is a hard dependency for option + 2a's slashing mechanism. The reputation primitive is what makes "LP defaulted" + attributable. +- **RFP-022 (bonded atomic swaps)** could optionally be consumed by either + option as the bonded-redemption-leg primitive on the atomic-swap settlement, + layered on top of the LP-side or reserve-side bond. +- **RFP-021 (cross-chain privacy DEX)** is orthogonal: it offers real-asset + cross-chain swaps with federated custody; this RFP offers synthetic-XMR + exposure with managed redemption. Option 2b shares the view-key-shared TSS + custody trade-off with RFP-021's XMR support; the two RFPs could share + signer-set infrastructure if both are funded. +- **RFP-004 (Privacy-Preserving DEX, open)** is the natural single-chain trading + venue for sXMR. + +See +[appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) +for the deployed-synthetics survey (Haven, Synthetix, sBTC, Secret Monero +Bridge) including the redeem-to-underlying-with-custody design family (option +2b's pattern). See +[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) +for the federated-signer custody analysis that applies to option 2b. ## References - [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) -- [appendix/sxmr-design-space.md](../appendix/sxmr-design-space.md) +- [appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) - [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) -- [sBTC (Stacks) Bitcoin layer documentation](https://docs.stacks.co/learn/sbtc) (accessed 2026-05-21) -- [sBTC withdrawal to a user-supplied Bitcoin address](https://docs.stacks.co/more-guides/sbtc/bridging-bitcoin/sbtc-to-btc) (accessed 2026-05-21) -- [Synthetix SIP-302: V3 collateral and snxUSD minting (CDP-style reference)](https://sips.synthetix.io/sips/sip-302/) (accessed 2026-05-21) -- [Crypto Times: $10.8M drained from Thorchain on 2026-05-15](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) (accessed 2026-05-21) -- [Halborn: Wormhole Hack on 2022-02-02 (technical analysis)](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) (accessed 2026-05-21) -- [FROST: Flexible Round-Optimized Schnorr Threshold Signatures (Komlo and Goldberg, SAC 2020 / IACR 2020/852)](https://eprint.iacr.org/2020/852) (accessed 2026-05-21) +- [appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) +- [sBTC (Stacks) Bitcoin layer documentation](https://docs.stacks.co/learn/sbtc) + (specific trust-shape claims pending vault verification; see + PENDING-atomic-swap-protocol-details.md in the research vault) +- [Crypto Times: $10.8M drained from Thorchain on 2026-05-15](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) + (accessed 2026-05-19) +- [Halborn: Wormhole Hack on 2022-02-02 (technical analysis)](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) + (accessed 2026-05-19) +- [FROST: Flexible Round-Optimized Schnorr Threshold Signatures (Komlo and Goldberg, SAC 2020 / IACR 2020/852)](https://eprint.iacr.org/2020/852) + (accessed 2026-05-21) diff --git a/appendix/atomic-swaps-primer.md b/appendix/atomic-swaps-primer.md index 8e0a4bd..1db374b 100644 --- a/appendix/atomic-swaps-primer.md +++ b/appendix/atomic-swaps-primer.md @@ -1,21 +1,46 @@ # Atomic Swaps Primer -Background appendix on how cross-chain atomic swaps work. Covers the cryptographic mechanics, the canonical XMR-BTC flow, and the free-option property of atomicity. Pure survey of deployed protocols and published literature; no specific RFP designs. +Background appendix on how cross-chain atomic swaps work. Covers the +cryptographic mechanics, the canonical XMR-BTC flow, and the free-option +property of atomicity. Pure survey of deployed protocols and published +literature; no specific RFP designs. ## The primitive -An atomic swap is a two-party exchange of assets on two different chains where either both legs settle or both legs unwind. Atomicity comes from cryptography, not from a third party: a single secret unlocks both legs, and the protocol is constructed so revealing the secret on one chain forces revelability on the other. +An atomic swap is a two-party exchange of assets on two different chains where +either both legs settle or both legs unwind. Atomicity comes from cryptography, +not from a third party: a single secret unlocks both legs, and the protocol is +constructed so revealing the secret on one chain forces revelability on the +other. Two cryptographic constructions are deployed: -- **Hash time-locked contract (HTLC)** for chain pairs with compatible scripting. The lock outputs are spendable either by knowledge of a hash preimage `s` (claim path) or by waiting out a timelock (refund path). Decred-Litecoin executed the first on-chain HTLC swap on 2017-09-20. Source: [Decred blog, On-Chain Atomic Swaps (2017-09-20)](https://blog.decred.org/2017/09/20/On-Chain-Atomic-Swaps/) (accessed 2026-05-21). -- **Adaptor signatures with cross-curve DLEQ proofs** for chain pairs where one side has restricted scripting (e.g. Monero). The secret is a scalar that completes a signature on one chain; revealing it lets the counterparty produce a valid signature on the other. The construction was first proposed for BTC-XMR in 2017 and reached working implementations in 2021. Sources: [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) (accessed 2026-05-21); [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332](https://arxiv.org/abs/2101.12332) (accessed 2026-05-21); [getmonero.org: Bitcoin to Monero atomic swaps are now live, 2021-08-20](https://www.getmonero.org/2021/08/20/atomic-swaps.html) (accessed 2026-05-21). - -The two constructions differ in their script requirements but share the same trust model and the same free-option property. +- **Hash time-locked contract (HTLC)** for chain pairs with compatible + scripting. The lock outputs are spendable either by knowledge of a hash + preimage `s` (claim path) or by waiting out a timelock (refund path). + Decred-Litecoin executed the first on-chain HTLC swap on 2017-09-20. Source: + [Decred blog, On-Chain Atomic Swaps (2017-09-20)](https://blog.decred.org/2017/09/20/On-Chain-Atomic-Swaps/) + (accessed 2026-05-21). +- **Adaptor signatures with cross-curve DLEQ proofs** for chain pairs where one + side has restricted scripting (e.g. Monero). The secret is a scalar that + completes a signature on one chain; revealing it lets the counterparty produce + a valid signature on the other. The construction was first proposed for + BTC-XMR in 2017 and reached working implementations in 2021. Sources: + [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) + (accessed 2026-05-21); + [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332](https://arxiv.org/abs/2101.12332) + (accessed 2026-05-21); + [getmonero.org: Bitcoin to Monero atomic swaps are now live, 2021-08-20](https://www.getmonero.org/2021/08/20/atomic-swaps.html) + (accessed 2026-05-21). + +The two constructions differ in their script requirements but share the same +trust model and the same free-option property. ## The canonical XMR-BTC swap -Standard adaptor-signature flow, as implemented by COMIT (`xmr-btc-swap`, archival pending since 2024-11) and its successor fork eigenwallet (`core`, active as of v4.6.1 on 2026-05-15). +Standard adaptor-signature flow, as implemented by COMIT (`xmr-btc-swap`, +archival pending since 2024-11) and its successor fork eigenwallet (`core`, +active as of v4.6.1 on 2026-05-15). ### Roles @@ -54,46 +79,108 @@ sequenceDiagram ### Why BTC is locked first -The script-bearing side locks first **by construction of the adaptor-signature primitive**, not as a design choice. +The script-bearing side locks first **by construction of the adaptor-signature +primitive**, not as a design choice. -The mechanism: the secret that completes the swap is an Ed25519 scalar `s` whose discrete log corresponds to one half of the joint Monero spend key. Alice's adaptor signature on a Bitcoin transaction is a *signature with `s` factored out*; Bob can adapt it into a valid signature by adding `s`, but the act of broadcasting that adapted signature on Bitcoin publishes `s` as part of the on-chain transaction (it can be extracted by anyone observing the broadcast). Alice then uses `s` to construct a Monero spend signature for the joint-key output, claiming the XMR. +The mechanism: the secret that completes the swap is an Ed25519 scalar `s` whose +discrete log corresponds to one half of the joint Monero spend key. Alice's +adaptor signature on a Bitcoin transaction is a *signature with `s` factored +out*; Bob can adapt it into a valid signature by adding `s`, but the act of +broadcasting that adapted signature on Bitcoin publishes `s` as part of the +on-chain transaction (it can be extracted by anyone observing the broadcast). +Alice then uses `s` to construct a Monero spend signature for the joint-key +output, claiming the XMR. Reversing the order does not compose: -- If Bob locked XMR first, there would be no Bitcoin transaction whose broadcast reveals `s`. Bob would need a way to commit to `s` such that Alice can extract it after she locks BTC — but the only mechanism the primitive provides is "Bob's broadcast of a Bitcoin-claim signature reveals `s`", which presupposes Bob has something to claim on Bitcoin. -- Equivalently: the secret-revelation flow points from BTC settlement to XMR claimability. The chain that hosts the adaptor signature (BTC) must hold a lock the counterparty wants to claim before the secret materialises. +- If Bob locked XMR first, there would be no Bitcoin transaction whose broadcast + reveals `s`. Bob would need a way to commit to `s` such that Alice can extract + it after she locks BTC — but the only mechanism the primitive provides is + "Bob's broadcast of a Bitcoin-claim signature reveals `s`", which presupposes + Bob has something to claim on Bitcoin. +- Equivalently: the secret-revelation flow points from BTC settlement to XMR + claimability. The chain that hosts the adaptor signature (BTC) must hold a + lock the counterparty wants to claim before the secret materialises. -Consequence: **whichever chain holds the script side of the swap locks first.** For XMR-BTC, BTC. For XMR with any other script-bearing chain, that chain. This is a property of the primitive, fixed independently of who is taker or maker. +Consequence: **whichever chain holds the script side of the swap locks first.** +For XMR-BTC, BTC. For XMR with any other script-bearing chain, that chain. This +is a property of the primitive, fixed independently of who is taker or maker. ### Timelocks and refunds -Each lock has a refund timelock. If the swap stalls before reveal, the locker can sweep their lock back after the timelock expires. The script-side refund (Alice's BTC) typically has a shorter timelock than the secret-side refund (Bob's XMR), so Alice cannot wait until Bob has refunded his XMR and then claim Alice-side BTC anyway. +Each lock has a refund timelock. If the swap stalls before reveal, the locker +can sweep their lock back after the timelock expires. The script-side refund +(Alice's BTC) typically has a shorter timelock than the secret-side refund +(Bob's XMR), so Alice cannot wait until Bob has refunded his XMR and then claim +Alice-side BTC anyway. -Refund and claim windows are conventionally measured in hours. A swap that proceeds normally completes in roughly one Bitcoin confirmation depth (typically 10-60 minutes for the BTC lock) plus one Monero confirmation depth (typically 10-30 minutes for the XMR lock) plus the reveal latency. +Refund and claim windows are conventionally measured in hours. A swap that +proceeds normally completes in roughly one Bitcoin confirmation depth (typically +10-60 minutes for the BTC lock) plus one Monero confirmation depth (typically +10-30 minutes for the XMR lock) plus the reveal latency. ### Production status of XMR-BTC implementations -- **COMIT `xmr-btc-swap`**: original reference implementation, [unmaintained since 2024-11, archival pending per issue #1791](https://github.com/comit-network/xmr-btc-swap) (accessed 2026-05-21). -- **eigenwallet `core`**: active fork of `xmr-btc-swap`; v4.6.1 released 2026-05-15. [github.com/eigenwallet/core](https://github.com/eigenwallet/core) (accessed 2026-05-21). -- **Farcaster Project (`farcaster-project/farcaster-node`)**: independent BTC-XMR implementation. Still listed as actively maintained as of 2026, with Lightning BTC support added to reduce BTC-side confirmation time. Community-scale rather than volume-scale operation. Sources: [xgram.io: Best Monero atomic swap platforms 2026](https://xgram.io/blog/best-xmr-atomic-swaps-and-community-services-2026) (accessed 2026-05-19); [github.com/farcaster-project](https://github.com/farcaster-project) (accessed 2026-05-19). -- **AtomicDEX / Komodo Wallet**: rebranded to "Komodo Wallet" in 2025. Public trackers report no recent volume; Nomics' last published 24-hour volume figure is approximately USD 5,737 from November 2021. Source: [Nomics: AtomicDEX](https://nomics.com/exchanges/atomicdex) (accessed 2026-05-19). -- **Liquality**: consumer atomic-swap wallet extension discontinued effective 2024-06-15. Sources: [Liquality on X, 2024-05-20](https://x.com/Liquality_io/status/1792678368694985162) (accessed 2026-05-19); [Rootstock Helpdesk: Liquality](https://helpdesk.rootstock.io/solutions/liquality.html) (accessed 2026-05-19). - -The XMR-BTC corridor is operational but at community scale. See the [trust-model contrast appendix](./cross-chain-trust-model-contrast.md) for cumulative-volume comparison against federated-signer protocols. +- **COMIT `xmr-btc-swap`**: original reference implementation, + [unmaintained since 2024-11, archival pending per issue #1791](https://github.com/comit-network/xmr-btc-swap) + (accessed 2026-05-21). +- **eigenwallet `core`**: active fork of `xmr-btc-swap`; v4.6.1 released + 2026-05-15. [github.com/eigenwallet/core](https://github.com/eigenwallet/core) + (accessed 2026-05-21). +- **Farcaster Project (`farcaster-project/farcaster-node`)**: independent + BTC-XMR implementation. Still listed as actively maintained as of 2026, with + Lightning BTC support added to reduce BTC-side confirmation time. + Community-scale rather than volume-scale operation. Sources: + [xgram.io: Best Monero atomic swap platforms 2026](https://xgram.io/blog/best-xmr-atomic-swaps-and-community-services-2026) + (accessed 2026-05-19); + [github.com/farcaster-project](https://github.com/farcaster-project) (accessed + 2026-05-19). +- **AtomicDEX / Komodo Wallet**: rebranded to "Komodo Wallet" in 2025. Public + trackers report no recent volume; Nomics' last published 24-hour volume figure + is approximately USD 5,737 from November 2021. Source: + [Nomics: AtomicDEX](https://nomics.com/exchanges/atomicdex) (accessed + 2026-05-19). +- **Liquality**: consumer atomic-swap wallet extension discontinued effective + 2024-06-15. Sources: + [Liquality on X, 2024-05-20](https://x.com/Liquality_io/status/1792678368694985162) + (accessed 2026-05-19); + [Rootstock Helpdesk: Liquality](https://helpdesk.rootstock.io/solutions/liquality.html) + (accessed 2026-05-19). + +The XMR-BTC corridor is operational but at community scale. See the +[trust-model contrast appendix](./cross-chain-trust-model-contrast.md) for +cumulative-volume comparison against federated-signer protocols. ## The free-option problem -Atomic swaps are deliberately symmetric: either party can refuse the next message at any stage, and both sides refund at timeout. From outside, this looks like a stall; structurally, it is the design. +Atomic swaps are deliberately symmetric: either party can refuse the next +message at any stage, and both sides refund at timeout. From outside, this looks +like a stall; structurally, it is the design. -At each phase boundary, one party has committed (locked their leg) and the other has not yet acted. The uncommitted party holds a **free option**: they can observe the market for the duration of the lock window and proceed only if the trade is still in their favour. +At each phase boundary, one party has committed (locked their leg) and the other +has not yet acted. The uncommitted party holds a **free option**: they can +observe the market for the duration of the lock window and proceed only if the +trade is still in their favour. Stage-by-stage in the XMR-BTC flow: -1. **After Alice locks BTC (step 1, before step 2).** Bob holds the free option. If XMR price has moved against him since the quote, he simply does not lock XMR. Alice's BTC refunds at timeout. Bob's downside: time. Alice's downside: lock window plus refund timelock with capital wedged. -2. **After Bob locks XMR (step 2, before step 3).** Alice holds the free option. If the price has moved against her, she does not publish the adaptor signature. Both legs refund at timeout. Alice's downside: time. Bob's downside: capital wedged for the longer refund window. -3. **After secret reveal (step 3 onward).** No party holds an option; the swap completes deterministically. - -This is the **free-option problem** of atomic swaps. It is not a bug in any particular implementation; it is the cost of atomicity itself. Cited in the literature as the structural reason atomic-swap volume has remained small despite working implementations. Source: [Han et al., On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) (accessed 2026-05-21). +1. **After Alice locks BTC (step 1, before step 2).** Bob holds the free option. + If XMR price has moved against him since the quote, he simply does not lock + XMR. Alice's BTC refunds at timeout. Bob's downside: time. Alice's downside: + lock window plus refund timelock with capital wedged. +2. **After Bob locks XMR (step 2, before step 3).** Alice holds the free option. + If the price has moved against her, she does not publish the adaptor + signature. Both legs refund at timeout. Alice's downside: time. Bob's + downside: capital wedged for the longer refund window. +3. **After secret reveal (step 3 onward).** No party holds an option; the swap + completes deterministically. + +This is the **free-option problem** of atomic swaps. It is not a bug in any +particular implementation; it is the cost of atomicity itself. Cited in the +literature as the structural reason atomic-swap volume has remained small +despite working implementations. Source: +[Han et al., On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) +(accessed 2026-05-21). ### Notation for option value @@ -104,35 +191,67 @@ The expected value of a free option held over a timelock window scales as: where: - `σ` = annualised volatility of the price ratio between the two swap legs; -- `T` = duration of the timelock window (the period over which the option holder can observe and decide); +- `T` = duration of the timelock window (the period over which the option holder + can observe and decide); - `notional` = size of the locked leg. -This is a Black-Scholes-style approximation, valid for small `T` and continuous-time random-walk price dynamics. It is the standard way to size a bond, premium, or cap intended to neutralise the free option a counterparty holds during a lock window. +This is a Black-Scholes-style approximation, valid for small `T` and +continuous-time random-walk price dynamics. It is the standard way to size a +bond, premium, or cap intended to neutralise the free option a counterparty +holds during a lock window. ## Generalising the locks-first rule across pairs -The lock-ordering constraint is a property of the cryptographic construction, not of the specific BTC-XMR pair. In any adaptor-signature swap, the **script-bearing side** (the chain that hosts the adaptor signature whose broadcast reveals the secret scalar) must lock first. The non-script side, where the swap output is a joint-key construction that the secret unlocks, locks second. +The lock-ordering constraint is a property of the cryptographic construction, +not of the specific BTC-XMR pair. In any adaptor-signature swap, the +**script-bearing side** (the chain that hosts the adaptor signature whose +broadcast reveals the secret scalar) must lock first. The non-script side, where +the swap output is a joint-key construction that the secret unlocks, locks +second. -For HTLC swaps, the analogous constraint is that the chain whose HTLC reveals the preimage on claim must be locked first; the chain whose HTLC consumes the same preimage on its claim path then settles second. In practice for symmetric-script pairs (e.g. BTC-LTC) the ordering is conventional rather than forced, since both chains can play either role. +For HTLC swaps, the analogous constraint is that the chain whose HTLC reveals +the preimage on claim must be locked first; the chain whose HTLC consumes the +same preimage on its claim path then settles second. In practice for +symmetric-script pairs (e.g. BTC-LTC) the ordering is conventional rather than +forced, since both chains can play either role. -For XMR paired with any other chain, XMR is always the non-script side. The script-bearing partner locks first. +For XMR paired with any other chain, XMR is always the non-script side. The +script-bearing partner locks first. ## What atomic swaps do not provide -- **Counterparty availability.** Both parties must be online to lock, reveal, and (on adversarial paths) submit refund transactions. If one party goes offline mid-swap, the other waits out the refund window. -- **Per-trade matching.** No protocol-owned liquidity; each swap requires a willing counterparty for the exact pair and size. -- **Pair coverage by default.** HTLC required compatible scripting on both chains; adaptor signatures generalise this but each pair still needs cross-curve cryptographic work (BTC-XMR required ~4 years from proposal to working implementation). -- **Settlement speed.** End-to-end time is dominated by the slowest chain's confirmation depth plus the timelock window. - -These are intrinsic limits of the primitive, not deficiencies of any particular implementation. Deployed protocols address them with off-protocol layers (intent gossip for liveness, market-making conventions for matching) or accept them as user-facing constraints. +- **Counterparty availability.** Both parties must be online to lock, reveal, + and (on adversarial paths) submit refund transactions. If one party goes + offline mid-swap, the other waits out the refund window. +- **Per-trade matching.** No protocol-owned liquidity; each swap requires a + willing counterparty for the exact pair and size. +- **Pair coverage by default.** HTLC required compatible scripting on both + chains; adaptor signatures generalise this but each pair still needs + cross-curve cryptographic work (BTC-XMR required ~4 years from proposal to + working implementation). +- **Settlement speed.** End-to-end time is dominated by the slowest chain's + confirmation depth plus the timelock window. + +These are intrinsic limits of the primitive, not deficiencies of any particular +implementation. Deployed protocols address them with off-protocol layers (intent +gossip for liveness, market-making conventions for matching) or accept them as +user-facing constraints. ## References -- [Decred blog, On-Chain Atomic Swaps (2017-09-20, first on-chain swap, Decred-Litecoin)](https://blog.decred.org/2017/09/20/On-Chain-Atomic-Swaps/) (accessed 2026-05-21) -- [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) (accessed 2026-05-21) -- [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332 (2021-01-29)](https://arxiv.org/abs/2101.12332) (accessed 2026-05-21) -- [getmonero.org: Bitcoin to Monero atomic swaps are now live (2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) (accessed 2026-05-21) -- [Han et al., On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) (accessed 2026-05-21) -- [comit-network/xmr-btc-swap (unmaintained since 2024-11; archival pending)](https://github.com/comit-network/xmr-btc-swap) (accessed 2026-05-21) -- [eigenwallet/core (active fork of xmr-btc-swap; v4.6.1, 2026-05-15)](https://github.com/eigenwallet/core) (accessed 2026-05-21) -- [farcaster-project/farcaster-node (independent XMR-BTC implementation; last release v0.8.4, 2023-01-16)](https://github.com/farcaster-project/farcaster-node) (accessed 2026-05-21) +- [Decred blog, On-Chain Atomic Swaps (2017-09-20, first on-chain swap, Decred-Litecoin)](https://blog.decred.org/2017/09/20/On-Chain-Atomic-Swaps/) + (accessed 2026-05-21) +- [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) + (accessed 2026-05-21) +- [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332 (2021-01-29)](https://arxiv.org/abs/2101.12332) + (accessed 2026-05-21) +- [getmonero.org: Bitcoin to Monero atomic swaps are now live (2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) + (accessed 2026-05-21) +- [Han et al., On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) + (accessed 2026-05-21) +- [comit-network/xmr-btc-swap (unmaintained since 2024-11; archival pending)](https://github.com/comit-network/xmr-btc-swap) + (accessed 2026-05-21) +- [eigenwallet/core (active fork of xmr-btc-swap; v4.6.1, 2026-05-15)](https://github.com/eigenwallet/core) + (accessed 2026-05-21) +- [farcaster-project/farcaster-node (independent XMR-BTC implementation; last release v0.8.4, 2023-01-16)](https://github.com/farcaster-project/farcaster-node) + (accessed 2026-05-21) diff --git a/appendix/cross-chain-trust-model-contrast.md b/appendix/cross-chain-trust-model-contrast.md index ff3bf56..b290602 100644 --- a/appendix/cross-chain-trust-model-contrast.md +++ b/appendix/cross-chain-trust-model-contrast.md @@ -1,74 +1,201 @@ # Cross-Chain Trust Model Contrast -Survey appendix on the two architectural camps that deployed cross-chain swap protocols fall into, the trust assumptions each camp asks of users, and the adoption record of each. Pure survey of deployed and pre-mainnet protocols; no design choices made here. +Survey appendix on the two architectural camps that deployed cross-chain swap +protocols fall into, the trust assumptions each camp asks of users, and the +adoption record of each. Pure survey of deployed and pre-mainnet protocols; no +design choices made here. -For the underlying cryptographic mechanics of atomic swaps see the [atomic-swaps primer](./atomic-swaps-primer.md). +For the underlying cryptographic mechanics of atomic swaps see the +[atomic-swaps primer](./atomic-swaps-primer.md). ## Two architectural camps -Every deployed cross-chain swap design today collapses to one of two trust models: a federated-signer middle chain that custodies external assets, or a peer-to-peer atomic swap that custodies nothing. +Every deployed cross-chain swap design today collapses to one of two trust +models: a federated-signer middle chain that custodies external assets, or a +peer-to-peer atomic swap that custodies nothing. ### Federated-signer middle chain -A purpose-built chain whose validator set custodies external assets via a threshold signature scheme and runs swap matching natively. +A purpose-built chain whose validator set custodies external assets via a +threshold signature scheme and runs swap matching natively. Representative protocols: -- **Thorchain.** Cosmos SDK / CometBFT L1 launched 2021. Validators run an off-chain observer-signer daemon (Bifrost) and co-sign outbound transactions from per-asset TSS vaults using a GG20 ECDSA scheme (fork of Binance `tss-lib` upgraded from GG18 to GG20). Native swap matching via slip-based continuous liquidity pools (CLPs) with RUNE as universal pairing asset. ~103 active nodes (cap 120), minimum bond 400,020 RUNE per node. Sources: [DefiLlama Thorchain DEX dashboard](https://defillama.com/protocol/thorchain-dex) (accessed 2026-05-19); [State of the Network Feb 2026](https://blog.thorchain.org/state-of-the-network-february-2026/) (accessed 2026-05-19); [Thorchain Bifrost TSS docs](https://dev.thorchain.org/bifrost/tss.html) (accessed 2026-05-19). -- **Serai.** Substrate-based L1, pre-mainnet as of 2026-05 (Substrate blockchain audit complete 2026-04-15, internal testnet pending). Validator set forms per-coin threshold multisigs using FROST (per-curve, including FROSTLASS over CLSAG for Monero). Native AMM with constant-product pools. Validator cap 600 at launch, staking per-network. Sources: [serai.exchange](https://serai.exchange/) (accessed 2026-05-19); [Audit of Serai's Substrate Blockchain (2026-04-15)](https://serai.exchange/2026/04/15/serai-blockchain-audited.html) (accessed 2026-05-19); [Announcing monero-oxide (2025-09-09)](https://serai.exchange/2025/09/09/monero-serai-oxide.html) (accessed 2026-05-19). -- **Maya, Chainflip.** Cousin protocols of Thorchain, same architectural pattern. -- **Wormhole.** Distinct sub-pattern: not a swap chain but a guardian-attestation messaging protocol. 19 guardian operators sign 13-of-19 multisignature attestations (Verifiable Action Approvals) to relay messages across ~40 connected chains. Token movement uses lock-and-mint or burn-and-mint; cross-asset swaps happen on destination-chain DEXes or solver networks rather than inside Wormhole. Same trust shape (committee of known signers) but no protocol-owned liquidity, no native middle chain. Source: [Wormhole Guardians docs](https://wormhole.com/docs/protocol/infrastructure/guardians/) (accessed 2026-05-19). +- **Thorchain.** Cosmos SDK / CometBFT L1 launched 2021. Validators run an + off-chain observer-signer daemon (Bifrost) and co-sign outbound transactions + from per-asset TSS vaults using a GG20 ECDSA scheme (fork of Binance `tss-lib` + upgraded from GG18 to GG20). Native swap matching via slip-based continuous + liquidity pools (CLPs) with RUNE as universal pairing asset. ~103 active nodes + (cap 120), minimum bond 400,020 RUNE per node. Sources: + [DefiLlama Thorchain DEX dashboard](https://defillama.com/protocol/thorchain-dex) + (accessed 2026-05-19); + [State of the Network Feb 2026](https://blog.thorchain.org/state-of-the-network-february-2026/) + (accessed 2026-05-19); + [Thorchain Bifrost TSS docs](https://dev.thorchain.org/bifrost/tss.html) + (accessed 2026-05-19). +- **Serai.** Substrate-based L1, pre-mainnet as of 2026-05 (Substrate blockchain + audit complete 2026-04-15, internal testnet pending). Validator set forms + per-coin threshold multisigs using FROST (per-curve, including FROSTLASS over + CLSAG for Monero). Native AMM with constant-product pools. Validator cap 600 + at launch, staking per-network. Sources: + [serai.exchange](https://serai.exchange/) (accessed 2026-05-19); + [Audit of Serai's Substrate Blockchain (2026-04-15)](https://serai.exchange/2026/04/15/serai-blockchain-audited.html) + (accessed 2026-05-19); + [Announcing monero-oxide (2025-09-09)](https://serai.exchange/2025/09/09/monero-serai-oxide.html) + (accessed 2026-05-19). +- **Maya, Chainflip.** Cousin protocols of Thorchain, same architectural + pattern. +- **Wormhole.** Distinct sub-pattern: not a swap chain but a + guardian-attestation messaging protocol. 19 guardian operators sign 13-of-19 + multisignature attestations (Verifiable Action Approvals) to relay messages + across ~40 connected chains. Token movement uses lock-and-mint or + burn-and-mint; cross-asset swaps happen on destination-chain DEXes or solver + networks rather than inside Wormhole. Same trust shape (committee of known + signers) but no protocol-owned liquidity, no native middle chain. Source: + [Wormhole Guardians docs](https://wormhole.com/docs/protocol/infrastructure/guardians/) + (accessed 2026-05-19). What the user trusts: -1. A threshold of the validator set will not collude to spend from the vault. The economic backstop in Thorchain is a 2:1 invariant (bonded RUNE should exceed twice the pooled liquidity); see [Thorchain economic model](https://docs.thorchain.org/technical-documentation/technical-deep-dive/economic-model.md). -2. The cryptographic primitive used to combine signer contributions is sound. Not a free assumption. On 2026-05-15 a GG20 weakness (TSSHOCK-class: malformed proofs allowing key reconstruction by a colluding signer over many rounds) drained approximately $10.8M from a Thorchain Asgard vault. Sources: [Crypto Times, 2026-05-17](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) (accessed 2026-05-19); [AMBCrypto](https://ambcrypto.com/thorchain-exploit-raises-fresh-concerns-over-mpc-wallet-security/) (accessed 2026-05-19). -3. The signer-to-chain integration is correct. The 2021 Thorchain ETH router exploits (two incidents, combined ~$16M) were not TSS failures: the Bifrost interface trusted smart-contract emitted events from a wrapping attacker contract, so the TSS layer functioned as designed while signing transactions that drained the vault. Source: [Thorchain post-mortem](https://medium.com/thorchain/post-mortem-eth-router-exploits-1-2-and-premature-return-to-trading-incident-2908928c5fb) (accessed 2026-05-19). -4. Implementations on every external chain are correct. The 2022-02-02 Wormhole Solana-side `load_instruction_at` bug let an attacker forge a VAA and mint 120k wETH unbacked ($326M). Source: [Halborn: Wormhole Hack February 2022](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) (accessed 2026-05-19). - -For Monero specifically: any threshold-signer custody of XMR is necessarily view-key-shared. Serai's FROSTLASS over CLSAG is the most advanced production-grade design but the validator set still observes which Monero outputs are committed to the swap. The privacy property is "honest-but-curious validators learn the protocol-side deposit history", not "validators learn nothing". +1. A threshold of the validator set will not collude to spend from the vault. + The economic backstop in Thorchain is a 2:1 invariant (bonded RUNE should + exceed twice the pooled liquidity); see + [Thorchain economic model](https://docs.thorchain.org/technical-documentation/technical-deep-dive/economic-model.md). +2. The cryptographic primitive used to combine signer contributions is sound. + Not a free assumption. On 2026-05-15 a GG20 weakness (TSSHOCK-class: + malformed proofs allowing key reconstruction by a colluding signer over many + rounds) drained approximately $10.8M from a Thorchain Asgard vault. Sources: + [Crypto Times, 2026-05-17](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) + (accessed 2026-05-19); + [AMBCrypto](https://ambcrypto.com/thorchain-exploit-raises-fresh-concerns-over-mpc-wallet-security/) + (accessed 2026-05-19). +3. The signer-to-chain integration is correct. The 2021 Thorchain ETH router + exploits (two incidents, combined ~$16M) were not TSS failures: the Bifrost + interface trusted smart-contract emitted events from a wrapping attacker + contract, so the TSS layer functioned as designed while signing transactions + that drained the vault. Source: + [Thorchain post-mortem](https://medium.com/thorchain/post-mortem-eth-router-exploits-1-2-and-premature-return-to-trading-incident-2908928c5fb) + (accessed 2026-05-19). +4. Implementations on every external chain are correct. The 2022-02-02 Wormhole + Solana-side `load_instruction_at` bug let an attacker forge a VAA and mint + 120k wETH unbacked ($326M). Source: + [Halborn: Wormhole Hack February 2022](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) + (accessed 2026-05-19). + +For Monero specifically: any threshold-signer custody of XMR is necessarily +view-key-shared. Serai's FROSTLASS over CLSAG is the most advanced +production-grade design but the validator set still observes which Monero +outputs are committed to the swap. The privacy property is "honest-but-curious +validators learn the protocol-side deposit history", not "validators learn +nothing". Pros of the federated-signer pattern: -- AMM-style liquidity. A single ordered state machine maintains pool invariants and serves all-comers without per-trade matching. -- One-step user experience: deposit with memo, await outbound. No counterparty interactivity, no refund flows, no online-availability requirement past broadcast. -- Sub-block-time settlement on the middle chain; only destination-chain finality and the TSS keysign delay the outbound. +- AMM-style liquidity. A single ordered state machine maintains pool invariants + and serves all-comers without per-trade matching. +- One-step user experience: deposit with memo, await outbound. No counterparty + interactivity, no refund flows, no online-availability requirement past + broadcast. +- Sub-block-time settlement on the middle chain; only destination-chain finality + and the TSS keysign delay the outbound. - Arbitrary asset pairs at protocol-set pricing. -- Cryptoeconomic recourse: misbehaviour is slashable. Thorchain operates at a documented bond-to-pooled ratio; Serai caps custody at 33% of allocated validator stake per network. Sources: [Thorchain RUNE docs](https://docs.thorchain.org/understanding-thorchain/rune) (accessed 2026-05-19); [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md) (accessed 2026-05-19). +- Cryptoeconomic recourse: misbehaviour is slashable. Thorchain operates at a + documented bond-to-pooled ratio; Serai caps custody at 33% of allocated + validator stake per network. Sources: + [Thorchain RUNE docs](https://docs.thorchain.org/understanding-thorchain/rune) + (accessed 2026-05-19); + [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md) + (accessed 2026-05-19). Cons of the federated-signer pattern: - Custody risk is real and realised (see incidents above). -- The signer federation is a chokepoint for censorship and out-of-protocol pressure on individually identifiable validators. -- Pre-economic-security bootstrap. Bonded-security guarantees do not bind until the validator stake pool catches up with custody. This is the structural reason Serai is pre-launch despite a complete audit. -- Public middle-chain state links source and destination identities on the comparator chains. +- The signer federation is a chokepoint for censorship and out-of-protocol + pressure on individually identifiable validators. +- Pre-economic-security bootstrap. Bonded-security guarantees do not bind until + the validator stake pool catches up with custody. This is the structural + reason Serai is pre-launch despite a complete audit. +- Public middle-chain state links source and destination identities on the + comparator chains. ### Atomic swap -A two-party exchange where atomicity comes from cryptography (HTLC or adaptor signatures) rather than a third party. See the [atomic-swaps primer](./atomic-swaps-primer.md) for mechanics. +A two-party exchange where atomicity comes from cryptography (HTLC or adaptor +signatures) rather than a third party. See the +[atomic-swaps primer](./atomic-swaps-primer.md) for mechanics. Representative protocols (XMR-BTC corridor specifically): -- **COMIT Network** (`comit-network/xmr-btc-swap`). Original Rust reference implementation of BTC-XMR adaptor-signature swaps. Reference implementation `comit-rs` archived 2021-03; `xmr-btc-swap` unmaintained per repo notice, last release v1.0.0-rc.1 on 2024-11-15. Maintenance has migrated to community-led `eigenwallet/core`. Source: [github.com/comit-network/xmr-btc-swap](https://github.com/comit-network/xmr-btc-swap) (accessed 2026-05-19). -- **Farcaster Project** (`farcaster-project/farcaster-node`). Independent BTC-XMR implementation. Still listed as actively maintained as of 2026, with Lightning BTC support added to reduce BTC-side confirmation time. Community-scale rather than volume-scale operation. Sources: [xgram.io: Best Monero atomic swap platforms 2026](https://xgram.io/blog/best-xmr-atomic-swaps-and-community-services-2026) (accessed 2026-05-19); [github.com/farcaster-project](https://github.com/farcaster-project) (accessed 2026-05-19). -- **AtomicDEX / Komodo Wallet.** Rebranded to "Komodo Wallet" in 2025. Public trackers report no recent volume: BitDegree's listing notes "no data available for AtomicDEX because of exchange inactivity"; Nomics' last published 24-hour volume is approximately USD 5,737 from November 2021. Not wound down, but has not produced competitive volumes. Sources: [Komodo Platform Roadmap](https://roadmap.komodoplatform.com/) (accessed 2026-05-19); [BitDegree: AtomicDEX trading data](https://www.bitdegree.org/top-crypto-exchanges/atomicdex) (accessed 2026-05-19); [Nomics: AtomicDEX](https://nomics.com/exchanges/atomicdex) (accessed 2026-05-19). -- **Liquality.** Consumer atomic-swap wallet extension discontinued effective 2024-06-15. Company pivoted to in-app wallet and SDK products. Sources: [Liquality on X, 2024-05-20](https://x.com/Liquality_io/status/1792678368694985162) (accessed 2026-05-19); [Rootstock Helpdesk: Liquality](https://helpdesk.rootstock.io/solutions/liquality.html) (accessed 2026-05-19). - -What the user trusts: nothing beyond the soundness of the cryptographic construction and the liveness of the two parties for the duration of the swap. +- **COMIT Network** (`comit-network/xmr-btc-swap`). Original Rust reference + implementation of BTC-XMR adaptor-signature swaps. Reference implementation + `comit-rs` archived 2021-03; `xmr-btc-swap` unmaintained per repo notice, last + release v1.0.0-rc.1 on 2024-11-15. Maintenance has migrated to community-led + `eigenwallet/core`. Source: + [github.com/comit-network/xmr-btc-swap](https://github.com/comit-network/xmr-btc-swap) + (accessed 2026-05-19). +- **Farcaster Project** (`farcaster-project/farcaster-node`). Independent + BTC-XMR implementation. Still listed as actively maintained as of 2026, with + Lightning BTC support added to reduce BTC-side confirmation time. + Community-scale rather than volume-scale operation. Sources: + [xgram.io: Best Monero atomic swap platforms 2026](https://xgram.io/blog/best-xmr-atomic-swaps-and-community-services-2026) + (accessed 2026-05-19); + [github.com/farcaster-project](https://github.com/farcaster-project) (accessed + 2026-05-19). +- **AtomicDEX / Komodo Wallet.** Rebranded to "Komodo Wallet" in 2025. Public + trackers report no recent volume: BitDegree's listing notes "no data available + for AtomicDEX because of exchange inactivity"; Nomics' last published 24-hour + volume is approximately USD 5,737 from November 2021. Not wound down, but has + not produced competitive volumes. Sources: + [Komodo Platform Roadmap](https://roadmap.komodoplatform.com/) (accessed + 2026-05-19); + [BitDegree: AtomicDEX trading data](https://www.bitdegree.org/top-crypto-exchanges/atomicdex) + (accessed 2026-05-19); + [Nomics: AtomicDEX](https://nomics.com/exchanges/atomicdex) (accessed + 2026-05-19). +- **Liquality.** Consumer atomic-swap wallet extension discontinued effective + 2024-06-15. Company pivoted to in-app wallet and SDK products. Sources: + [Liquality on X, 2024-05-20](https://x.com/Liquality_io/status/1792678368694985162) + (accessed 2026-05-19); + [Rootstock Helpdesk: Liquality](https://helpdesk.rootstock.io/solutions/liquality.html) + (accessed 2026-05-19). + +What the user trusts: nothing beyond the soundness of the cryptographic +construction and the liveness of the two parties for the duration of the swap. Pros: -- No custody risk. Funds never leave control of one of the two participants. No validator set to slash, no vault to drain. -- No signer federation: no n-of-m threshold to compromise, no per-chain observer to censor. -- No pre-economic-security window. Cryptographic security is full from day one because there is no bond-to-custody ratio to bootstrap. +- No custody risk. Funds never leave control of one of the two participants. No + validator set to slash, no vault to drain. +- No signer federation: no n-of-m threshold to compromise, no per-chain observer + to censor. +- No pre-economic-security window. Cryptographic security is full from day one + because there is no bond-to-custody ratio to bootstrap. Cons (intrinsic to atomicity, not implementation defects): -1. **Free option on both sides.** Once one party has locked, the other can wait and observe price movement before completing or walking away. See the [free-option section in the primer](./atomic-swaps-primer.md#the-free-option-problem) and [Han et al., IACR 2019/896](https://eprint.iacr.org/2019/896) (accessed 2026-05-19) for the literature reference. -2. **Settlement time dominated by the slowest chain.** Confirmations stack across both chains. Third-party documentation of atomic-swap practice notes that "a single swap can take 30 minutes to several hours to finalise". Source: [xgram.io: Best Monero atomic swap platforms 2026](https://xgram.io/blog/best-xmr-atomic-swaps-and-community-services-2026) (accessed 2026-05-19). -3. **Mandatory interactivity for both parties.** Both must be online for lock, reveal, and (in adversarial paths) refund. -4. **Per-trade matching.** No protocol-owned liquidity. Each swap requires a willing counterparty for the exact pair and size. Third-party summary: "you cannot easily swap large amounts because you need to find a specific peer willing to take the other side of that exact trade" ([xgram.io, 2026](https://xgram.io/blog/best-xmr-atomic-swaps-and-community-services-2026), accessed 2026-05-19). -5. **Pair coverage.** HTLC requires compatible scripting; adaptor signatures generalise this but each new pair requires cross-curve cryptographic work. BTC-XMR specifically took years of work between first published research and production implementation; see the primer for sourcing. +1. **Free option on both sides.** Once one party has locked, the other can wait + and observe price movement before completing or walking away. See the + [free-option section in the primer](./atomic-swaps-primer.md#the-free-option-problem) + and [Han et al., IACR 2019/896](https://eprint.iacr.org/2019/896) (accessed + 2026-05-19) for the literature reference. +2. **Settlement time dominated by the slowest chain.** Confirmations stack + across both chains. Third-party documentation of atomic-swap practice notes + that "a single swap can take 30 minutes to several hours to finalise". + Source: + [xgram.io: Best Monero atomic swap platforms 2026](https://xgram.io/blog/best-xmr-atomic-swaps-and-community-services-2026) + (accessed 2026-05-19). +3. **Mandatory interactivity for both parties.** Both must be online for lock, + reveal, and (in adversarial paths) refund. +4. **Per-trade matching.** No protocol-owned liquidity. Each swap requires a + willing counterparty for the exact pair and size. Third-party summary: "you + cannot easily swap large amounts because you need to find a specific peer + willing to take the other side of that exact trade" + ([xgram.io, 2026](https://xgram.io/blog/best-xmr-atomic-swaps-and-community-services-2026), + accessed 2026-05-19). +5. **Pair coverage.** HTLC requires compatible scripting; adaptor signatures + generalise this but each new pair requires cross-curve cryptographic work. + BTC-XMR specifically took years of work between first published research and + production implementation; see the primer for sourcing. ## Adoption record @@ -76,51 +203,107 @@ The two camps have produced very different volume outcomes. Federated-signer middle chains: -- **Thorchain cumulative swap volume** $112.201B as of 2026-05-19 (DefiLlama). 30-day volume $1.632B; annualised fees $29.76M; current TVL $70.24M. Source: [DefiLlama Thorchain DEX dashboard](https://defillama.com/protocol/thorchain-dex) (accessed 2026-05-19). -- **Wormhole cumulative transfer volume** $58.95B all-time (claimed); Portal Bridge DefiLlama figure $58.19B; 30-day volume $1.169B. Sources: [Connecting the Internet Economy (Wormhole blog, 2025-04-03)](https://wormhole.com/blog/connecting-the-internet-economy-wormhole-and-the-w-tokens-past-present-and) (accessed 2026-05-19); [Portal TVL on DefiLlama](https://defillama.com/protocol/portal) (accessed 2026-05-19). +- **Thorchain cumulative swap volume** $112.201B as of 2026-05-19 (DefiLlama). + 30-day volume $1.632B; annualised fees $29.76M; current TVL $70.24M. Source: + [DefiLlama Thorchain DEX dashboard](https://defillama.com/protocol/thorchain-dex) + (accessed 2026-05-19). +- **Wormhole cumulative transfer volume** $58.95B all-time (claimed); Portal + Bridge DefiLlama figure $58.19B; 30-day volume $1.169B. Sources: + [Connecting the Internet Economy (Wormhole blog, 2025-04-03)](https://wormhole.com/blog/connecting-the-internet-economy-wormhole-and-the-w-tokens-past-present-and) + (accessed 2026-05-19); + [Portal TVL on DefiLlama](https://defillama.com/protocol/portal) (accessed + 2026-05-19). Atomic-swap protocols: -- **Liquality** reported "$35M in cross-chain atomic swaps facilitated through its wallet and interface" lifetime. Source: [defiprime.com: Liquality](https://defiprime.com/liquality) (accessed 2026-05-19). -- COMIT, Farcaster, AtomicDEX: no comparable cumulative-volume figure published. Recent activity in all three is community-scale rather than volume-scale. +- **Liquality** reported "$35M in cross-chain atomic swaps facilitated through + its wallet and interface" lifetime. Source: + [defiprime.com: Liquality](https://defiprime.com/liquality) (accessed + 2026-05-19). +- COMIT, Farcaster, AtomicDEX: no comparable cumulative-volume figure published. + Recent activity in all three is community-scale rather than volume-scale. -The gap is four orders of magnitude on cumulative volume in the published evidence. +The gap is four orders of magnitude on cumulative volume in the published +evidence. ### Stated rationale from the projects themselves -The Thorchain account published a 2019-07-02 Medium post arguing that "bridges are superior to atomic swaps", citing liquidity gravity (peer-to-peer matching requires a counterparty per trade), user experience (multi-hour timelocks and CLI tooling), and pair coverage. Source: [Thorchain Medium, "Why Cross-Chain bridges are superior to Atomic Swaps" (2019-07-02)](https://medium.com/thorchain/why-cross-chain-bridges-are-superior-to-atomic-swaps-aebde263103c) (accessed 2026-05-19). - -Luke Parker (Serai lead developer) said directly in a MoneroTalk interview: "while I do love atomic swaps [..] I don't feel the community actually wants atomic swaps, which is a brutal truth" (timestamp 35:50). Parker explicitly groups Serai with Thorchain, Maya, and Chainflip rather than with Farcaster or COMIT. Source: [Monero Observer: MoneroTalk interview with kayabaNerve on Serai DEX](https://monero.observer/monerotalk-kayabanerve-interview-serai-dex/) (accessed 2026-05-19). - -The COMIT design corpus (RFC series, 25+ ADR-style spike documents, public blog) makes no mention of staking, reputation, or counterparty accountability mechanisms; the project relied entirely on timelock refund paths and adaptor-signature secrecy. Source: [comit-network/spikes/0017-negotiation-and-execution-protocol.adoc](https://github.com/comit-network/spikes/blob/master/0017-negotiation-and-execution-protocol.adoc) (accessed 2026-05-20). +The Thorchain account published a 2019-07-02 Medium post arguing that "bridges +are superior to atomic swaps", citing liquidity gravity (peer-to-peer matching +requires a counterparty per trade), user experience (multi-hour timelocks and +CLI tooling), and pair coverage. Source: +[Thorchain Medium, "Why Cross-Chain bridges are superior to Atomic Swaps" (2019-07-02)](https://medium.com/thorchain/why-cross-chain-bridges-are-superior-to-atomic-swaps-aebde263103c) +(accessed 2026-05-19). + +Luke Parker (Serai lead developer) said directly in a MoneroTalk interview: +"while I do love atomic swaps [..] I don't feel the community actually wants +atomic swaps, which is a brutal truth" (timestamp 35:50). Parker explicitly +groups Serai with Thorchain, Maya, and Chainflip rather than with Farcaster or +COMIT. Source: +[Monero Observer: MoneroTalk interview with kayabaNerve on Serai DEX](https://monero.observer/monerotalk-kayabanerve-interview-serai-dex/) +(accessed 2026-05-19). + +The COMIT design corpus (RFC series, 25+ ADR-style spike documents, public blog) +makes no mention of staking, reputation, or counterparty accountability +mechanisms; the project relied entirely on timelock refund paths and +adaptor-signature secrecy. Source: +[comit-network/spikes/0017-negotiation-and-execution-protocol.adoc](https://github.com/comit-network/spikes/blob/master/0017-negotiation-and-execution-protocol.adoc) +(accessed 2026-05-20). ## References -- [Thorchain DEX dashboard, DefiLlama](https://defillama.com/protocol/thorchain-dex) (accessed 2026-05-19) -- [Thorchain State of the Network February 2026](https://blog.thorchain.org/state-of-the-network-february-2026/) (accessed 2026-05-19) -- [Thorchain Bifrost TSS docs](https://dev.thorchain.org/bifrost/tss.html) (accessed 2026-05-19) -- [Thorchain RUNE bond-to-pooled docs](https://docs.thorchain.org/understanding-thorchain/rune) (accessed 2026-05-19) -- [Thorchain post-mortem: 2021 ETH router exploits](https://medium.com/thorchain/post-mortem-eth-router-exploits-1-2-and-premature-return-to-trading-incident-2908928c5fb) (accessed 2026-05-19) -- [Thorchain Medium: "Why Cross-Chain bridges are superior to Atomic Swaps" (2019-07-02)](https://medium.com/thorchain/why-cross-chain-bridges-are-superior-to-atomic-swaps-aebde263103c) (accessed 2026-05-19) -- [Crypto Times: $10.8M Thorchain GG20/TSSHOCK exploit (2026-05-17)](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) (accessed 2026-05-19) -- [AMBCrypto: Thorchain MPC wallet concerns](https://ambcrypto.com/thorchain-exploit-raises-fresh-concerns-over-mpc-wallet-security/) (accessed 2026-05-19) +- [Thorchain DEX dashboard, DefiLlama](https://defillama.com/protocol/thorchain-dex) + (accessed 2026-05-19) +- [Thorchain State of the Network February 2026](https://blog.thorchain.org/state-of-the-network-february-2026/) + (accessed 2026-05-19) +- [Thorchain Bifrost TSS docs](https://dev.thorchain.org/bifrost/tss.html) + (accessed 2026-05-19) +- [Thorchain RUNE bond-to-pooled docs](https://docs.thorchain.org/understanding-thorchain/rune) + (accessed 2026-05-19) +- [Thorchain post-mortem: 2021 ETH router exploits](https://medium.com/thorchain/post-mortem-eth-router-exploits-1-2-and-premature-return-to-trading-incident-2908928c5fb) + (accessed 2026-05-19) +- [Thorchain Medium: "Why Cross-Chain bridges are superior to Atomic Swaps" (2019-07-02)](https://medium.com/thorchain/why-cross-chain-bridges-are-superior-to-atomic-swaps-aebde263103c) + (accessed 2026-05-19) +- [Crypto Times: $10.8M Thorchain GG20/TSSHOCK exploit (2026-05-17)](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) + (accessed 2026-05-19) +- [AMBCrypto: Thorchain MPC wallet concerns](https://ambcrypto.com/thorchain-exploit-raises-fresh-concerns-over-mpc-wallet-security/) + (accessed 2026-05-19) - [serai.exchange](https://serai.exchange/) (accessed 2026-05-19) -- [Audit of Serai's Substrate Blockchain (2026-04-15)](https://serai.exchange/2026/04/15/serai-blockchain-audited.html) (accessed 2026-05-19) -- [Announcing monero-oxide / FROSTLASS CLSAGs (2025-09-09)](https://serai.exchange/2025/09/09/monero-serai-oxide.html) (accessed 2026-05-19) -- [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md) (accessed 2026-05-19) -- [Monero Observer: MoneroTalk interview with kayabaNerve on Serai DEX](https://monero.observer/monerotalk-kayabanerve-interview-serai-dex/) (accessed 2026-05-19) -- [Wormhole Guardians docs](https://wormhole.com/docs/protocol/infrastructure/guardians/) (accessed 2026-05-19) -- [Portal TVL on DefiLlama](https://defillama.com/protocol/portal) (accessed 2026-05-19) -- [Connecting the Internet Economy (Wormhole, 2025-04-03)](https://wormhole.com/blog/connecting-the-internet-economy-wormhole-and-the-w-tokens-past-present-and) (accessed 2026-05-19) -- [Halborn: Wormhole Hack February 2022](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) (accessed 2026-05-19) -- [Han et al., On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) (accessed 2026-05-19) -- [comit-network/spikes/0017-negotiation-and-execution-protocol.adoc](https://github.com/comit-network/spikes/blob/master/0017-negotiation-and-execution-protocol.adoc) (accessed 2026-05-20) -- [github.com/comit-network/xmr-btc-swap](https://github.com/comit-network/xmr-btc-swap) (accessed 2026-05-19) -- [github.com/farcaster-project](https://github.com/farcaster-project) (accessed 2026-05-19) -- [xgram.io: Best Monero atomic swap platforms 2026](https://xgram.io/blog/best-xmr-atomic-swaps-and-community-services-2026) (accessed 2026-05-19) -- [Komodo Platform Roadmap](https://roadmap.komodoplatform.com/) (accessed 2026-05-19) -- [BitDegree: AtomicDEX trading data](https://www.bitdegree.org/top-crypto-exchanges/atomicdex) (accessed 2026-05-19) -- [Nomics: AtomicDEX](https://nomics.com/exchanges/atomicdex) (accessed 2026-05-19) -- [Liquality on X: discontinuation (2024-05-20)](https://x.com/Liquality_io/status/1792678368694985162) (accessed 2026-05-19) -- [Rootstock Helpdesk: Liquality](https://helpdesk.rootstock.io/solutions/liquality.html) (accessed 2026-05-19) -- [defiprime.com: Liquality cross-chain atomic swaps](https://defiprime.com/liquality) (accessed 2026-05-19) +- [Audit of Serai's Substrate Blockchain (2026-04-15)](https://serai.exchange/2026/04/15/serai-blockchain-audited.html) + (accessed 2026-05-19) +- [Announcing monero-oxide / FROSTLASS CLSAGs (2025-09-09)](https://serai.exchange/2025/09/09/monero-serai-oxide.html) + (accessed 2026-05-19) +- [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md) + (accessed 2026-05-19) +- [Monero Observer: MoneroTalk interview with kayabaNerve on Serai DEX](https://monero.observer/monerotalk-kayabanerve-interview-serai-dex/) + (accessed 2026-05-19) +- [Wormhole Guardians docs](https://wormhole.com/docs/protocol/infrastructure/guardians/) + (accessed 2026-05-19) +- [Portal TVL on DefiLlama](https://defillama.com/protocol/portal) (accessed + 2026-05-19) +- [Connecting the Internet Economy (Wormhole, 2025-04-03)](https://wormhole.com/blog/connecting-the-internet-economy-wormhole-and-the-w-tokens-past-present-and) + (accessed 2026-05-19) +- [Halborn: Wormhole Hack February 2022](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) + (accessed 2026-05-19) +- [Han et al., On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) + (accessed 2026-05-19) +- [comit-network/spikes/0017-negotiation-and-execution-protocol.adoc](https://github.com/comit-network/spikes/blob/master/0017-negotiation-and-execution-protocol.adoc) + (accessed 2026-05-20) +- [github.com/comit-network/xmr-btc-swap](https://github.com/comit-network/xmr-btc-swap) + (accessed 2026-05-19) +- [github.com/farcaster-project](https://github.com/farcaster-project) (accessed + 2026-05-19) +- [xgram.io: Best Monero atomic swap platforms 2026](https://xgram.io/blog/best-xmr-atomic-swaps-and-community-services-2026) + (accessed 2026-05-19) +- [Komodo Platform Roadmap](https://roadmap.komodoplatform.com/) (accessed + 2026-05-19) +- [BitDegree: AtomicDEX trading data](https://www.bitdegree.org/top-crypto-exchanges/atomicdex) + (accessed 2026-05-19) +- [Nomics: AtomicDEX](https://nomics.com/exchanges/atomicdex) (accessed + 2026-05-19) +- [Liquality on X: discontinuation (2024-05-20)](https://x.com/Liquality_io/status/1792678368694985162) + (accessed 2026-05-19) +- [Rootstock Helpdesk: Liquality](https://helpdesk.rootstock.io/solutions/liquality.html) + (accessed 2026-05-19) +- [defiprime.com: Liquality cross-chain atomic swaps](https://defiprime.com/liquality) + (accessed 2026-05-19) diff --git a/appendix/synthetics-design-space.md b/appendix/synthetics-design-space.md index e74454e..365e9c1 100644 --- a/appendix/synthetics-design-space.md +++ b/appendix/synthetics-design-space.md @@ -1,89 +1,198 @@ # Synthetics Design Space -Survey appendix on deployed synthetic-asset designs and what each protocol commits to (and trusts) at the redemption boundary. Pure survey of deployed and historical synthetics; no design choices made here. +Survey appendix on deployed synthetic-asset designs and what each protocol +commits to (and trusts) at the redemption boundary. Pure survey of deployed and +historical synthetics; no design choices made here. -A "synthetic" in this appendix means a token on chain A that tracks the price of an asset on chain B (or an off-chain reference) without being a direct wrapping of that asset. Pure wrapped tokens (one-to-one custody-backed representations) are out of scope. +A "synthetic" in this appendix means a token on chain A that tracks the price of +an asset on chain B (or an off-chain reference) without being a direct wrapping +of that asset. Pure wrapped tokens (one-to-one custody-backed representations) +are out of scope. ## Taxonomy Deployed synthetic designs differ on two axes: -1. **What backs the synthetic.** Stable collateral (over-collateralised CDP), the underlying asset itself (custody-backed), or no backing at all (pure pegged float). -2. **What redemption means.** Convertible to the underlying asset at oracle price, convertible to the collateral at oracle price, or not redeemable but freely tradable. +1. **What backs the synthetic.** Stable collateral (over-collateralised CDP), + the underlying asset itself (custody-backed), or no backing at all (pure + pegged float). +2. **What redemption means.** Convertible to the underlying asset at oracle + price, convertible to the collateral at oracle price, or not redeemable but + freely tradable. The deployed examples populate three corners of this space: ### Oracle-priced over-collateralised synthetics -Synthetics minted against stable collateral, valued by oracle, settled in collateral rather than the tracked asset. - -- **Haven Protocol (XHV / xUSD / other xAssets).** Monero-forked L1 launched 2018. Users lock XHV to mint xAssets at oracle price; conversion between xAssets burns the source and mints the destination. Over-collateralised. xUSD has depegged multiple times (notably 2022-2023) due to low liquidity, oracle delays, and market stress. As of 2026-05-22, XHV market cap is approximately $5.5M and xUSD supply approximately $1.2M; daily transactions approximately 50-100. Sources: [Haven Protocol Documentation](https://docs.havenprotocol.org) (accessed 2026-05-22); [CoinGecko: Haven (XHV)](https://www.coingecko.com/en/coins/haven) (accessed 2026-05-22); [Haven Explorer](https://explorer.havenprotocol.org) (accessed 2026-05-22). Note: prior PR-57 appendix text stated Haven shut down in December 2024; this claim has been flagged for vault verification as it does not match the current explorer/market-cap data above. -- **Synthetix.** SNX stakers mint sUSD and other synthetic equivalents against SNX collateral, debt pooled across all stakers. Used as a reference for "oracle-priced over-collateralised synth" rather than for a specific Monero-relevant property here. Note: prior PR-57 appendix text cited SIP-302 as the canonical reference for V3 collateral and snxUSD minting; this citation has been flagged for vault verification. +Synthetics minted against stable collateral, valued by oracle, settled in +collateral rather than the tracked asset. + +- **Haven Protocol (XHV / xUSD / other xAssets).** Monero-forked L1 launched + 2018\. Users lock XHV to mint xAssets at oracle price; conversion between + xAssets burns the source and mints the destination. Over-collateralised. xUSD + has depegged multiple times (notably 2022-2023) due to low liquidity, oracle + delays, and market stress. As of 2026-05-22, XHV market cap is approximately + $5.5M and xUSD supply approximately $1.2M; daily transactions approximately + 50-100. Sources: + [Haven Protocol Documentation](https://docs.havenprotocol.org) (accessed + 2026-05-22); + [CoinGecko: Haven (XHV)](https://www.coingecko.com/en/coins/haven) (accessed + 2026-05-22); [Haven Explorer](https://explorer.havenprotocol.org) (accessed + 2026-05-22). Note: prior PR-57 appendix text stated Haven shut down in + December 2024; this claim has been flagged for vault verification as it does + not match the current explorer/market-cap data above. +- **Synthetix.** SNX stakers mint sUSD and other synthetic equivalents against + SNX collateral, debt pooled across all stakers. Used as a reference for + "oracle-priced over-collateralised synth" rather than for a specific + Monero-relevant property here. Note: prior PR-57 appendix text cited SIP-302 + as the canonical reference for V3 collateral and snxUSD minting; this citation + has been flagged for vault verification. What you trust in this design family: - The oracle. A compromised oracle is an infinite-mint vulnerability. -- The collateralisation ratio holds under price-of-collateral stress (otherwise the protocol becomes insolvent against outstanding synthetics). +- The collateralisation ratio holds under price-of-collateral stress (otherwise + the protocol becomes insolvent against outstanding synthetics). - The liquidation mechanism executes faster than collateral price collapse. -Privacy properties (Haven specifically): Monero-style ring signatures and stealth addresses protect transfers of xAssets, but Haven has no smart-contract layer, so xAssets cannot be used in DeFi outside Haven itself. +Privacy properties (Haven specifically): Monero-style ring signatures and +stealth addresses protect transfers of xAssets, but Haven has no smart-contract +layer, so xAssets cannot be used in DeFi outside Haven itself. ### Redeem-to-underlying with custody -Synthetics minted against the underlying asset held by a custodial bridge, valued by direct redemption. - -- **sBTC (Stacks).** Synthetic BTC on Stacks, redeemable to native BTC. The custody arrangement (signer set, threshold scheme, redemption SLA) has been flagged for vault verification before specific claims are made here. Canonical docs page: [docs.stacks.co/learn/sbtc](https://docs.stacks.co/learn/sbtc). This claim and its specific trust-shape characterisation have been added to the pending-research request for PR #57. -- **Secret Monero Bridge** (Secret Network). Mainnet launched August 2021. Multi-signature Monero wallet operated by consensus-node signers (MSCNOs) communicating over I2P; users deposit XMR, receive sXMR (a SNIP-20 token on Secret Network) usable in Secret DeFi (e.g. SecretSwap). Source: [Bitcoin Insider: Secret Monero Bridge mainnet launch](https://www.bitcoininsider.org/article/123189/secret-network-announces-launch-secret-monero-bridge-mainnet) (accessed 2026-05-22); [github.com/maxkoda-cpu/Secret-Monero-Bridge](https://github.com/maxkoda-cpu/Secret-Monero-Bridge) (accessed 2026-05-22). +Synthetics minted against the underlying asset held by a custodial bridge, +valued by direct redemption. + +- **sBTC (Stacks).** Synthetic BTC on Stacks, redeemable to native BTC. The + custody arrangement (signer set, threshold scheme, redemption SLA) has been + flagged for vault verification before specific claims are made here. Canonical + docs page: [docs.stacks.co/learn/sbtc](https://docs.stacks.co/learn/sbtc). + This claim and its specific trust-shape characterisation have been added to + the pending-research request for PR #57. +- **Secret Monero Bridge** (Secret Network). Mainnet launched August 2021. + Multi-signature Monero wallet operated by consensus-node signers (MSCNOs) + communicating over I2P; users deposit XMR, receive sXMR (a SNIP-20 token on + Secret Network) usable in Secret DeFi (e.g. SecretSwap). Source: + [Bitcoin Insider: Secret Monero Bridge mainnet launch](https://www.bitcoininsider.org/article/123189/secret-network-announces-launch-secret-monero-bridge-mainnet) + (accessed 2026-05-22); + [github.com/maxkoda-cpu/Secret-Monero-Bridge](https://github.com/maxkoda-cpu/Secret-Monero-Bridge) + (accessed 2026-05-22). What you trust in this design family: - The custodian (signer set, multisig threshold). -- The cryptographic primitive combining signer contributions (TSS, multisig, FROST). -- The off-chain coordination among signers does not produce a censorship chokepoint or collusion path. +- The cryptographic primitive combining signer contributions (TSS, multisig, + FROST). +- The off-chain coordination among signers does not produce a censorship + chokepoint or collusion path. -This trust shape is structurally identical to a federated-signer middle chain (see the [trust-model contrast appendix](./cross-chain-trust-model-contrast.md)); the synthetic-token wrapper is cosmetic relative to the trust assumption. +This trust shape is structurally identical to a federated-signer middle chain +(see the +[trust-model contrast appendix](./cross-chain-trust-model-contrast.md)); the +synthetic-token wrapper is cosmetic relative to the trust assumption. ### Redeem-to-underlying without custody -This design corner has no fully deployed example in the published landscape as of 2026-05. The Secret Monero Bridge above is custodial; the BTC-XMR atomic-swap projects (COMIT, Farcaster) execute peer-to-peer swaps but do not issue a synthetic token at all. A redeem-to-underlying synthetic where redemption itself is peer-to-peer-atomic and the protocol never custodies the underlying is a published design space but not a published implementation. +This design corner has no fully deployed example in the published landscape as +of 2026-05. The Secret Monero Bridge above is custodial; the BTC-XMR atomic-swap +projects (COMIT, Farcaster) execute peer-to-peer swaps but do not issue a +synthetic token at all. A redeem-to-underlying synthetic where redemption itself +is peer-to-peer-atomic and the protocol never custodies the underlying is a +published design space but not a published implementation. ## Privacy-coin specific constraints -Synthetic designs that target Monero (or other privacy coins) inherit constraints from the underlying: - -- **No SPV-style proof of state.** Monero has no proof primitive that can demonstrate "address Y received amount X" to a third party without view-key disclosure. Bilateral proofs (`check_tx_proof` family) exist but lifting them to public on-chain state is equivalent to view-key disclosure for the swap output, which deanonymises the swap. Sources: [Monero, Zero to Monero 2.0 §Payment Proofs](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) (accessed 2026-05-21). -- **Custody-side privacy leak.** Threshold custody of XMR requires view-key sharing among signers. Honest-but-curious signers learn the deposit history of the synthetic-side mint and burn flow. This is a property of any TSS custody of XMR, including the most advanced production design (Serai's FROSTLASS over CLSAG); see the [trust-model contrast appendix](./cross-chain-trust-model-contrast.md). -- **No native smart contracts on Monero.** Designs that want programmability over a Monero-backed synthetic must run that programmability on a separate chain; the synthetic and its DeFi context are necessarily off Monero. -- **Future cryptographic primitives.** The FCMP++ (full-chain membership and metadata-private proofs) research direction may unlock new non-disclosing proof variants; it is pre-production. Source: [Monero, FCMP++ announcement (2024-04-27)](https://www.getmonero.org/2024/04/27/fcmps.html) (accessed 2026-05-21). +Synthetic designs that target Monero (or other privacy coins) inherit +constraints from the underlying: + +- **No SPV-style proof of state.** Monero has no proof primitive that can + demonstrate "address Y received amount X" to a third party without view-key + disclosure. Bilateral proofs (`check_tx_proof` family) exist but lifting them + to public on-chain state is equivalent to view-key disclosure for the swap + output, which deanonymises the swap. Sources: + [Monero, Zero to Monero 2.0 §Payment Proofs](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) + (accessed 2026-05-21). +- **Custody-side privacy leak.** Threshold custody of XMR requires view-key + sharing among signers. Honest-but-curious signers learn the deposit history of + the synthetic-side mint and burn flow. This is a property of any TSS custody + of XMR, including the most advanced production design (Serai's FROSTLASS over + CLSAG); see the + [trust-model contrast appendix](./cross-chain-trust-model-contrast.md). +- **No native smart contracts on Monero.** Designs that want programmability + over a Monero-backed synthetic must run that programmability on a separate + chain; the synthetic and its DeFi context are necessarily off Monero. +- **Future cryptographic primitives.** The FCMP++ (full-chain membership and + metadata-private proofs) research direction may unlock new non-disclosing + proof variants; it is pre-production. Source: + [Monero, FCMP++ announcement (2024-04-27)](https://www.getmonero.org/2024/04/27/fcmps.html) + (accessed 2026-05-21). ## Negative example: Secret Monero Bridge -The Secret Monero Bridge is the closest deployed prior art for bridging XMR into a programmable privacy ecosystem. The documented launch reception is instructive: - -1. **Trusted operator model without economic security.** The bridge used a multi-signature Monero wallet controlled by consensus-node operators. There was no bonded collateral, no slashing, and no cryptographic proof of correctness. Security relied on social trust plus I2P anonymisation of the operator network. Source: [`maxkoda-cpu/Secret-Monero-Bridge`](https://github.com/maxkoda-cpu/Secret-Monero-Bridge) (accessed 2026-05-22). -2. **Privacy-hostile onboarding UX.** The mainnet release required users to provide an email address and use Discord for support tickets; the Monero community viewed this as antithetical to privacy principles and widely refused to use the bridge. Source: vault note `projects/secret-network.md` documents this controversy; the primary documentation is Bitcoin Insider's launch coverage and contemporary Monero-community forum discussions, both available via the cited launch announcement. -3. **Unclear current status.** As of 2025-2026 the GitHub repository has limited recent activity and community forum posts question whether the bridge is still maintained. Source: [`maxkoda-cpu/Secret-Monero-Bridge`](https://github.com/maxkoda-cpu/Secret-Monero-Bridge) (accessed 2026-05-22). - -These are properties of the bridge's design and reception; whether any specific lesson applies to a future synthetic depends on the future synthetic's own choices and is left to the relevant RFPs. +The Secret Monero Bridge is the closest deployed prior art for bridging XMR into +a programmable privacy ecosystem. The documented launch reception is +instructive: + +1. **Trusted operator model without economic security.** The bridge used a + multi-signature Monero wallet controlled by consensus-node operators. There + was no bonded collateral, no slashing, and no cryptographic proof of + correctness. Security relied on social trust plus I2P anonymisation of the + operator network. Source: + [`maxkoda-cpu/Secret-Monero-Bridge`](https://github.com/maxkoda-cpu/Secret-Monero-Bridge) + (accessed 2026-05-22). +2. **Privacy-hostile onboarding UX.** The mainnet release required users to + provide an email address and use Discord for support tickets; the Monero + community viewed this as antithetical to privacy principles and widely + refused to use the bridge. Source: vault note `projects/secret-network.md` + documents this controversy; the primary documentation is Bitcoin Insider's + launch coverage and contemporary Monero-community forum discussions, both + available via the cited launch announcement. +3. **Unclear current status.** As of 2025-2026 the GitHub repository has limited + recent activity and community forum posts question whether the bridge is + still maintained. Source: + [`maxkoda-cpu/Secret-Monero-Bridge`](https://github.com/maxkoda-cpu/Secret-Monero-Bridge) + (accessed 2026-05-22). + +These are properties of the bridge's design and reception; whether any specific +lesson applies to a future synthetic depends on the future synthetic's own +choices and is left to the relevant RFPs. ## How minting works in deployed synthetic protocols Common patterns across the deployed examples: -- **Lock collateral, mint synthetic at oracle price** (Haven xAssets, Synthetix sUSD). The collateral is the protocol's native token (or a basket); the synthetic is valued by oracle at mint. Over-collateralisation absorbs price moves. -- **Deposit underlying, mint synthetic 1:1 minus fees** (Secret Monero Bridge sXMR, sBTC on Stacks). The synthetic is a wrapped representation; mint is custodial, burn unlocks the underlying. -- **No deployed example exists** for a synthetic that mints against stable collateral *and* redeems to the underlying via peer-to-peer atomic swap. This is the design space targeted by the bundle's sXMR RFPs. +- **Lock collateral, mint synthetic at oracle price** (Haven xAssets, Synthetix + sUSD). The collateral is the protocol's native token (or a basket); the + synthetic is valued by oracle at mint. Over-collateralisation absorbs price + moves. +- **Deposit underlying, mint synthetic 1:1 minus fees** (Secret Monero Bridge + sXMR, sBTC on Stacks). The synthetic is a wrapped representation; mint is + custodial, burn unlocks the underlying. +- **No deployed example exists** for a synthetic that mints against stable + collateral *and* redeems to the underlying via peer-to-peer atomic swap. This + is the design space targeted by the bundle's sXMR RFPs. ## References -- [Haven Protocol Documentation](https://docs.havenprotocol.org) (accessed 2026-05-22) -- [Haven Protocol Whitepaper](https://havenprotocol.org/whitepaper/) (accessed 2026-05-22) -- [CoinGecko: Haven (XHV)](https://www.coingecko.com/en/coins/haven) (accessed 2026-05-22) +- [Haven Protocol Documentation](https://docs.havenprotocol.org) (accessed + 2026-05-22) +- [Haven Protocol Whitepaper](https://havenprotocol.org/whitepaper/) (accessed + 2026-05-22) +- [CoinGecko: Haven (XHV)](https://www.coingecko.com/en/coins/haven) (accessed + 2026-05-22) - [Haven Explorer](https://explorer.havenprotocol.org) (accessed 2026-05-22) -- [Secret Network documentation](https://docs.scrt.network) (accessed 2026-05-22) -- [Bitcoin Insider: Secret Monero Bridge mainnet launch](https://www.bitcoininsider.org/article/123189/secret-network-announces-launch-secret-monero-bridge-mainnet) (accessed 2026-05-22) -- [`maxkoda-cpu/Secret-Monero-Bridge`](https://github.com/maxkoda-cpu/Secret-Monero-Bridge) (accessed 2026-05-22) -- [Secret Monero Bridge Devpost](https://devpost.com/software/secret-monero-bridge) (accessed 2026-05-22) -- [Monero, Zero to Monero 2.0 (whitepaper)](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) (accessed 2026-05-21) -- [Monero, FCMP++ announcement (2024-04-27)](https://www.getmonero.org/2024/04/27/fcmps.html) (accessed 2026-05-21) -- [docs.stacks.co/learn/sbtc](https://docs.stacks.co/learn/sbtc) (referenced; specific trust-shape claims pending vault verification) +- [Secret Network documentation](https://docs.scrt.network) (accessed + 2026-05-22) +- [Bitcoin Insider: Secret Monero Bridge mainnet launch](https://www.bitcoininsider.org/article/123189/secret-network-announces-launch-secret-monero-bridge-mainnet) + (accessed 2026-05-22) +- [`maxkoda-cpu/Secret-Monero-Bridge`](https://github.com/maxkoda-cpu/Secret-Monero-Bridge) + (accessed 2026-05-22) +- [Secret Monero Bridge Devpost](https://devpost.com/software/secret-monero-bridge) + (accessed 2026-05-22) +- [Monero, Zero to Monero 2.0 (whitepaper)](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) + (accessed 2026-05-21) +- [Monero, FCMP++ announcement (2024-04-27)](https://www.getmonero.org/2024/04/27/fcmps.html) + (accessed 2026-05-21) +- [docs.stacks.co/learn/sbtc](https://docs.stacks.co/learn/sbtc) (referenced; + specific trust-shape claims pending vault verification) From ad2e6b11b60ba4b198fe62840f3d39cc3188e1c7 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 22 May 2026 17:58:14 +1000 Subject: [PATCH 09/17] rfp: apply verified sourcing from research vault (11-claim pass) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The vault deliverable atomic-swap-protocol-details.md (plus stacks-sbtc.md, synthetix.md, updated haven.md) answered all 11 sourcing requests on 2026-05-22. Corrections applied: Primer (appendix/atomic-swaps-primer.md): - Drop the "step 0: signed quote" framing. Quote exchange is an implementation-layer maker convention (libp2p secure-channel auth), not a cryptographic protocol step. Gugger 2020 §2 explicitly says price agreement is off-protocol. - Reframe BTC-locks-first as an economic constraint (draining-attack analysis, Hoenisch and del Pino 2021 §4), not a primitive constraint. Gugger 2020 has the reverse XMR-first variant; reversing the order requires CLSAG-based adaptor signatures (not deployed). - Correct timelock framing: both timelocks are Bitcoin-side; Monero has no script-level timelock primitive (Gugger 2020 §3.1). Add canonical mainnet values from xmr-btc-swap and eigenwallet source code (eigenwallet: t_1=24, t_2=144; COMIT: 72/72). - Soften Han 2019 claim: paper proves equivalence to premium-free American Call Option and quantifies premium at ~2% for crypto pairs; does not directly attribute volume scarcity to the free-option. - Reframe the "4-year gap": Decred-Litecoin 2017-09-19 first on-chain HTLC to COMIT 2021-08-20 BTC-XMR mainnet is ~4 years bridging the script-vs-no-script chain gap. From Gugger 2020 formal protocol to COMIT mainnet is ~18 months. TierNolan's bitcointalk post is 2013, not 2017. - Refine HTLC requirements: hashlocks plus relative timelocks plus transaction-malleability fix (Gugger 2020 §3.2). - Bump eigenwallet to v4.6.4 (2026-05-21). - Correct deployed-direction roles: Alice = XMR seller, Bob = BTC seller, BTC locks first. Synthetics appendix (appendix/synthetics-design-space.md): - Haven Protocol: confirmed shutdown 2024-12-12 after range-proof exploit; >94% of XHV supply controlled by attackers at closure. Closure announcement cited directly. - Synthetix: SIP-302 V3 CDP-minting reference verified with direct quote from the SIP. - sBTC (Stacks): 15-signer federation, 70% threshold (14 currently operating, 10-of-14 to sign); ~6-block (~1h) withdrawal latency; no protocol-level privacy on BTC-side destination. - Two-unrelated-sXMR-products section: Synthetix sXMR (Ethereum L1, SNX-collateralised CDP oracle synth, Hadar release 2020-03-30) is unrelated to Secret Network sXMR (SNIP-20 wrapped real XMR via Secret Monero Bridge, 2021). The two share a ticker but were never paired. - Remove all "flagged for vault verification" inline annotations. RFP-024 (synthetic XMR pure): - Rewrite the wedge paragraph: two distinct prior-art families (bridge-custodied real XMR via Secret Monero Bridge; CDP-collateralised oracle-priced synth via Synthetix sXMR) neither of which fills the non-custodial peer-to-peer-atomic-swap corner. - Correct Haven characterisation: ran 2018-2024, closed 2024-12-12, never offered xXMR. - Clean up references to remove the stale "pending vault verification" annotations. RFP-025 (synthetic XMR SLA): - Add the sBTC custody specifics (15-signer 70% threshold) to the references list; remove the "pending vault verification" annotation. Decisions log (proposals-review/pr-57-decisions.md): - Replace "Outstanding sourcing requests" with "Sourcing requests resolved 2026-05-22" listing each of the 11 claims with their resolution. PR description updated to reflect the new three-appendix structure and the verified-sourcing pass. Co-Authored-By: Claude Opus 4.7 (1M context) --- RFPs/RFP-024-synthetic-xmr-pure.md | 52 +++-- RFPs/RFP-025-synthetic-xmr-sla.md | 9 +- appendix/atomic-swaps-primer.md | 324 +++++++++++++++++----------- appendix/synthetics-design-space.md | 108 +++++++--- 4 files changed, 324 insertions(+), 169 deletions(-) diff --git a/RFPs/RFP-024-synthetic-xmr-pure.md b/RFPs/RFP-024-synthetic-xmr-pure.md index a5733ee..fba0a28 100644 --- a/RFPs/RFP-024-synthetic-xmr-pure.md +++ b/RFPs/RFP-024-synthetic-xmr-pure.md @@ -23,16 +23,37 @@ swap. The protocol holds no XMR, runs no signer set, and offers no redemption SLA. The wedge: no published, live synthetic redeems to real XMR on Monero L1 -*non-custodially, via peer-to-peer atomic swap*. The closest deployed prior art -is **custodial**: Secret Network's Secret Monero Bridge (live since August 2021) -ran sXMR as a SNIP-20 token bridged via a multi-signature Monero wallet operated -by consensus-node operators; the trust shape is a signer set, not peer-to-peer -atomicity. Other commodity-tracking synthetics (sBTC on Stacks, sETH-style -synths) redeem to transparent assets, leaving the destination on a public -ledger. The Haven Protocol xAsset family (xUSD and other privacy-preserving -xAssets) runs on a Monero-forked L1 but does not include an xXMR product; its -design is over-collateralised synthetics minted against XHV, not peer-to-peer -atomic-swap redemption. +*non-custodially, via peer-to-peer atomic swap*. Two distinct prior-art families +exist, neither of which fills this corner: + +- **Bridge-custodied real XMR.** Secret Network's Secret Monero Bridge (live + since August 2021) ran sXMR as a SNIP-20 token bridged via a multi-signature + Monero wallet operated by consensus-node operators; the trust shape is a + signer set, not peer-to-peer atomicity. Source: + [github.com/maxkoda-cpu/Secret-Monero-Bridge](https://github.com/maxkoda-cpu/Secret-Monero-Bridge) + (accessed 2026-05-22). +- **CDP-collateralised oracle-priced synth, no real XMR.** Synthetix listed sXMR + on Ethereum L1 (Hadar release, 2020-03-30) as an SNX-collateralised + oracle-priced ERC-20; the contract held no Monero, only SNX collateral was at + risk, and the synth was not redeemable to XMR. Source: + [Synthetix blog: Hadar release](https://blog.synthetix.io/new-synths-update-for-the-upcoming-hadar-release/) + (accessed 2026-05-22). The Synthetix sXMR and the Secret Network sXMR share a + ticker but are unrelated products; see + [appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) + §Two unrelated sXMR products. + +Other commodity-tracking synthetics (sBTC on Stacks, sETH-style synths) redeem +to transparent assets, leaving the destination on a public ledger. The Haven +Protocol xAsset family (xUSD and other privacy-preserving xAssets) ran on a +Monero-forked L1 from 2018 until project closure on 2024-12-12 (a range-proof +validation vulnerability allowed unbounded illicit minting; >94% of known XHV +supply was controlled by attackers at closure). Haven never offered an xXMR +product; its design was over-collateralised synthetics minted against XHV, not +peer-to-peer atomic-swap redemption. Source: +[Haven Protocol: Project Closure Announcement (2024-12-12)](https://havenprotocol.org/2024/12/12/project-closure-announcement/) +(accessed 2026-05-22). Haven's shutdown is a structural failure mode worth +noting: the same ring-signature properties that protect users prevent +post-incident wallet identification and freezing. This RFP positions itself as the first design where the redemption path itself is both privacy-preserving (deposits real XMR on Monero L1) and non-custodial @@ -256,6 +277,11 @@ LP economics. (accessed 2026-05-22) - [Haven Protocol documentation](https://docs.havenprotocol.org) (accessed 2026-05-22) -- [Stacks docs: sBTC overview](https://docs.stacks.co/learn/sbtc) (specific - trust-shape claims pending vault verification; see - PENDING-atomic-swap-protocol-details.md in the research vault) +- [docs.stacks.co/concepts/sbtc](https://docs.stacks.co/concepts/sbtc) (accessed + 2026-05-22) +- [Hiro: Who are the sBTC signers, breaking down SIP-028](https://www.hiro.so/blog/who-are-the-sbtc-signers-breaking-down-sip-028) + (accessed 2026-05-22) +- [Synthetix blog: New Synths update for the upcoming Hadar release](https://blog.synthetix.io/new-synths-update-for-the-upcoming-hadar-release/) + (accessed 2026-05-22) +- [Haven Protocol: Project Closure Announcement (2024-12-12)](https://havenprotocol.org/2024/12/12/project-closure-announcement/) + (accessed 2026-05-22) diff --git a/RFPs/RFP-025-synthetic-xmr-sla.md b/RFPs/RFP-025-synthetic-xmr-sla.md index 22c40ee..225e778 100644 --- a/RFPs/RFP-025-synthetic-xmr-sla.md +++ b/RFPs/RFP-025-synthetic-xmr-sla.md @@ -346,9 +346,12 @@ for the federated-signer custody analysis that applies to option 2b. - [appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) - [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) - [appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) -- [sBTC (Stacks) Bitcoin layer documentation](https://docs.stacks.co/learn/sbtc) - (specific trust-shape claims pending vault verification; see - PENDING-atomic-swap-protocol-details.md in the research vault) +- [docs.stacks.co/concepts/sbtc](https://docs.stacks.co/concepts/sbtc) (accessed + 2026-05-22) — sBTC is a 1:1 BTC-backed asset on Stacks; custody is a 15-signer + federation with a 70% threshold (current operating set 14 signers, 10-of-14 to + sign peg-out); withdrawal latency ~6 Bitcoin blocks. +- [Hiro: Who are the sBTC signers, breaking down SIP-028](https://www.hiro.so/blog/who-are-the-sbtc-signers-breaking-down-sip-028) + (accessed 2026-05-22) - [Crypto Times: $10.8M drained from Thorchain on 2026-05-15](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) (accessed 2026-05-19) - [Halborn: Wormhole Hack on 2022-02-02 (technical analysis)](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) diff --git a/appendix/atomic-swaps-primer.md b/appendix/atomic-swaps-primer.md index 1db374b..89ccea7 100644 --- a/appendix/atomic-swaps-primer.md +++ b/appendix/atomic-swaps-primer.md @@ -15,23 +15,30 @@ other. Two cryptographic constructions are deployed: -- **Hash time-locked contract (HTLC)** for chain pairs with compatible - scripting. The lock outputs are spendable either by knowledge of a hash - preimage `s` (claim path) or by waiting out a timelock (refund path). - Decred-Litecoin executed the first on-chain HTLC swap on 2017-09-20. Source: +- **Hash time-locked contract (HTLC)** for chain pairs where both chains have + scripting expressive enough for hashlocks (`HASH160`/`SHA256` + `OP_EQUAL`), + relative timelocks (`CHECKLOCKTIMEVERIFY` / `CHECKSEQUENCEVERIFY`), and a + transaction-malleability fix (e.g. SegWit on Bitcoin). The lock outputs are + spendable either by knowledge of a hash preimage (claim path) or by waiting + out a timelock (refund path). Decred-Litecoin executed the first on-chain HTLC + swap on 2017-09-19. Sources: [Decred blog, On-Chain Atomic Swaps (2017-09-20)](https://blog.decred.org/2017/09/20/On-Chain-Atomic-Swaps/) - (accessed 2026-05-21). + (accessed 2026-05-22); + [Gugger 2020 §3.2](https://eprint.iacr.org/2020/1126.pdf) (accessed + 2026-05-22). - **Adaptor signatures with cross-curve DLEQ proofs** for chain pairs where one - side has restricted scripting (e.g. Monero). The secret is a scalar that - completes a signature on one chain; revealing it lets the counterparty produce - a valid signature on the other. The construction was first proposed for - BTC-XMR in 2017 and reached working implementations in 2021. Sources: + side lacks the script primitives required for HTLC (Monero being the canonical + case). The secret is a scalar that simultaneously serves as a private-key + share on each chain's signature scheme; revealing it on one chain's signature + enables the counterparty to sign on the other. The cross-curve DLEQ proof + (proving the same scalar is a discrete log over two different elliptic-curve + groups) is the gluing primitive. Sources: [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) - (accessed 2026-05-21); + (accessed 2026-05-22); [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332](https://arxiv.org/abs/2101.12332) - (accessed 2026-05-21); + (accessed 2026-05-22); [getmonero.org: Bitcoin to Monero atomic swaps are now live, 2021-08-20](https://www.getmonero.org/2021/08/20/atomic-swaps.html) - (accessed 2026-05-21). + (accessed 2026-05-22). The two constructions differ in their script requirements but share the same trust model and the same free-option property. @@ -39,105 +46,140 @@ trust model and the same free-option property. ## The canonical XMR-BTC swap Standard adaptor-signature flow, as implemented by COMIT (`xmr-btc-swap`, -archival pending since 2024-11) and its successor fork eigenwallet (`core`, -active as of v4.6.1 on 2026-05-15). +unmaintained since 2024-11) and its successor fork eigenwallet (`core`, v4.6.4 +released 2026-05-21). The papers (Gugger 2020; Hoenisch and del Pino 2021) +present two directional variants; the deployed COMIT/eigenwallet code follows +the Hoenisch-del Pino direction (BTC locks first). See "Locking order" below for +why. -### Roles +### Roles (deployed COMIT/eigenwallet direction) -- **Alice** holds BTC, wants XMR. -- **Bob** holds XMR, wants BTC. +- **Alice** holds XMR, wants BTC. She locks XMR second. +- **Bob** holds BTC, wants XMR. He locks BTC first. + +The Hoenisch-del Pino paper labels are intentional: "Service Provider" plays +Alice (XMR seller), and the customer plays Bob (BTC seller). The deployed code +is BTC-first because the alternative (XMR-first with a maker holding BTC) +exposes the maker to a draining attack; see "Locking order" below. ### Sequence ```mermaid sequenceDiagram autonumber - participant A as Alice (BTC holder) + participant A as Alice (XMR holder) participant BTC as Bitcoin participant XMR as Monero - participant B as Bob (XMR holder) + participant B as Bob (BTC holder) - Note over A,B: 0. Quote and joint-key setup (off-chain) - A->>B: Request quote - B-->>A: Signed quote (price, expiry, refund pubkeys) - A-->>B: Joint-key setup transcript - B-->>A: Joint-key setup transcript + Note over A,B: 0. Off-chain price agreement and key generation + Note over A,B: Price agreed off-protocol (Gugger 2020 §2) + A->>B: Key-generation: DLEQ proofs and shares + B->>A: Key-generation: DLEQ proofs and shares - Note over A,B: 1. Lock-BTC (Alice locks first, script-bearing side) - A->>BTC: Lock BTC to 2-of-2 (Alice + Bob) - BTC-->>B: Confirmation observed + Note over A,B: 1. Lock-BTC (Bob locks first) + B->>BTC: Lock BTC to PTLC keyed by point S_a^btc + BTC-->>A: Confirmation observed - Note over A,B: 2. Lock-XMR (Bob locks second) - B->>XMR: Lock XMR to joint-key stealth address - XMR-->>A: Confirmation observed (via shared view key) + Note over A,B: 2. Lock-XMR (Alice locks second) + A->>XMR: Lock XMR to shared spend key S_a^xmr + S_b^xmr + XMR-->>B: Confirmation observed (via shared view key) Note over A,B: 3. Reveal and Settle - A->>BTC: Publish adaptor signature (allows Bob to claim BTC) - B->>BTC: Claim BTC, broadcasting the scalar to Alice - A->>XMR: Use the revealed scalar to claim XMR + B->>A: Adaptor signature on BTC redeem tx encrypted under S_a^btc + A->>BTC: Decrypt and publish, revealing s_a on Bitcoin + B->>XMR: Use s_a (combined with s_b) to claim XMR ``` -### Why BTC is locked first +What the secret is: the cross-curve DLEQ proof binds a single scalar `s_a` to a +secp256k1 point (Alice's adaptor-signature decryption key on the BTC side) and +to an Ed25519 point (Alice's Monero spend-key share). When Alice publishes the +decrypted BTC redeem signature on Bitcoin, `s_a` is on-chain. Bob then combines +`s_a + s_b` to spend the jointly-locked Monero. Source: +[Gugger 2020 §4.2](https://eprint.iacr.org/2020/1126.pdf); +[Hoenisch and del Pino 2021 Fig. 4](https://arxiv.org/abs/2101.12332). + +### Price agreement is not a protocol step + +Both papers treat price agreement as off-protocol. Gugger 2020 §2 says: "We +assume that they already have negotiated the price in advance ... This +negotiation can also be integrated into the protocol, for example by swap +services who provide a price to their customers." The first formal step in both +protocols is key generation, not a quote. + +In practice, `xmr-btc-swap` and `eigenwallet/core` makers do publish a quote +over libp2p before swap setup begins (the maker daemon `asb` computes price from +off-chain ticker data). The quote is not cryptographically signed; it relies on +libp2p's secure-channel authentication for transport-level integrity. This is an +implementation-layer convention used by maker software, not a step of the +protocol. + +### Locking order + +The deployed code locks BTC first, but the order is **not forced by the +cryptographic primitive**. Gugger 2020 presents an XMR-first variant; Hoenisch +and del Pino 2021 §4 discuss the same reverse direction. The deployed BTC-first +direction reflects an **economic constraint, not a cryptographic one**. + +The economic constraint (Hoenisch and del Pino 2021 §4, "draining attack"): the +party that locks first incurs the on-chain refund-transaction fee if the swap +aborts. A maker who locks first against an arbitrary counterparty can be +attacked by an adversary who repeatedly initiates swaps and abandons them, +forcing the maker to pay refund fees each time until inventory drains. The party +with the smaller refund-fee burden and the willingness to absorb it should lock +first; in practice this is the customer (Bob, BTC seller in the deployed +direction). + +A reverse XMR-first variant is implementable. It requires adaptor signatures +over Monero's CLSAG ring-signature scheme (rather than over secp256k1 ECDSA). +Hoenisch and del Pino 2021 §4 describe this construction; it was +"work-in-progress" as of the 2021 paper and is not present in `xmr-btc-swap` or +`eigenwallet/core` as of 2026-05. -The script-bearing side locks first **by construction of the adaptor-signature -primitive**, not as a design choice. +### Timelocks and refunds -The mechanism: the secret that completes the swap is an Ed25519 scalar `s` whose -discrete log corresponds to one half of the joint Monero spend key. Alice's -adaptor signature on a Bitcoin transaction is a *signature with `s` factored -out*; Bob can adapt it into a valid signature by adding `s`, but the act of -broadcasting that adapted signature on Bitcoin publishes `s` as part of the -on-chain transaction (it can be extracted by anyone observing the broadcast). -Alice then uses `s` to construct a Monero spend signature for the joint-key -output, claiming the XMR. +Both timelocks are on the Bitcoin chain. Monero has no script primitive for +timelocks (Gugger 2020 §3.1: "Monero does not require any particular on-chain +primitives (hashlocks, timelocks)"). The XMR-side "refund" path works by one +party publishing a Bitcoin transaction that reveals a secret, which the +counterparty then uses to spend the jointly-locked Monero output. -Reversing the order does not compose: +- `t_1` (cancel timelock): blocks after `tx_lock^btc` confirms before + `tx_cancel^btc` can be published by either party. Determines the upper bound + on Alice's redeem window. +- `t_2` (punish timelock): blocks after `tx_cancel^btc` confirms before Alice + can publish `tx_punish^btc` to take Bob's BTC if Bob has stayed offline. -- If Bob locked XMR first, there would be no Bitcoin transaction whose broadcast - reveals `s`. Bob would need a way to commit to `s` such that Alice can extract - it after she locks BTC — but the only mechanism the primitive provides is - "Bob's broadcast of a Bitcoin-claim signature reveals `s`", which presupposes - Bob has something to claim on Bitcoin. -- Equivalently: the secret-revelation flow points from BTC settlement to XMR - claimability. The chain that hosts the adaptor signature (BTC) must hold a - lock the counterparty wants to claim before the secret materialises. +Source: [Hoenisch and del Pino 2021 §3.3](https://arxiv.org/abs/2101.12332). -Consequence: **whichever chain holds the script side of the swap locks first.** -For XMR-BTC, BTC. For XMR with any other script-bearing chain, that chain. This -is a property of the primitive, fixed independently of who is taker or maker. +Canonical mainnet values: -### Timelocks and refunds +- **`comit-network/xmr-btc-swap`** (upstream, unmaintained): `t_1 = 72` blocks + (~12h), `t_2 = 72` blocks (~12h); total refund window ~24h. +- **`eigenwallet/core`** (active fork, as of 2026-05-22): `t_1 = 24` blocks + (~4h), `t_2 = 144` blocks (~24h); total refund window ~28h. -Each lock has a refund timelock. If the swap stalls before reveal, the locker -can sweep their lock back after the timelock expires. The script-side refund -(Alice's BTC) typically has a shorter timelock than the secret-side refund -(Bob's XMR), so Alice cannot wait until Bob has refunded his XMR and then claim -Alice-side BTC anyway. - -Refund and claim windows are conventionally measured in hours. A swap that -proceeds normally completes in roughly one Bitcoin confirmation depth (typically -10-60 minutes for the BTC lock) plus one Monero confirmation depth (typically -10-30 minutes for the XMR lock) plus the reveal latency. +A swap that proceeds normally completes in roughly one Bitcoin confirmation +depth for the BTC lock plus one Monero confirmation depth for the XMR lock plus +the reveal latency. ### Production status of XMR-BTC implementations - **COMIT `xmr-btc-swap`**: original reference implementation, [unmaintained since 2024-11, archival pending per issue #1791](https://github.com/comit-network/xmr-btc-swap) - (accessed 2026-05-21). -- **eigenwallet `core`**: active fork of `xmr-btc-swap`; v4.6.1 released - 2026-05-15. [github.com/eigenwallet/core](https://github.com/eigenwallet/core) - (accessed 2026-05-21). + (accessed 2026-05-22). Last formal release v1.0.0-rc.1 on 2024-11-15. +- **eigenwallet `core`**: active fork of `xmr-btc-swap`; v4.6.4 released + 2026-05-21 (14 releases in the 47 days from 2026-04-05 to 2026-05-21). + [github.com/eigenwallet/core](https://github.com/eigenwallet/core) (accessed + 2026-05-22). - **Farcaster Project (`farcaster-project/farcaster-node`)**: independent - BTC-XMR implementation. Still listed as actively maintained as of 2026, with - Lightning BTC support added to reduce BTC-side confirmation time. - Community-scale rather than volume-scale operation. Sources: - [xgram.io: Best Monero atomic swap platforms 2026](https://xgram.io/blog/best-xmr-atomic-swaps-and-community-services-2026) - (accessed 2026-05-19); - [github.com/farcaster-project](https://github.com/farcaster-project) (accessed - 2026-05-19). -- **AtomicDEX / Komodo Wallet**: rebranded to "Komodo Wallet" in 2025. Public - trackers report no recent volume; Nomics' last published 24-hour volume figure - is approximately USD 5,737 from November 2021. Source: + BTC-XMR implementation. Last formal release v0.8.4 on 2023-01-16; last code + push 2024-08-11; not archived but inactive since 2024. Source: + [github.com/farcaster-project/farcaster-node](https://github.com/farcaster-project/farcaster-node) + (accessed 2026-05-22). +- **AtomicDEX / Komodo Wallet**: rebranded to "Komodo Wallet" in 2025. No public + BTC-XMR pair-level volume figures available; Nomics' last published 24-hour + volume for AtomicDEX was approximately USD 5,737 from November 2021. Source: [Nomics: AtomicDEX](https://nomics.com/exchanges/atomicdex) (accessed 2026-05-19). - **Liquality**: consumer atomic-swap wallet extension discontinued effective @@ -147,7 +189,7 @@ proceeds normally completes in roughly one Bitcoin confirmation depth (typically [Rootstock Helpdesk: Liquality](https://helpdesk.rootstock.io/solutions/liquality.html) (accessed 2026-05-19). -The XMR-BTC corridor is operational but at community scale. See the +The XMR-BTC corridor is operational at community scale. See the [trust-model contrast appendix](./cross-chain-trust-model-contrast.md) for cumulative-volume comparison against federated-signer protocols. @@ -162,25 +204,29 @@ has not yet acted. The uncommitted party holds a **free option**: they can observe the market for the duration of the lock window and proceed only if the trade is still in their favour. -Stage-by-stage in the XMR-BTC flow: +Stage-by-stage in the deployed BTC-first XMR-BTC flow: -1. **After Alice locks BTC (step 1, before step 2).** Bob holds the free option. - If XMR price has moved against him since the quote, he simply does not lock - XMR. Alice's BTC refunds at timeout. Bob's downside: time. Alice's downside: - lock window plus refund timelock with capital wedged. -2. **After Bob locks XMR (step 2, before step 3).** Alice holds the free option. - If the price has moved against her, she does not publish the adaptor - signature. Both legs refund at timeout. Alice's downside: time. Bob's +1. **After Bob locks BTC (step 1, before step 2).** Alice holds the free option. + If XMR price has moved against her since the quote, she simply does not lock + XMR. Bob's BTC refunds at timeout. Alice's downside: time. Bob's downside: + refund-fee burden and lock window with BTC wedged. +2. **After Alice locks XMR (step 2, before step 3).** Bob holds the free option. + If the price has moved against him, he does not deliver the adaptor + signature. Both legs refund at timeout. Bob's downside: time. Alice's downside: capital wedged for the longer refund window. 3. **After secret reveal (step 3 onward).** No party holds an option; the swap completes deterministically. This is the **free-option problem** of atomic swaps. It is not a bug in any -particular implementation; it is the cost of atomicity itself. Cited in the -literature as the structural reason atomic-swap volume has remained small -despite working implementations. Source: +particular implementation; it is the cost of atomicity itself. Han, Lin, and Yu +2019 prove the atomic swap is formally equivalent to a premium-free American +Call Option and estimate the implicit premium using the Cox-Ross-Rubinstein +option-pricing model at approximately 2% of asset value for cryptocurrency pairs +(vs ~0.3% for stocks and fiat). The paper provides the mechanism and quantifies +the premium; it does not directly attribute deployed-protocol volume scarcity to +the free-option problem. Source: [Han et al., On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) -(accessed 2026-05-21). +(accessed 2026-05-22). ### Notation for option value @@ -200,23 +246,46 @@ continuous-time random-walk price dynamics. It is the standard way to size a bond, premium, or cap intended to neutralise the free option a counterparty holds during a lock window. -## Generalising the locks-first rule across pairs - -The lock-ordering constraint is a property of the cryptographic construction, -not of the specific BTC-XMR pair. In any adaptor-signature swap, the -**script-bearing side** (the chain that hosts the adaptor signature whose -broadcast reveals the secret scalar) must lock first. The non-script side, where -the swap output is a joint-key construction that the secret unlocks, locks -second. - -For HTLC swaps, the analogous constraint is that the chain whose HTLC reveals -the preimage on claim must be locked first; the chain whose HTLC consumes the -same preimage on its claim path then settles second. In practice for -symmetric-script pairs (e.g. BTC-LTC) the ordering is conventional rather than -forced, since both chains can play either role. - -For XMR paired with any other chain, XMR is always the non-script side. The -script-bearing partner locks first. +## How locking order generalises across pairs + +For HTLC swaps with two script-bearing chains (BTC-LTC, BTC-ETH), the +lock-ordering is conventional: both chains can play either role. Operational +choice usually puts the chain with the **shorter refund-fee burden** or +**stronger maker-side draining-attack protection** first. + +For adaptor-signature swaps where one chain has restricted scripting (BTC-XMR, +BTC-Grin), the choice is driven by the draining-attack analysis above. The +deployed `xmr-btc-swap`/`eigenwallet` direction puts the script-bearing chain +(BTC) first because the customer-as-Bob model places the refund-fee burden on +the customer, who tolerates it. + +A reversed direction is implementable for any pair given the right cryptographic +primitives (CLSAG-based adaptor signatures for XMR-first; Schnorr adaptor +signatures for Grin-first, etc.). The choice of direction is not fixed by +cryptography; it is fixed by the economic constraints of who can absorb the +refund-fee burden under adversarial counterparty behaviour. + +## A defensible "BTC-XMR took 4 years" claim + +The first published BTC-XMR atomic-swap protocol is Gugger 2020 (IACR ePrint +2020/1126); the COMIT reference implementation reached public mainnet on +2021-08-20. From first formal proposal to working mainnet implementation was +about 18 months, not four years. + +However, BTC-XMR was the hardest atomic-swap case to bring to mainnet because +Monero has no scripting for HTLCs. The cryptographic gap (cross-curve DLEQ +proofs plus ECDSA one-time verifiably-encrypted signatures) was bridged by +intermediate work (Noether 2018 MRL-0010 for cross-curve DLEQ; Fournier 2019 for +ECDSA one-time VES). From the **first on-chain HTLC swap** (Decred-Litecoin +2017-09-19) to the **first BTC-XMR adaptor-signature swap on mainnet** (COMIT +2021-08-20) is approximately four years of cryptographic and engineering work to +bridge the script-vs-no-script chain gap. Sources: +[Decred blog, On-Chain Atomic Swaps (2017-09-20)](https://blog.decred.org/2017/09/20/On-Chain-Atomic-Swaps/); +[getmonero.org, Bitcoin to Monero atomic swaps are now live (2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html); +[Gugger 2020](https://eprint.iacr.org/2020/1126.pdf); +[Hoenisch and del Pino 2021](https://arxiv.org/abs/2101.12332). The TierNolan +bitcointalk post (topic 193281, 2013-05-21) is the originating idea for +cross-chain atomic swaps, cited as reference [17] in Hoenisch and del Pino 2021. ## What atomic swaps do not provide @@ -225,10 +294,9 @@ script-bearing partner locks first. offline mid-swap, the other waits out the refund window. - **Per-trade matching.** No protocol-owned liquidity; each swap requires a willing counterparty for the exact pair and size. -- **Pair coverage by default.** HTLC required compatible scripting on both - chains; adaptor signatures generalise this but each pair still needs - cross-curve cryptographic work (BTC-XMR required ~4 years from proposal to - working implementation). +- **Pair coverage by default.** HTLC required hashlocks plus timelocks plus + malleability fixes on both chains; adaptor signatures generalise this but each + pair still needs cross-curve cryptographic work. - **Settlement speed.** End-to-end time is dominated by the slowest chain's confirmation depth plus the timelock window. @@ -240,18 +308,22 @@ user-facing constraints. ## References - [Decred blog, On-Chain Atomic Swaps (2017-09-20, first on-chain swap, Decred-Litecoin)](https://blog.decred.org/2017/09/20/On-Chain-Atomic-Swaps/) - (accessed 2026-05-21) + (accessed 2026-05-22) - [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) - (accessed 2026-05-21) + (accessed 2026-05-22) - [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332 (2021-01-29)](https://arxiv.org/abs/2101.12332) - (accessed 2026-05-21) + (accessed 2026-05-22) - [getmonero.org: Bitcoin to Monero atomic swaps are now live (2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) - (accessed 2026-05-21) + (accessed 2026-05-22) - [Han et al., On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) - (accessed 2026-05-21) -- [comit-network/xmr-btc-swap (unmaintained since 2024-11; archival pending)](https://github.com/comit-network/xmr-btc-swap) - (accessed 2026-05-21) -- [eigenwallet/core (active fork of xmr-btc-swap; v4.6.1, 2026-05-15)](https://github.com/eigenwallet/core) - (accessed 2026-05-21) -- [farcaster-project/farcaster-node (independent XMR-BTC implementation; last release v0.8.4, 2023-01-16)](https://github.com/farcaster-project/farcaster-node) - (accessed 2026-05-21) + (accessed 2026-05-22) +- [comit-network/xmr-btc-swap (unmaintained since 2024-11)](https://github.com/comit-network/xmr-btc-swap) + (accessed 2026-05-22) +- [eigenwallet/core (active fork; v4.6.4, 2026-05-21)](https://github.com/eigenwallet/core) + (accessed 2026-05-22) +- [farcaster-project/farcaster-node (independent XMR-BTC implementation; v0.8.4 release 2023-01-16, last push 2024-08-11)](https://github.com/farcaster-project/farcaster-node) + (accessed 2026-05-22) +- [Nomics: AtomicDEX](https://nomics.com/exchanges/atomicdex) (accessed + 2026-05-19) +- [Liquality on X: discontinuation (2024-05-20)](https://x.com/Liquality_io/status/1792678368694985162) + (accessed 2026-05-19) diff --git a/appendix/synthetics-design-space.md b/appendix/synthetics-design-space.md index 365e9c1..34a19b7 100644 --- a/appendix/synthetics-design-space.md +++ b/appendix/synthetics-design-space.md @@ -28,25 +28,33 @@ Synthetics minted against stable collateral, valued by oracle, settled in collateral rather than the tracked asset. - **Haven Protocol (XHV / xUSD / other xAssets).** Monero-forked L1 launched - 2018\. Users lock XHV to mint xAssets at oracle price; conversion between - xAssets burns the source and mints the destination. Over-collateralised. xUSD - has depegged multiple times (notably 2022-2023) due to low liquidity, oracle - delays, and market stress. As of 2026-05-22, XHV market cap is approximately - $5.5M and xUSD supply approximately $1.2M; daily transactions approximately - 50-100. Sources: + 2018\. Users locked XHV to mint xAssets at oracle price; conversion between + xAssets burned the source and minted the destination. Over-collateralised. + xUSD depegged multiple times (notably 2022-2023) due to low liquidity, oracle + delays, and market stress. **Haven announced project closure on 2024-12-12** + after discovery of a range-proof validation vulnerability (introduced in the + 3.2 rebase to Monero, effective from August 2023) that allowed at least 1.3 + billion XHV to be illicitly minted across at least 42 transactions; at closure + the team stated "over 94% of the known supply is now controlled by the + attackers" and that "there is no realistic way forward". CoinGecko market-cap + and explorer activity since closure reflect residual exchange trading of an + unbacked token, not active protocol use. Sources: + [Haven Protocol: Project Closure Announcement (2024-12-12)](https://havenprotocol.org/2024/12/12/project-closure-announcement/) + (accessed 2026-05-22); [Haven Protocol Documentation](https://docs.havenprotocol.org) (accessed - 2026-05-22); - [CoinGecko: Haven (XHV)](https://www.coingecko.com/en/coins/haven) (accessed - 2026-05-22); [Haven Explorer](https://explorer.havenprotocol.org) (accessed - 2026-05-22). Note: prior PR-57 appendix text stated Haven shut down in - December 2024; this claim has been flagged for vault verification as it does - not match the current explorer/market-cap data above. -- **Synthetix.** SNX stakers mint sUSD and other synthetic equivalents against - SNX collateral, debt pooled across all stakers. Used as a reference for - "oracle-priced over-collateralised synth" rather than for a specific - Monero-relevant property here. Note: prior PR-57 appendix text cited SIP-302 - as the canonical reference for V3 collateral and snxUSD minting; this citation - has been flagged for vault verification. + 2026-05-22). +- **Synthetix.** SNX stakers mint snxUSD (V3) or sUSD (V2) and other synthetic + equivalents against SNX or governance-approved collateral; in V3, debt is + pooled per-pool (V2 socialised debt across all stakers). The canonical V3 + CDP-minting reference is + [SIP-302 (Pools V3)](https://sips.synthetix.io/sips/sip-302) (accessed + 2026-05-22): *"The Vault Module creates vaults of each collateral type per + pool, similar to a CDP (MakerDAO, Liquity), where accounts can delegate their + staked collateral to pools by opening staking positions and then mint and burn + snxUSD, backed by their collateral."* Used here as a reference for + "oracle-priced over-collateralised synth"; Synthetix did list an sXMR synth + (Hadar release, 2020-03-30) as an SNX-collateralised oracle-priced Ethereum L1 + synth — see "Two unrelated sXMR products" below. What you trust in this design family: @@ -64,21 +72,50 @@ layer, so xAssets cannot be used in DeFi outside Haven itself. Synthetics minted against the underlying asset held by a custodial bridge, valued by direct redemption. -- **sBTC (Stacks).** Synthetic BTC on Stacks, redeemable to native BTC. The - custody arrangement (signer set, threshold scheme, redemption SLA) has been - flagged for vault verification before specific claims are made here. Canonical - docs page: [docs.stacks.co/learn/sbtc](https://docs.stacks.co/learn/sbtc). - This claim and its specific trust-shape characterisation have been added to - the pending-research request for PR #57. +- **sBTC (Stacks).** 1:1 Bitcoin-backed asset on the Stacks L2; users mint by + depositing BTC into a federation-controlled multisig UTXO and redeem by + burning sBTC on Stacks to trigger a peg-out signed by the federation. Mainnet + deposits launched 2024-12-17. **Custody is a 15-signer federation with a 70% + threshold (11 of 15 to sign peg-in/peg-out operations, per SIP-028; current + operating set is 14 signers with 10-of-14 threshold).** Withdrawal latency is + 6 Bitcoin blocks (~1 hour). The peg-out releases BTC from the publicly known + multisig UTXO to a requester-supplied destination address; there is no + protocol-level privacy property on the BTC-side destination. Sources: + [docs.stacks.co/concepts/sbtc](https://docs.stacks.co/concepts/sbtc) (accessed + 2026-05-22); + [Hiro: Who are the sBTC signers, breaking down SIP-028](https://www.hiro.so/blog/who-are-the-sbtc-signers-breaking-down-sip-028) + (accessed 2026-05-22). - **Secret Monero Bridge** (Secret Network). Mainnet launched August 2021. Multi-signature Monero wallet operated by consensus-node signers (MSCNOs) communicating over I2P; users deposit XMR, receive sXMR (a SNIP-20 token on - Secret Network) usable in Secret DeFi (e.g. SecretSwap). Source: + Secret Network) usable in Secret DeFi (e.g. SecretSwap). Sources: [Bitcoin Insider: Secret Monero Bridge mainnet launch](https://www.bitcoininsider.org/article/123189/secret-network-announces-launch-secret-monero-bridge-mainnet) (accessed 2026-05-22); [github.com/maxkoda-cpu/Secret-Monero-Bridge](https://github.com/maxkoda-cpu/Secret-Monero-Bridge) (accessed 2026-05-22). +#### Two unrelated sXMR products + +Two different products have used the ticker "sXMR" historically; they are +unrelated: + +- **Synthetix sXMR (Ethereum L1, 2020).** SNX-collateralised CDP oracle-priced + synth tracking the Monero price via Chainlink, listed as part of the Synthetix + Hadar release on 2020-03-30 alongside sBCH, sADA, sDASH, sEOS, sETC. Contract: + ERC-20 at `0x5299d6F7472DCc137D7f3C4BcfBBB514BaBF341A` on Ethereum. The + contract held no Monero — only SNX collateral was at risk. Not redeemable for + XMR. Source: + [Synthetix blog: New Synths update for the upcoming Hadar release](https://blog.synthetix.io/new-synths-update-for-the-upcoming-hadar-release/) + (accessed 2026-05-22). +- **Secret Network sXMR (Secret Network, 2021).** SNIP-20 wrapped-Monero token + issued by the Secret Monero Bridge (above). Federation-custodied real XMR, + redeemable to XMR. Different ticker namespace (SNIP-20 on Secret Network, not + ERC-20 on Ethereum). Not connected to Synthetix. + +The name collision is unfortunate; the products are not related and were not +paired. Earlier framings that combined them ("Synthetix's sXMR paired with the +Secret Network Monero Bridge") are incorrect. + What you trust in this design family: - The custodian (signer set, multisig threshold). @@ -154,6 +191,15 @@ instructive: [`maxkoda-cpu/Secret-Monero-Bridge`](https://github.com/maxkoda-cpu/Secret-Monero-Bridge) (accessed 2026-05-22). +A separate but adjacent failure case is the **Haven Protocol shutdown** +(2024-12-12, see above): a privacy-preserving CDP synthetic protocol that ran on +a Monero-forked L1 was forced to shut down after a range-proof exploit allowed +unbounded illicit minting of the protocol's native collateral token. The +ring-signature properties that protect users also prevented post-incident wallet +identification and freezing. This is a structural failure mode of any +privacy-preserving CDP / mint-burn synthetic protocol: privacy operates +symmetrically against attackers and against post-incident forensics. + These are properties of the bridge's design and reception; whether any specific lesson applies to a future synthetic depends on the future synthetic's own choices and is left to the relevant RFPs. @@ -194,5 +240,13 @@ Common patterns across the deployed examples: (accessed 2026-05-21) - [Monero, FCMP++ announcement (2024-04-27)](https://www.getmonero.org/2024/04/27/fcmps.html) (accessed 2026-05-21) -- [docs.stacks.co/learn/sbtc](https://docs.stacks.co/learn/sbtc) (referenced; - specific trust-shape claims pending vault verification) +- [docs.stacks.co/concepts/sbtc](https://docs.stacks.co/concepts/sbtc) (accessed + 2026-05-22) +- [Hiro: Who are the sBTC signers, breaking down SIP-028](https://www.hiro.so/blog/who-are-the-sbtc-signers-breaking-down-sip-028) + (accessed 2026-05-22) +- [SIP-302 (Synthetix Pools V3)](https://sips.synthetix.io/sips/sip-302) + (accessed 2026-05-22) +- [Synthetix blog: New Synths update for the upcoming Hadar release](https://blog.synthetix.io/new-synths-update-for-the-upcoming-hadar-release/) + (accessed 2026-05-22) +- [Haven Protocol: Project Closure Announcement (2024-12-12)](https://havenprotocol.org/2024/12/12/project-closure-announcement/) + (accessed 2026-05-22) From b227883dba964e8ea09201ac22b3b10641b9145f Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 22 May 2026 18:05:36 +1000 Subject: [PATCH 10/17] rfp: add RFP-026 fee-burn atomic swaps; apply bond-system review fixes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit New RFP: - RFP-026 (Fee-Burn Atomic Swaps): adapts the eigenwallet PR #675 mechanism to LEZ-paired swaps. Non-refundable burn on the refund branch prices the free option without an on-LEZ bond. Maker-set fraction; burnt (not paid to counterparty) to avoid incentive skew; mercy path for honest refunds. The RFP explicitly addresses direction dependence: the fee-burn lives on the locks-first chain, so it prices the first-locker's option only; the second-locker's option needs a separate mechanism (or is left unpriced). For the reverse XMR-first variant (Hoenisch and del Pino 2021 §4), Monero has no refund-branch script and the mechanism is infeasible until FCMP++ or similar primitives ship. Bond-system review (code-reviewer agent) findings applied: - RFP-022 §Overview: replaced "Locking order is fixed by the cryptographic primitive" with the draining-attack economic framing (Hoenisch and del Pino 2021 §4), matching the corrected primer. Fixed broken anchor link to the primer. - RFP-022 §Cons: added "Bond can exceed spread in high-volatility regimes" with the σ=0.8 / 28h example yielding bond ≈ 4-5% of notional vs typical maker spread 1-2%. Applicants must address what happens when σ × √T > spread. - RFP-022 §Relationship: added RFP-026 entry. Explicitly framed as a *substitute* for RFP-022's bond, not a complement. RFP-022 bond dominates Tier 1 (capital-efficient on honest completion); RFP-026 fee-burn dominates Tier 2 (prices the off-LEZ option the bond can't). Layering both on the same option boundary is double-counting. - RFP-024 §Overview: added "Trade-off accepted up front" paragraph moving the unpriced-free-option choice from Risks to the Overview. States explicitly that LPs bear the cost of the unpriced option; points readers to RFP-022, RFP-026, or RFP-025 if they want the option priced. - RFP-025 §Option 2a: added paragraph distinguishing the per-swap RFP-022 bond from the persistent SLA-bond. Applicants must address whether the two are additive or one subsumes the other when layered; aggregate bond load matters for LP economics. Deferred for follow-up review (real findings, not fixed in this commit): bond sizing T-parameter inconsistency (1h indicative vs 28h actual refund window); Phase 5 settlement clarification; bondless- taker capped-entry interaction with both-bonds-at-Commit; Tier 2 bidirectional audit tables; Wormhole-as-closest-analog framing in RFP-023; Thorchain aggregate-bond invariant accept/reject; bondless cap math (US$100 ↔ option value). Captured in pr-57-decisions.md. Co-Authored-By: Claude Opus 4.7 (1M context) --- RFPs/RFP-022-bonded-atomic-swaps.md | 39 ++- RFPs/RFP-024-synthetic-xmr-pure.md | 10 + RFPs/RFP-025-synthetic-xmr-sla.md | 11 + RFPs/RFP-026-fee-burn-atomic-swaps.md | 386 ++++++++++++++++++++++++++ 4 files changed, 438 insertions(+), 8 deletions(-) create mode 100644 RFPs/RFP-026-fee-burn-atomic-swaps.md diff --git a/RFPs/RFP-022-bonded-atomic-swaps.md b/RFPs/RFP-022-bonded-atomic-swaps.md index f823a6a..734512d 100644 --- a/RFPs/RFP-022-bonded-atomic-swaps.md +++ b/RFPs/RFP-022-bonded-atomic-swaps.md @@ -32,14 +32,19 @@ no premium owed). Bond sized at or above option value (`σ × √T × notional`; [atomic-swaps primer](../appendix/atomic-swaps-primer.md#notation-for-option-value)) makes the abort branch EV-negative and closes the free option. -Locking order is fixed by the cryptographic primitive, not by design choice. The -[atomic-swaps primer §Generalising the locks-first rule across pairs](../appendix/atomic-swaps-primer.md#generalising-the-locks-first-rule-across-pairs) -sets out the rule; the specific lock-ordering for LEZ↔BTC and LEZ↔XMR is part of -the applicant's design output and must be justified against the primer's -framing. In the worked examples below, Alice locks first on the external chain -and Bob locks second on LEZ; this is the BTC-XMR convention lifted directly. -Applicants targeting other pairs (LEZ↔ETH especially, where both chains have -full scripting) must state the locking-order choice explicitly. +Locking order is driven by the **draining-attack economic analysis** (Hoenisch +and del Pino 2021 §4): the party who locks first incurs the on-chain +refund-transaction fee under adversarial counterparty behaviour, so the party +who can absorb that cost should lock first. See +[atomic-swaps primer §How locking order generalises across pairs](../appendix/atomic-swaps-primer.md#how-locking-order-generalises-across-pairs). +The choice is *not* fixed by the cryptographic primitive; reverse variants are +constructible given the appropriate adaptor-signature primitives on each chain. +For the worked examples below, Alice is the BTC-side party and locks first on +the external chain (matching the deployed COMIT/eigenwallet convention); Bob is +the LEZ-side party and locks second on LEZ. Applicants targeting other pairs +(LEZ↔ETH especially, where both chains have full scripting) must state the +locking-order choice explicitly and justify it against the draining-attack +analysis. The design splits into two tiers that reflect a structural asymmetry in the underlying cryptography: @@ -308,6 +313,16 @@ the LEZ escrow program: - **Bond opportunity cost.** Makers must lock LEZ-denominated bond capital, which yields nothing during the lock window. This raises maker spreads relative to the unbonded (free-option) atomic swap of RFP-003. +- **Bond can exceed spread in high-volatility regimes.** For pairs with + annualised volatility around 0.8 (a plausible regime for XMR) and the ~28h + deployed refund window, the option value `σ × √T × notional` works out to + roughly 4-5% of notional, which exceeds typical maker spreads on the BTC-XMR + corridor (1-2%). The bond is not a free-option closure under those regimes; it + shifts the problem from "makers are griefed" to "makers stop quoting because + the bond load exceeds their margin". Applicants must address what happens in + this regime: dynamic bond sizing, spread widening, fallback to fee-burn-only + (RFP-026), or accept the consequence that the design has a working-volatility + range it cannot serve. - **Bond denomination friction.** First-time takers need LEZ-denominated bond assets. The bondless-taker capped-entry path mitigates this but only for the first swap. @@ -367,6 +382,14 @@ the LEZ escrow program: - **RFP-024 (sXMR pure)** and **RFP-025 (sXMR with SLA)** are orthogonal. They target synthetic XMR exposure inside LEZ DeFi; this RFP targets real-asset atomic swaps. They could be deployed alongside. +- **RFP-026 (fee-burn atomic swaps)** is the *substitute* option-pricing + mechanism, not a complement. RFP-026's fee-burn lives in the external-chain + refund branch; RFP-022's bond lives on LEZ at Commit. They price the same free + option using different escrow locations. RFP-022's bond dominates on Tier 1 + (capital-efficient because it refunds on honest completion); RFP-026's + fee-burn dominates on Tier 2 (it can price the off-LEZ residual option that + Tier 2's bond cannot). Layering both on the same option boundary is + double-counting. See [appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) for the underlying cryptographic mechanics, the free-option framing, and the diff --git a/RFPs/RFP-024-synthetic-xmr-pure.md b/RFPs/RFP-024-synthetic-xmr-pure.md index fba0a28..d648086 100644 --- a/RFPs/RFP-024-synthetic-xmr-pure.md +++ b/RFPs/RFP-024-synthetic-xmr-pure.md @@ -55,6 +55,16 @@ peer-to-peer atomic-swap redemption. Source: noting: the same ring-signature properties that protect users prevent post-incident wallet identification and freezing. +**Trade-off accepted up front.** This RFP deliberately leaves the free option of +the redemption-leg atomic swap unpriced. RFP-022's LEZ bond and RFP-026's +external-chain fee-burn both price that option but at the cost of LP capital +efficiency or refund-branch principal loss. Goal 1's premise is that a +privacy-maximalist user base will tolerate variable redemption availability (LPs +may be slow to show up, spreads may widen under stress) in exchange for the +cleanest non-custody story. The unpriced free option is the explicit cost the +protocol pays for that positioning; LPs bear it. If you want the option priced, +choose RFP-022, RFP-026, or RFP-025 instead. + This RFP positions itself as the first design where the redemption path itself is both privacy-preserving (deposits real XMR on Monero L1) and non-custodial (atomic-swap rather than signer-set bridge). See diff --git a/RFPs/RFP-025-synthetic-xmr-sla.md b/RFPs/RFP-025-synthetic-xmr-sla.md index 225e778..59f59cd 100644 --- a/RFPs/RFP-025-synthetic-xmr-sla.md +++ b/RFPs/RFP-025-synthetic-xmr-sla.md @@ -72,6 +72,17 @@ routed to an LP, they must complete the atomic swap within a window. If they default, their bond is slashed and paid to the redeemer. LPs may leave the set, but only after a notice period that exceeds the redemption SLA. +**Distinguish this bond from RFP-022's swap-bond.** RFP-022's bond prices the +*free option on a single in-flight swap* and refunds at swap completion. Option +2a's bond is a *persistent performance bond against the LP's SLA across many +swaps*; it is locked for the LP's tenure plus the notice period. An LP that +adopts both layers carries both bonds against each redemption (RFP-022's bond +escrowed for the duration of the specific swap; option 2a's bond locked across +the LP's tenure). Applicants must address how the two bonds compose: are they +additive against per-redemption notional, or does the SLA-bond subsume the +swap-bond? Aggregate bond load matters for LP economics and must be sized +against expected concurrent-redemption load, not just per-swap option value. + ``` sXMR LEZ program + LP registry diff --git a/RFPs/RFP-026-fee-burn-atomic-swaps.md b/RFPs/RFP-026-fee-burn-atomic-swaps.md new file mode 100644 index 0000000..bad7c14 --- /dev/null +++ b/RFPs/RFP-026-fee-burn-atomic-swaps.md @@ -0,0 +1,386 @@ +--- +id: RFP-026 +title: Fee-Burn Atomic Swaps (Refund-Side Free-Option Mitigation) +tier: M +funding: $TBD +status: draft +category: Applications & Integrations +--- + +# RFP-026 — Fee-Burn Atomic Swaps (Refund-Side Free-Option Mitigation) + +> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos +> team and the community compare cross-chain DEX designs across RFP-021 through +> RFP-026. Hard requirements, team profile, timeline, and contracting details +> are deliberately omitted; they will be filled in if the design is selected for +> funding. + +## 🧭 Overview + +Extend RFP-003 (Atomic Swaps with LEZ, open) with a **non-refundable fee on the +refund branch** that prices out the free option without requiring an on-LEZ +bond. The fee is burnt (sent to an unspendable output), not paid to the +counterparty, so it does not skew incentives. The mechanism is the proposal in +[eigenwallet PR #675](https://github.com/eigenwallet/core/pull/675) (open as of +2026-05-22), generalised to the LEZ-paired case. + +The protocol intuition: today, in the deployed BTC-XMR adaptor-signature swap, a +taker who has locked BTC can refund at the cost of one Bitcoin transaction fee +(a few thousand sats). This makes the refund branch effectively free, which is +exactly what creates the free-option problem documented in the +[atomic-swaps primer](../appendix/atomic-swaps-primer.md#the-free-option-problem). +The fee-burn fix splits the refund branch so that taking it costs the taker a +configurable fraction of the locked amount. The fraction is set by the maker per +quote; the taker sees it before initiating and decides whether to trade. + +The mechanism is a **substitute** for the bond-based approach in RFP-022, not a +complement. The two instruments price the same free option using different +escrow locations; layering both is double-counting (charging the option holder +twice for the same option). + +- **RFP-022 LEZ bond**: the option premium is a separate amount escrowed on LEZ + at Commit; slashes to the counterparty on LEZ-observable default; + capital-efficient because it refunds on honest completion. +- **RFP-026 fee-burn**: the option premium is a haircut on the refunded + principal taken on the external chain in the refund branch; burns rather than + slashes (to avoid skewing the counterparty's incentives); does not refund on + honest completion (only the *refund branch* is fee-burdened, so honest + completions pay nothing). + +Where each dominates: + +- **Tier 1 (LEZ↔BTC, LEZ↔ETH)**: the LEZ bond strictly dominates. The bond + returns on honest completion; the fee-burn destroys principal whenever the + refund branch is taken. With both sides' locks LEZ-observable, the bond gives + the same option-closure at lower expected capital cost. +- **Tier 2 (LEZ↔XMR)**: the fee-burn dominates the LEZ bond. RFP-022's bond + cannot price the residual Phase-2 free option (the trigger event, the XMR-side + lock, is off-LEZ; see RFP-022 §Tier 2). The fee-burn on the + script-bearing-chain refund branch *can* price it because the trigger (the + refund-branch transaction itself) is on a chain both parties observe directly. + The fee-burn closes the gap RFP-022's bond cannot. + +Applicants should not propose stacking both mechanisms on the same option +boundary. They should propose the fee-burn as the Tier-2-preferred primitive and +explicitly cede Tier 1 to RFP-022's LEZ bond, or argue why one mechanism alone +covers both tiers. + +## Background: the eigenwallet PR #675 design + +The eigenwallet PR (open, not yet merged as of 2026-05-22) modifies the +Bitcoin-side refund branch of the BTC-XMR adaptor-signature swap. Roles in the +eigenwallet convention: **Bob is the taker (BTC-side, locks BTC first); Alice is +the maker (XMR-side, locks XMR second).** This matches the deployed COMIT +direction. + +Current state without fee-burn: after `TxCancel` is published, Bob has two paths +to recover his BTC after a 24h timelock — `TxFullRefund` returns all of `[B]` +(the BTC amount) to Bob; or Alice publishes `TxPunish` if Bob has stayed +offline. Bob's refund costs roughly the transaction fee of `TxFullRefund` plus 2 +prior transactions. + +Proposed state with fee-burn: the `TxFullRefund` path is **replaced** by +`TxPartialRefund`, which splits the locked output into two pieces: `[B]` +(refunded to Bob immediately) and a `Deposit [A+B]` (held in an intermediate +output). The deposit goes through a sub-protocol: + +1. After a further short timelock (30 minutes in PR #675), Bob can publish + `TxReclaim` to retrieve the deposit himself. +2. Before that timelock, Alice can publish `TxWithhold` to take the deposit into + her control (because she observed Bob refunded against the spirit of the + protocol). +3. After Alice has withheld, she can either publish `TxMercy` to release the + deposit back to Bob (forgiving the refund), or burn it by not signing any + further transaction (the deposit becomes permanently unspendable as soon as + `TxWithhold`'s output spend conditions cannot be satisfied by either party + alone). + +The deposit fraction is set by the maker per quote (Alice configures her +`ask_spread` plus a refund-fee parameter); the taker sees the deposit fraction +before locking BTC and chooses whether to trade. The deposit is **burnt** (not +paid to Alice) so that Alice has no incentive to provoke a refund just to +collect the deposit; Alice's mercy path exists so honest refunds (e.g. Alice's +own connectivity loss) can be forgiven without permanent loss to Bob. + +Source: [eigenwallet/core PR #675](https://github.com/eigenwallet/core/pull/675) +(accessed 2026-05-22; archived in research vault). + +eigenwallet shipped a related-but-narrower mechanism in v4.0.0 (2026-03-16): an +**anti-spam deposit** where Alice can withhold part of a refund for up to 30 +minutes then release with "mercy". PR #675 generalises this into a +protocol-level fee-burn with maker-set fraction. Source: +[eigenwallet/core release 4.0.0](https://github.com/eigenwallet/core/releases/tag/4.0.0) +(accessed 2026-05-22). + +## Direction dependence: where the fee-burn works and where it does not + +This is the central design question and the RFP applicants must address it +explicitly. + +The fee-burn mechanism prices the option held by **the party that locks first +and would walk via the refund branch**. In the deployed BTC-XMR direction (BTC +locks first, eigenwallet's PR #675 case): + +- Bob (BTC taker, locks first) is the party who can grief via refund. The + fee-burn forces him to forfeit `[A+B]` deposit on every refund. The free + option Bob holds at the Phase 1-to-Phase 2 boundary (between his BTC lock and + Alice's XMR lock) is now priced. +- Alice (XMR maker, locks second) holds a different option at the Phase + 2-to-Phase 3 boundary (between her XMR lock and Bob's reveal of the secret). + The fee-burn on Bob's refund branch does *nothing* to price this. Alice's + option is priced separately, either by her own conduct (she chose to lock + against Bob; her downside is lock-window opportunity cost on XMR) or by an + LEZ-side bond on her side (which RFP-022 Tier 2 cannot fully provide because + her XMR lock is not LEZ-observable). + +Trade-direction analysis: + +| Trade direction | Who locks first | Who locks second | Fee-burn prices whose option? | +| -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | +| **LEZ→BTC** (user wants BTC, maker holds BTC) | LEZ-side party locks first (if the LEZ↔BTC pair follows the eigenwallet convention) | BTC-side party locks second | Option of the LEZ-side party who walks via LEZ-side refund branch. **Workable** because LEZ has script. | +| **BTC→LEZ** (user wants LEZ-side asset, maker holds LEZ asset) | BTC-side party locks first | LEZ-side party locks second | Option of the BTC-side party who walks via BTC-side refund branch. **Workable** because Bitcoin has script (PR #675 demonstrates the construction). | +| **LEZ→XMR** (user wants XMR, maker holds XMR) | LEZ-side party locks first (deployed eigenwallet convention has BTC first; for LEZ↔XMR, LEZ takes the BTC role as the script-bearing side) | XMR-side party locks second | Option of the LEZ-side party who walks via LEZ-side refund branch. **Workable** because LEZ has script. The fee-burn lives on LEZ. | +| **XMR→LEZ** (user wants LEZ-side asset, maker holds LEZ asset) | LEZ-side party still locks first (same as above by primitive role) | XMR-side party locks second | Same as above: fee-burn lives on the LEZ side. **Workable**. | + +**Where the fee-burn does not work**: the **reverse XMR-first variant** +described in Hoenisch and del Pino 2021 §4 (a CLSAG-adaptor-signature +construction where the XMR-side party locks first). In that variant the +locked-first leg is on Monero, which has no script; a Monero-side fee-burn on +the refund branch is not constructible because Monero has no refund-branch +script at all (Gugger 2020 §3.1: "Monero does not require any particular +on-chain primitives (hashlocks, timelocks)"). For this direction, the fee-burn +approach is structurally infeasible until non-disclosing Monero proof primitives +(FCMP++) ship and allow lock state to be verified on a script-bearing chain. + +**Where the fee-burn also does not work**: it does not price the +**second-locker's option** (the party who waits, sees the first lock, and +chooses whether to advance). That option lives on the no-fee-burn side of the +swap. For the BTC-XMR deployed direction, this is Alice's pre-XMR-lock option +(which she does not face as a real risk: walking away pre-lock costs her nothing +beyond the cancelled quote). For the LEZ↔XMR cases, Alice's pre-XMR-lock walk is +the residual non-bond-priceable option from RFP-022 Tier 2; the fee-burn does +not address it either. + +## Desired properties + +- **No on-LEZ bond required for the core mechanic.** The fee-burn lives in the + external-chain script; LEZ is uninvolved in the option-pricing instrument + itself. This is the structural difference from RFP-022. +- **Maker-set fraction.** Each maker chooses the deposit fraction per quote (a + percentage of the locked amount, configurable in the maker daemon analogous to + `ask_spread`). Takers see the fraction before initiating; choose not to trade + if the fraction is too high. +- **Burn destination is not the counterparty.** The deposit is sent to an + unspendable output (or to a 2-of-2 spend conditional on a transaction that + neither party will ever sign in equilibrium). This prevents the maker from + having an incentive to provoke refunds to collect the deposit. +- **Mercy path.** The maker can release the deposit back to the taker after + withholding it, so honest refunds (e.g. connectivity loss on either side) can + be forgiven. This is the analogue of bond-refund-on-honest-completion in + RFP-022. +- **Dominates the LEZ bond on Tier 2 (LEZ↔XMR).** Because the fee-burn lives on + the script-bearing chain where the refund-branch transaction itself is the + trigger, it prices the off-LEZ residual option that RFP-022's bond cannot. + Tier 2 swaps gain a real option-pricing mechanism (rather than only reputation + \+ market competition). +- **Layerable with RFP-023.** Maker reputation gates which fraction takers will + accept from which makers; takers building reputation can be offered lower + fractions over time. Reputation reduces the friction; fee-burn protects the + maker against new-identity griefing. + +## High-level functionality and flow + +```mermaid +sequenceDiagram + autonumber + participant A as Alice (maker) + participant LEZ as LEZ swap contract + participant Ext as External chain + participant B as Bob (taker) + + Note over A,B: Phase 0 - Quote (with fee-burn parameter) + A->>B: Quote (price, expiry, swap_id, refund_fee_fraction) + + Note over A,Ext: Phase 1 - Lock-Ext (taker locks first; deployed direction) + B->>Ext: Lock to script with three exit paths:
(a) claim by Alice with secret
(b) partial-refund by Bob splits
[trade_amount] + [deposit = fee_fraction × trade_amount]
(c) Alice's punish path if Bob disappears + Ext-->>LEZ: Inclusion proof (verified by LEZ light client) + + Note over A,LEZ: Phase 2 - Lock-LEZ + A->>LEZ: Lock trade_amount conditioned on s + + Note over B,LEZ: Phase 3 - Reveal + B->>LEZ: Publish adaptor signature (reveals s) + A->>Ext: Use s to claim external-chain output + + Note over A,B: Or: Phase 2' - Cancel (refund branch) + B->>Ext: Publish TxPartialRefund:
[trade_amount] back to Bob immediately
[deposit] into intermediate output + Note over A,B: After short timelock (e.g. 30 min) + alt Maker forgives + A->>Ext: TxMercy: deposit released to Bob + else Maker withholds (deposit burns) + A->>Ext: TxWithhold (deposit becomes unspendable) + else Maker no-shows + B->>Ext: TxReclaim: deposit returned to Bob + end +``` + +The crucial detail: the deposit path is the *only* difference from a vanilla +refund. Honest completion is unchanged. Only the refund branch carries the +option premium. + +## Pros + +- **No LEZ capital lockup.** Takers and makers do not need LEZ-denominated + assets to participate. The mechanism works on any pair where the + script-bearing chain has refund-branch scripting. +- **Composable with the eigenwallet ecosystem.** Adopting the same construction + as eigenwallet PR #675 means the LEZ atomic-swap protocol can interoperate + with eigenwallet makers on the BTC-XMR pair. This is materially valuable for + the BTC-XMR direction specifically. +- **Maker-set, not protocol-set.** Each maker chooses their fee fraction; the + protocol does not impose a single rate. Markets discover the right fraction + over time. +- **Burn destination avoids incentive skew.** Unlike a "refund fee paid to + counterparty" design, the burn cannot motivate either party to grief the + other. The deposit going to an unspendable output (after mercy timeout) is + bounded loss for both sides. +- **Layerable with RFP-022 bonds.** A taker can post an LEZ bond *and* face a + fee-burn on the external chain. The compound cost of the abort branch is the + sum of the two. +- **Survives Monero-non-observability**: the fee-burn lives on the + script-bearing chain. LEZ does not need to witness anything on the Monero + side, so the LEZ↔XMR Tier 2 problem (from RFP-022) does not apply to the + fee-burn mechanism itself. + +## Cons + +- **Does not price the second-locker's option.** The fee-burn lives in the + first-locker's refund branch only. The option held by the second-locker (Alice + in the BTC-XMR direction, between her XMR lock and Bob's reveal) is not priced + by this mechanism. For full bilateral mitigation, layer with RFP-022 Tier 1 + (where both sides are LEZ-observable) or accept the asymmetry. +- **Does not work for XMR-first direction.** The reverse XMR-first variant + (Hoenisch and del Pino 2021 §4) requires Monero-side refund-branch scripting, + which does not exist. Pairs where the script-bearing side is unable to play + the locks-first role at all (currently none in this bundle) would also be + excluded. +- **Maker reputation is load-bearing.** The maker's mercy path is a + discretionary choice; in the limit, a malicious maker could withhold every + deposit and force burns. The deposit fraction must be sized small enough that + honest takers tolerate the worst-case loss, which constrains how much option + premium the mechanism can collect. Reputation (RFP-023) on the maker side is + the soft pressure that keeps mercy honest. +- **External-chain transaction-fee overhead.** The fee-burn protocol requires + multiple transactions on the external chain (cancel, partial-refund, withhold + or reclaim or mercy). At high external-chain fee regimes, the protocol's gas + cost competes with the deposit value. +- **Withhold/mercy/reclaim adds protocol surface.** Auditing and testing the + additional sub-protocol is a real engineering cost. eigenwallet PR #675 is the + reference, but adapting it to LEZ-paired swaps requires the LEZ-side analogue + (when LEZ takes the script-bearing role). +- **Not a bond.** The deposit is not slashed to the counterparty (by design); + the protocol cannot use the deposit to *compensate* the wronged party. + Compensation requires RFP-022's on-LEZ bond mechanism layered on top. + +## Risks + +- **Withhold-mercy race conditions.** The + Alice-withholds-then-mercifully-releases path must be atomic from a UX + perspective; partial-protocol-completion (Alice withholds and disappears + without mercy or final burn) leaves the deposit in limbo. Mitigation: design + the deposit script so that Bob's reclaim path is always available after a hard + deadline regardless of Alice's actions. PR #675 already has this property (the + 30-min timelock to `TxReclaim`). +- **Fraction-too-high griefing of takers.** A malicious maker could post an + unreasonably high deposit fraction in their quote, then trade-and-withhold to + permanently burn taker funds. Mitigation: discovery-layer fraction caps; + reputation-weighted fraction acceptance; protocol-level upper bound on the + deposit fraction (e.g. ≤ 20%). +- **Fraction-too-low under-pricing the option.** If the fraction is set below + the option's true value (`σ × √T × notional`), the abort branch is still + EV-positive for adversarial takers. Mitigation: applicants validate the + maker-set fraction against actual observed volatility; document a sizing + guidance comparable to the σ×√T×notional rule from the primer. +- **Coordinated fraction-collusion.** If most makers settle on the same fraction + (a Schelling point), takers cannot route around abusive levels. Mitigation: + discovery-layer transparency on per-maker fraction history; reputation rewards + for makers who use lower fractions and honour mercy. +- **External-chain fee-spike defeats burn economics.** During Bitcoin mempool + congestion, the cost of the refund-branch transactions can exceed the deposit + value. Mitigation: dynamic deposit-sizing relative to recent external-chain + fee rates; minimum-deposit floor. +- **Adoption fragmentation with eigenwallet.** If the LEZ-adapted fee-burn + diverges from eigenwallet's PR #675 in non-backwards-compatible ways, LEZ + takers cannot route to eigenwallet makers and vice versa. Mitigation: + implement the same on-the-wire construction PR #675 specifies, with LEZ-side + script primitives substituted only where LEZ takes the BTC role. + +## Relationship to other RFPs in this bundle + +- **RFP-003 (Atomic Swaps with LEZ, open)** is the foundation. RFP-026 modifies + the refund branch of the per-pair atomic-swap construction; the joint-key + setup, lock, and reveal flow are inherited from RFP-003. +- **RFP-022 (bonded atomic swaps)** is the *substitute* option-pricing + mechanism. Both RFPs price the same free option but with different escrow + locations and different capital efficiency. RFP-022's LEZ bond is more + capital-efficient on Tier 1 (LEZ↔BTC, LEZ↔ETH) because it refunds on honest + completion. RFP-026's fee-burn is the only mechanism that can price the + residual off-LEZ option in Tier 2 (LEZ↔XMR). Applicants should propose the + fee-burn for Tier 2 only and let RFP-022 cover Tier 1, or justify why one + mechanism alone should cover both. +- **RFP-023 (reputation-based atomic swaps)** is the soft-pressure layer for the + maker's mercy path. A maker who systematically withholds (rather than + mercifully releases) earns reputation cost. RFP-023's slashable-event matrix + should be extended to record `mercy_path_invoked` and `withhold_to_burn` + separately. +- **RFP-021 (cross-chain privacy DEX)** is orthogonal: federated-custody middle + chains have no atomic-swap refund branch to attach a fee-burn to. The two + designs solve different problems. +- **RFP-024 (sXMR pure)** and **RFP-025 (sXMR with SLA)** could optionally adopt + the fee-burn on the redemption-leg atomic swap. RFP-024's LP economy would + benefit from refund-branch fee-burns reducing taker-side free-option exposure; + RFP-025 option 2a could layer fee-burn on top of the LP bond. + +## A note on the locks-first direction + +This RFP's fee-burn mechanism is constructively dependent on which side locks +first. The bundle (see RFP-022 overview and the +[atomic-swaps primer](../appendix/atomic-swaps-primer.md#locking-order)) treats +locking order as driven by the draining-attack economic analysis, not by the +cryptographic primitive. For the deployed BTC-XMR direction (Bob = BTC taker +locks first), the fee-burn lives on Bitcoin and works as PR #675 specifies. For +LEZ-paired swaps following the same convention (LEZ-side locks first), the +fee-burn lives on LEZ and is implemented via the LEZ-side escrow script. + +Applicants must: + +1. **State the locks-first direction explicitly** for each pair the RFP targets. + Default to the deployed convention (BTC-side / LEZ-side locks first); justify + any deviation. +2. **Show that the fee-burn lives on the locks-first chain.** The fee-burn + cannot be added to the second-locker's refund branch in a way that prices the + first-locker's option; the geometry of the protocol forbids it. +3. **Mark which trade directions the chosen pair handles.** A fee-burn on the + LEZ-side refund branch prices both LEZ→external and external→LEZ trade + directions (since LEZ locks first either way under the deployed convention). + A fee-burn on the BTC-side refund branch in a BTC-XMR pair only handles the + BTC-first direction; the reverse XMR-first direction is structurally + unaddressed by this mechanism. + +## References + +- [eigenwallet/core PR #675: fee-burn on refunds](https://github.com/eigenwallet/core/pull/675) + (accessed 2026-05-22; body archived in research vault) +- [eigenwallet/core release 4.0.0: anti-spam deposit (cancel timelock reduction + 30-minute withhold/mercy)](https://github.com/eigenwallet/core/releases/tag/4.0.0) + (accessed 2026-05-22) +- [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) +- [RFP-022: Bonded Atomic Swaps](./RFP-022-bonded-atomic-swaps.md) +- [RFP-023: Reputation-Based Atomic Swaps](./RFP-023-reputation-atomic-swaps.md) +- [appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) — + free-option framing and locking-order analysis +- [Han et al., On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) + (accessed 2026-05-22) +- [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) + (accessed 2026-05-22) +- [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332](https://arxiv.org/abs/2101.12332) + (accessed 2026-05-22) From 40ceb5d10b27c835ec3aad3ac65b38fd398b8916 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 22 May 2026 18:30:51 +1000 Subject: [PATCH 11/17] rfp: restructure bundle; add LP-0018 and LP-0019 lambda prizes Three RFPs removed; two lambda prizes added; remaining RFPs reframed around existing-project prior art. Removed RFPs: - RFP-022 (Bonded Atomic Swaps) - RFP-023 (Reputation-Based Atomic Swaps) - RFP-026 (Fee-Burn Atomic Swaps) These RFPs specified solutions to two open problems where the Logos team would rather not pre-judge the design. They were prescriptive about the mechanism (bonds, reputation primitives, fee-burns) when the more honest posture is to frame the problem and let solvers compete. New lambda prizes (staged in lambda-prizes/; to move to logos-co/lambda-prize when accepted): - LP-0018 (Anti-Spam Mechanism for Atomic Swaps): frames the taker-spam / free-option problem. References eigenwallet PR #675 as one example of reference prior art but does not prescribe the approach. Solvers may design bonds, fee-burns, reputation, deposits, slashing schemes, or any combination. Success criteria require non-custody preservation, incentive-compatibility argument, direction-coverage statement, and honest-refund handling. - LP-0019 (Off-Chain Verifiable Reputation for Atomic-Swap Makers): frames the off-chain attribution / verifiable-complaint problem. Lists naive view-key disclosure, FCMP++-grade zk proofs, multi-party attestation, and watchtower designs as candidates without prescribing the answer. Success criteria require sybil resistance, spam resistance, third-party verifiability without trusting the complainant, and complainant-side privacy. Reframed remaining RFPs around existing-project inspiration: - RFP-021: already cited Thorchain/Serai/Maya/Chainflip. Relationship section updated to point at LP-0018 and LP-0019 instead of the deleted RFP-022/023. - RFP-024: added "Inspired by existing prior art" paragraph naming Synthetix (CDP minting mechanic, SIP-302 Pools V3) and eigenwallet/ COMIT (peer-to-peer atomic-swap redemption). The novelty is the combination, not either half. Updated all cross-references to the deleted RFPs. - RFP-025: Option 2a now explicitly framed as inspired by Thorchain's bonded-validator model (operators post slashable stake against a defined performance contract); Option 2b explicitly framed as adopting sBTC's threshold-signer custody model with an oracle-priced peg layer. Both link to appendix-documented existing projects. - All references to RFP-022/023/026 replaced with pointers to LP-0018 or LP-0019 as appropriate. Appendix coverage check: every project named in the remaining RFPs (Thorchain, Serai, Maya, Chainflip, Wormhole, sBTC, Stacks, Synthetix, eigenwallet, COMIT, Farcaster, Haven, Liquality, AtomicDEX, Komodo, Secret Monero Bridge, Secret Network) is documented in at least one appendix (atomic-swaps-primer.md, cross-chain-trust-model-contrast.md, or synthetics-design-space.md). Decisions log (proposals-review/pr-57-decisions.md) appended with a "Bundle restructure 2026-05-22 (afternoon)" section summarising the shift. Deferred bond-system review findings (#3, #4, #5, #6, #7, #8, #12, #14) are no longer relevant since the bonded-atomic-swap design they applied to has been removed. Co-Authored-By: Claude Opus 4.7 (1M context) --- RFPs/RFP-021-cross-chain-privacy-dex.md | 221 +++++++-- RFPs/RFP-022-bonded-atomic-swaps.md | 429 ------------------ RFPs/RFP-023-reputation-atomic-swaps.md | 374 --------------- RFPs/RFP-024-synthetic-xmr-pure.md | 65 ++- RFPs/RFP-025-synthetic-xmr-sla.md | 120 +++-- RFPs/RFP-026-fee-burn-atomic-swaps.md | 386 ---------------- .../LP-0018-atomic-swap-anti-spam.md | 277 +++++++++++ .../LP-0019-atomic-swap-maker-reputation.md | 287 ++++++++++++ 8 files changed, 852 insertions(+), 1307 deletions(-) delete mode 100644 RFPs/RFP-022-bonded-atomic-swaps.md delete mode 100644 RFPs/RFP-023-reputation-atomic-swaps.md delete mode 100644 RFPs/RFP-026-fee-burn-atomic-swaps.md create mode 100644 lambda-prizes/LP-0018-atomic-swap-anti-spam.md create mode 100644 lambda-prizes/LP-0019-atomic-swap-maker-reputation.md diff --git a/RFPs/RFP-021-cross-chain-privacy-dex.md b/RFPs/RFP-021-cross-chain-privacy-dex.md index 391b719..f331dd3 100644 --- a/RFPs/RFP-021-cross-chain-privacy-dex.md +++ b/RFPs/RFP-021-cross-chain-privacy-dex.md @@ -9,25 +9,60 @@ category: Applications & Integrations # RFP-021 — Cross-Chain Privacy DEX (Federated Middle Layer) -> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos team and the community compare cross-chain DEX designs across RFP-021 through RFP-025. Hard requirements, team profile, timeline, and contracting details are deliberately omitted; they will be filled in if the design is selected for funding. +> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos +> team and the community compare cross-chain DEX designs across RFP-021 through +> RFP-025. Hard requirements, team profile, timeline, and contracting details +> are deliberately omitted; they will be filled in if the design is selected for +> funding. ## 🧭 Overview -Build a cross-chain privacy DEX on LEZ that custodies external assets (BTC, ETH, XMR, and others) via a threshold signature scheme held by the LEZ validator set, executes swaps natively against an AMM, and adds LEZ-specific privacy primitives (shielded swap intents, sealed-bid batch matching, stealth outbound addresses) that the existing comparators (Thorchain, Serai, Maya, Chainflip) do not offer. - -The design follows the **federated-signer middle chain** pattern that Thorchain (over $120B cumulative volume since 2021 per DefiLlama, accessed 2026-05-21) and Serai (pre-mainnet, post-cryptographic-audit by Cypher Stack in May 2025) have converged on. RFP-021 inherits that pattern's well-understood AMM-style liquidity and one-step user experience, then layers LEZ's privacy execution primitives on top to close the privacy gap that every comparator leaves open: even Serai's middle-chain state is publicly readable, and Thorchain's source-chain memos link source and destination addresses on transparent ledgers before the middle chain even sees them. - -This is the most ambitious option in the cross-chain bundle. It is also the one with the strongest empirical case (volume, user experience, asset coverage) and the strongest custody risk. +Build a cross-chain privacy DEX on LEZ that custodies external assets (BTC, ETH, +XMR, and others) via a threshold signature scheme held by the LEZ validator set, +executes swaps natively against an AMM, and adds LEZ-specific privacy primitives +(shielded swap intents, sealed-bid batch matching, stealth outbound addresses) +that the existing comparators (Thorchain, Serai, Maya, Chainflip) do not offer. + +The design follows the **federated-signer middle chain** pattern that Thorchain +(over $120B cumulative volume since 2021 per DefiLlama, accessed 2026-05-21) and +Serai (pre-mainnet, post-cryptographic-audit by Cypher Stack in May 2025) have +converged on. RFP-021 inherits that pattern's well-understood AMM-style +liquidity and one-step user experience, then layers LEZ's privacy execution +primitives on top to close the privacy gap that every comparator leaves open: +even Serai's middle-chain state is publicly readable, and Thorchain's +source-chain memos link source and destination addresses on transparent ledgers +before the middle chain even sees them. + +This is the most ambitious option in the cross-chain bundle. It is also the one +with the strongest empirical case (volume, user experience, asset coverage) and +the strongest custody risk. ## Desired properties -- **Native cross-chain swap.** User deposits BTC, ETH, or XMR; receives the destination asset on the destination chain in a single user action. No wrapped tokens linger on LEZ after the swap. -- **AMM-style liquidity.** A single ordered state machine maintains pool invariants (`xy=k` or comparable). Large swaps clear against pooled liquidity, not against a per-trade counterparty. -- **One-step UX.** Deposit-with-memo, await outbound. No counterparty interactivity, no refund flows, no online-availability requirement past broadcast. -- **Bonded validator set with slashable misbehaviour.** Validators stake against the assets they custody; the bond-to-custodied-value ratio is enforced in protocol (Serai uses a 33% custody cap; Thorchain uses 2:1 bonded plus 1:1 pooled). -- **LEZ-native privacy execution.** Shielded swap intents (the user's swap is a commitment, not a public memo); sealed-bid batch matching with threshold decryption (collapses identity-based front-running); stealth outbound addresses on destination chains (breaks destination-chain clustering even for chains with no native privacy). -- **Permissioned-by-stake but censorship-resistant.** Anyone can join the validator set by posting the required stake; validator-set rotation occurs on a known cadence (Thorchain churns every 3 days; Serai per session). -- **Emergency halt mechanism.** Used three times in Thorchain's history; the protocol must be able to freeze outbounds on suspected custody compromise or consensus fault. +- **Native cross-chain swap.** User deposits BTC, ETH, or XMR; receives the + destination asset on the destination chain in a single user action. No wrapped + tokens linger on LEZ after the swap. +- **AMM-style liquidity.** A single ordered state machine maintains pool + invariants (`xy=k` or comparable). Large swaps clear against pooled liquidity, + not against a per-trade counterparty. +- **One-step UX.** Deposit-with-memo, await outbound. No counterparty + interactivity, no refund flows, no online-availability requirement past + broadcast. +- **Bonded validator set with slashable misbehaviour.** Validators stake against + the assets they custody; the bond-to-custodied-value ratio is enforced in + protocol (Serai uses a 33% custody cap; Thorchain uses 2:1 bonded plus 1:1 + pooled). +- **LEZ-native privacy execution.** Shielded swap intents (the user's swap is a + commitment, not a public memo); sealed-bid batch matching with threshold + decryption (collapses identity-based front-running); stealth outbound + addresses on destination chains (breaks destination-chain clustering even for + chains with no native privacy). +- **Permissioned-by-stake but censorship-resistant.** Anyone can join the + validator set by posting the required stake; validator-set rotation occurs on + a known cadence (Thorchain churns every 3 days; Serai per session). +- **Emergency halt mechanism.** Used three times in Thorchain's history; the + protocol must be able to freeze outbounds on suspected custody compromise or + consensus fault. ## High-level functionality and flow @@ -60,59 +95,145 @@ flowchart TB Execution -->|"queued outbounds signed via TSS"| Vaults ``` -**Happy path.** User sends BTC to a vault address on Bitcoin, carrying a memo (or, with LEZ privacy primitives, a commitment) that specifies the destination asset and address. LEZ validators observe the deposit, reach consensus via their consensus protocol, route the swap through the appropriate AMM pool, queue the outbound, and the threshold signature group co-signs an outbound transaction on the destination chain. Outbound is broadcast to a stealth address derived from the destination address. Total wall-clock time: source-chain finality plus LEZ consensus plus destination-chain finality, typically minutes. +**Happy path.** User sends BTC to a vault address on Bitcoin, carrying a memo +(or, with LEZ privacy primitives, a commitment) that specifies the destination +asset and address. LEZ validators observe the deposit, reach consensus via their +consensus protocol, route the swap through the appropriate AMM pool, queue the +outbound, and the threshold signature group co-signs an outbound transaction on +the destination chain. Outbound is broadcast to a stealth address derived from +the destination address. Total wall-clock time: source-chain finality plus LEZ +consensus plus destination-chain finality, typically minutes. -**Validator-set churn.** On a fixed cadence, the protocol runs a distributed key generation for the next validator set and migrates vault balances from old keys to new keys. New validators bond their stake; departing validators recover their bond after a vesting period. +**Validator-set churn.** On a fixed cadence, the protocol runs a distributed key +generation for the next validator set and migrates vault balances from old keys +to new keys. New validators bond their stake; departing validators recover their +bond after a vesting period. -**Misbehaviour path.** Failed keygen, failed keysign, observed double-spend attempts, or chain-attributable malfeasance trigger slashing of the responsible validator's bond. Slashing amounts and trigger conditions are protocol-defined. +**Misbehaviour path.** Failed keygen, failed keysign, observed double-spend +attempts, or chain-attributable malfeasance trigger slashing of the responsible +validator's bond. Slashing amounts and trigger conditions are protocol-defined. -**Emergency path.** A `halt` mechanism (Thorchain's `make halt` precedent; Serai uses session-level rollback during DKG failure) freezes outbounds on suspected solvency or signing failure. +**Emergency path.** A `halt` mechanism (Thorchain's `make halt` precedent; Serai +uses session-level rollback during DKG failure) freezes outbounds on suspected +solvency or signing failure. ## Pros -- **Highest deployed-volume model.** Thorchain has cleared over $120B cumulative cross-chain volume since 2021 ([DefiLlama Thorchain DEX](https://defillama.com/protocol/thorchain-dex), accessed 2026-05-21). The AMM-style middle-chain pattern wins on liquidity gravity and user experience over every atomic-swap competitor. -- **Sub-block-time settlement on the middle chain.** Only destination-chain finality and the TSS keysign delay the outbound. No multi-hour timelock windows. -- **Arbitrary asset pairs.** Pair coverage is reduced to "does the validator set run an observer for chain X". BTC, ETH, XMR all in scope at launch. -- **Cryptoeconomic recourse.** Misbehaviour is slashable. The economic security argument is explicit and bounded. -- **LEZ privacy execution is a real differentiator.** No comparator offers shielded swap intents, sealed-bid batch matching, or stealth outbound addresses. This is the precise gap LEZ can fill. -- **Composable with the rest of LEZ.** The protocol-owned vault assets can back lending markets, structured products, and so on, on the same LEZ. +- **Highest deployed-volume model.** Thorchain has cleared over $120B cumulative + cross-chain volume since 2021 + ([DefiLlama Thorchain DEX](https://defillama.com/protocol/thorchain-dex), + accessed 2026-05-21). The AMM-style middle-chain pattern wins on liquidity + gravity and user experience over every atomic-swap competitor. +- **Sub-block-time settlement on the middle chain.** Only destination-chain + finality and the TSS keysign delay the outbound. No multi-hour timelock + windows. +- **Arbitrary asset pairs.** Pair coverage is reduced to "does the validator set + run an observer for chain X". BTC, ETH, XMR all in scope at launch. +- **Cryptoeconomic recourse.** Misbehaviour is slashable. The economic security + argument is explicit and bounded. +- **LEZ privacy execution is a real differentiator.** No comparator offers + shielded swap intents, sealed-bid batch matching, or stealth outbound + addresses. This is the precise gap LEZ can fill. +- **Composable with the rest of LEZ.** The protocol-owned vault assets can back + lending markets, structured products, and so on, on the same LEZ. ## Cons -- **Custody risk is real and realised.** Thorchain's GG20 TSS vault was drained on 2026-05-15 ($10.8M) via a TSSHOCK-class implementation weakness. Wormhole's Solana bridge was drained on 2022-02-02 ($326M) via a per-chain contract bug (`load_instruction_at`); Jump Crypto re-deposited the loss out of pocket. The federated middle-chain pattern has a non-zero historical loss rate. -- **Signer federation is a chokepoint.** Validators are identifiable; the validator set is a target for out-of-protocol pressure (legal, regulatory, kinetic). The federation cannot be made "fully decentralised" in the sense that an atomic-swap design can. -- **Pre-economic-security bootstrap.** Serai's mint-on-bootstrap design illustrates that the slashable-bond argument does not bind until the validator-stake pool catches up with custody. The launch window is a real risk. -- **XMR privacy compromise.** Any TSS custody of Monero is necessarily view-key-shared: the validator set learns the LEZ-side Monero deposit history. This is the same compromise Serai accepts (FROSTLASS over CLSAG); it must be called out plainly to users, not papered over. -- **Engineering surface is large.** Building a new chain, a per-external-chain observer fleet, a TSS scheme with serious audit posture, churn/migration logic, and an emergency halt is a multi-year programme. Serai took roughly five years from inception (around 2021) to post-cryptographic-audit pre-mainnet status (Cypher Stack audits completed May 2025; mainnet not yet launched as of 2026-05-21). +- **Custody risk is real and realised.** Thorchain's GG20 TSS vault was drained + on 2026-05-15 ($10.8M) via a TSSHOCK-class implementation weakness. Wormhole's + Solana bridge was drained on 2022-02-02 ($326M) via a per-chain contract bug + (`load_instruction_at`); Jump Crypto re-deposited the loss out of pocket. The + federated middle-chain pattern has a non-zero historical loss rate. +- **Signer federation is a chokepoint.** Validators are identifiable; the + validator set is a target for out-of-protocol pressure (legal, regulatory, + kinetic). The federation cannot be made "fully decentralised" in the sense + that an atomic-swap design can. +- **Pre-economic-security bootstrap.** Serai's mint-on-bootstrap design + illustrates that the slashable-bond argument does not bind until the + validator-stake pool catches up with custody. The launch window is a real + risk. +- **XMR privacy compromise.** Any TSS custody of Monero is necessarily + view-key-shared: the validator set learns the LEZ-side Monero deposit history. + This is the same compromise Serai accepts (FROSTLASS over CLSAG); it must be + called out plainly to users, not papered over. +- **Engineering surface is large.** Building a new chain, a per-external-chain + observer fleet, a TSS scheme with serious audit posture, churn/migration + logic, and an emergency halt is a multi-year programme. Serai took roughly + five years from inception (around 2021) to post-cryptographic-audit + pre-mainnet status (Cypher Stack audits completed May 2025; mainnet not yet + launched as of 2026-05-21). ## Risks -- **TSS implementation failure.** The 2026-05-15 Thorchain incident is the canonical example. Mitigation: choose FROST over GG20 (Serai's choice, and the lesson Thorchain's incident reinforces); budget for at least one Cypher Stack-equivalent audit of the chosen scheme; design with FROSTLASS-grade Monero support from the start rather than retrofitting. -- **Per-external-chain contract risk.** Wormhole's 2022 incident bypassed rather than broke the trust model: a Solana-side `load_instruction_at` bug let an attacker forge VAAs. Every integrated chain adds an attack surface independent of the LEZ consensus. Mitigation: minimise per-chain on-chain components; lean on TSS-signed outputs to chains with no LEZ-deployed contract. -- **Validator-set capture.** A small or homogeneous validator set is a censorship and coercion target. Mitigation: stake-weighted permissionless entry; geographic and jurisdictional diversity as a soft target. -- **Pre-mainnet economic-security gap.** Slashable-bond security depends on stake value catching up with custody value. Mitigation: explicit caps on custody until the bond-to-custodied ratio binds; transparent on-protocol ratio enforcement (Thorchain's Incentive Pendulum is one mechanism). -- **Regulatory exposure on XMR custody.** Holding XMR in a protocol-owned vault attracts more scrutiny than holding BTC. Mitigation: validator geographic diversity; documented privacy posture; clear separation between protocol governance and individual validator entities. -- **Privacy claim overreach.** The LEZ privacy primitives close the public-ledger linkability gap but do not protect against an honest-but-curious validator set. The threat model must be documented honestly so users do not assume "private" means "the validators learn nothing". +- **TSS implementation failure.** The 2026-05-15 Thorchain incident is the + canonical example. Mitigation: choose FROST over GG20 (Serai's choice, and the + lesson Thorchain's incident reinforces); budget for at least one Cypher + Stack-equivalent audit of the chosen scheme; design with FROSTLASS-grade + Monero support from the start rather than retrofitting. +- **Per-external-chain contract risk.** Wormhole's 2022 incident bypassed rather + than broke the trust model: a Solana-side `load_instruction_at` bug let an + attacker forge VAAs. Every integrated chain adds an attack surface independent + of the LEZ consensus. Mitigation: minimise per-chain on-chain components; lean + on TSS-signed outputs to chains with no LEZ-deployed contract. +- **Validator-set capture.** A small or homogeneous validator set is a + censorship and coercion target. Mitigation: stake-weighted permissionless + entry; geographic and jurisdictional diversity as a soft target. +- **Pre-mainnet economic-security gap.** Slashable-bond security depends on + stake value catching up with custody value. Mitigation: explicit caps on + custody until the bond-to-custodied ratio binds; transparent on-protocol ratio + enforcement (Thorchain's Incentive Pendulum is one mechanism). +- **Regulatory exposure on XMR custody.** Holding XMR in a protocol-owned vault + attracts more scrutiny than holding BTC. Mitigation: validator geographic + diversity; documented privacy posture; clear separation between protocol + governance and individual validator entities. +- **Privacy claim overreach.** The LEZ privacy primitives close the + public-ledger linkability gap but do not protect against an honest-but-curious + validator set. The threat model must be documented honestly so users do not + assume "private" means "the validators learn nothing". ## Relationship to other RFPs in this bundle -- **RFP-003 (Atomic Swaps with LEZ, open)** is the baseline atomic-swap RFP. RFP-021 is the structural alternative: federated middle layer instead of bilateral atomic swap. The two coexist: RFP-021 handles the high-liquidity bulk path; RFP-003 (and its evolutions RFP-022 and RFP-023) cover the non-custodial niche. -- **RFP-004 (Privacy-Preserving DEX, open)** is a *single-chain* shielded DEX on LEZ. RFP-021 is *cross-chain* with vault custody. Distinct scopes; the two could ship in parallel and serve different user journeys (intra-LEZ shielded trading vs cross-chain settlement). -- **RFP-022 (bonded atomic swaps)** and **RFP-023 (reputation-based atomic swaps)** are the non-custodial alternatives. They preserve cryptographic non-custody at the cost of multi-hour settlement and counterparty interactivity. RFP-021 sacrifices non-custody for AMM-style liquidity and one-step UX. The Logos design space is broad enough to ship both modes. -- **RFP-024 (sXMR pure)** and **RFP-025 (sXMR with SLA)** target a different product: synthetic XMR exposure inside LEZ DeFi, with atomic-swap redemption to real XMR. They are orthogonal to RFP-021 and could ship alongside it, sharing the same LEZ privacy primitives. - -See [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) for the full federated-signers vs atomic-swaps trust analysis that motivates this RFP's place in the bundle. +- **RFP-003 (Atomic Swaps with LEZ, open)** is the structural alternative: + bilateral atomic swap instead of federated middle layer. The two coexist: + RFP-021 handles the high-liquidity bulk path with AMM-style liquidity; RFP-003 + covers the non-custodial niche with multi-hour settlement and counterparty + interactivity. RFP-003's known economic gaps (taker spam, free-option + exploitation, off-chain maker reputation) are addressed by lambda prizes + LP-0018 and LP-0019; RFP-021 sidesteps those problems by design. +- **RFP-004 (Privacy-Preserving DEX, open)** is a *single-chain* shielded DEX on + LEZ. RFP-021 is *cross-chain* with vault custody. Distinct scopes; the two + could ship in parallel and serve different user journeys (intra-LEZ shielded + trading vs cross-chain settlement). +- **RFP-024 (sXMR pure)** and **RFP-025 (sXMR with SLA)** target a different + product: synthetic XMR exposure inside LEZ DeFi, with atomic-swap redemption + to real XMR. They are orthogonal to RFP-021 and could ship alongside it, + sharing the same LEZ privacy primitives. + +See +[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) +for the full federated-signers vs atomic-swaps trust analysis that motivates +this RFP's place in the bundle. ## References -- [DefiLlama Thorchain DEX (volume figures)](https://defillama.com/protocol/thorchain-dex) (accessed 2026-05-21) +- [DefiLlama Thorchain DEX (volume figures)](https://defillama.com/protocol/thorchain-dex) + (accessed 2026-05-21) - [Serai AMM docs](https://docs.serai.exchange/amm/) (accessed 2026-05-21) -- [Serai blog: Announcing monero-oxide (2025-09-09)](https://serai.exchange/2025/09/09/monero-serai-oxide.html) (accessed 2026-05-21) -- [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md) (accessed 2026-05-21) -- [Serai blog: How Far We've Come (2023-10-06)](https://serai.exchange/2023/10/06/how-far-weve-come.html) (accessed 2026-05-21) -- [Thorchain Medium: Why Cross-Chain bridges are superior to Atomic Swaps (2019)](https://medium.com/thorchain/why-cross-chain-bridges-are-superior-to-atomic-swaps-aebde263103c) (accessed 2026-05-21) -- [Thorchain docs: Continuous Liquidity Pools](https://docs.thorchain.org/technical-documentation/thorchain-finance/continuous-liquidity-pools) (accessed 2026-05-21) -- [Thorchain docs: RUNE (bond-to-pooled ratio)](https://docs.thorchain.org/understanding-thorchain/rune) (accessed 2026-05-21) -- [Crypto Times: $10.8M drained from Thorchain on 2026-05-15](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) (accessed 2026-05-21) -- [Halborn: Wormhole Hack February 2022](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) (accessed 2026-05-21) -- [FROST: Flexible Round-Optimized Schnorr Threshold Signatures (Komlo and Goldberg, SAC 2020 / IACR 2020/852)](https://eprint.iacr.org/2020/852) (accessed 2026-05-21) +- [Serai blog: Announcing monero-oxide (2025-09-09)](https://serai.exchange/2025/09/09/monero-serai-oxide.html) + (accessed 2026-05-21) +- [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md) + (accessed 2026-05-21) +- [Serai blog: How Far We've Come (2023-10-06)](https://serai.exchange/2023/10/06/how-far-weve-come.html) + (accessed 2026-05-21) +- [Thorchain Medium: Why Cross-Chain bridges are superior to Atomic Swaps (2019)](https://medium.com/thorchain/why-cross-chain-bridges-are-superior-to-atomic-swaps-aebde263103c) + (accessed 2026-05-21) +- [Thorchain docs: Continuous Liquidity Pools](https://docs.thorchain.org/technical-documentation/thorchain-finance/continuous-liquidity-pools) + (accessed 2026-05-21) +- [Thorchain docs: RUNE (bond-to-pooled ratio)](https://docs.thorchain.org/understanding-thorchain/rune) + (accessed 2026-05-21) +- [Crypto Times: $10.8M drained from Thorchain on 2026-05-15](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) + (accessed 2026-05-21) +- [Halborn: Wormhole Hack February 2022](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022) + (accessed 2026-05-21) +- [FROST: Flexible Round-Optimized Schnorr Threshold Signatures (Komlo and Goldberg, SAC 2020 / IACR 2020/852)](https://eprint.iacr.org/2020/852) + (accessed 2026-05-21) diff --git a/RFPs/RFP-022-bonded-atomic-swaps.md b/RFPs/RFP-022-bonded-atomic-swaps.md deleted file mode 100644 index 734512d..0000000 --- a/RFPs/RFP-022-bonded-atomic-swaps.md +++ /dev/null @@ -1,429 +0,0 @@ ---- -id: RFP-022 -title: Bonded Atomic Swaps (Two Tiers) -tier: XL -funding: $TBD -status: draft -category: Applications & Integrations ---- - -# RFP-022 — Bonded Atomic Swaps (Two Tiers) - -> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos -> team and the community compare cross-chain DEX designs across RFP-021 through -> RFP-025. Hard requirements, team profile, timeline, and contracting details -> are deliberately omitted; they will be filled in if the design is selected for -> funding. - -## 🧭 Overview - -Extend RFP-003 (Atomic Swaps with LEZ, open) with a maker/taker bond layer on -LEZ that constrains the free-option problem inherent to atomic swaps. Bonds are -posted on LEZ in stables or LEZ-native assets; slashing is conditioned on -LEZ-observable failures to advance through the swap state machine. - -The bond is the **price of the free option** the protocol structurally creates -at each phase boundary. The locker is short an option (their leg is committed -for a window during which the counterparty can observe the market); the -counterparty is long the option. The bond is posted by the long-option party; on -default (exercising the abort branch) it slashes to the locker, settling the -option premium. On honest completion the bond refunds (option expired worthless, -no premium owed). Bond sized at or above option value (`σ × √T × notional`; see -[atomic-swaps primer](../appendix/atomic-swaps-primer.md#notation-for-option-value)) -makes the abort branch EV-negative and closes the free option. - -Locking order is driven by the **draining-attack economic analysis** (Hoenisch -and del Pino 2021 §4): the party who locks first incurs the on-chain -refund-transaction fee under adversarial counterparty behaviour, so the party -who can absorb that cost should lock first. See -[atomic-swaps primer §How locking order generalises across pairs](../appendix/atomic-swaps-primer.md#how-locking-order-generalises-across-pairs). -The choice is *not* fixed by the cryptographic primitive; reverse variants are -constructible given the appropriate adaptor-signature primitives on each chain. -For the worked examples below, Alice is the BTC-side party and locks first on -the external chain (matching the deployed COMIT/eigenwallet convention); Bob is -the LEZ-side party and locks second on LEZ. Applicants targeting other pairs -(LEZ↔ETH especially, where both chains have full scripting) must state the -locking-order choice explicitly and justify it against the draining-attack -analysis. - -The design splits into two tiers that reflect a structural asymmetry in the -underlying cryptography: - -- **Tier 1 (LEZ to BTC, LEZ to ETH).** Both sides' locks are verifiable on LEZ - via a chain-watching light-client module. Both Alice's and Bob's bonds are - slashable on default; full bilateral free-option mitigation. -- **Tier 2 (LEZ to XMR).** Alice's XMR lock cannot be proven on LEZ without - revealing either the per-tx private key or the recipient view key (plus the - output blinding factor), each of which is sufficient to deanonymise the swap - output once submitted to world-readable LEZ state. Monero's bilateral - `check_tx_proof` (OutProofV2 or InProofV2 variants per - [Zero to Monero 2.0 §Payment Proofs](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf)) - is the canonical disclosure-requiring proof; no SPV-style alternative exists - pre-FCMP++. Bob's lock (on LEZ) remains observable, so Bob's bond is - slashable; Alice's bond is slashable only on her LEZ-observable abandonment - (failure to reveal after Bob has locked Logos). Alice keeps a residual - pre-XMR-lock free option that only reputation (RFP-023) can constrain. - -The Bond layer is a strict superset of RFP-003. Builders should consume the -per-pair SDKs from RFP-003 unchanged; this RFP adds the bond escrow contract, -the bond accounting, and the LEZ-side proof verification primitives. - -## Desired properties - -- **Non-custodial.** No vault holds external assets; no signer set. Bonds live - in LEZ-native assets on LEZ. -- **Free-option mitigation (Tier 1).** Symmetric bonding makes both sides' - optionality strictly EV-negative when bonds are sized above the option value - (`σ × √T × notional` is the standard option-pricing heuristic; an indicative - range is 2 to 5% of trade notional for 1-hour windows, to be validated by - applicants against actual observed BTC/ETH volatility). -- **Free-option mitigation (Tier 2).** Bob's optionality is closed by his - slashable bond. Alice's post-Bob-lock optionality is closed by her bond. - Alice's pre-XMR-lock optionality is *not* closed; this is the structural limit - of the asymmetry. -- **Unauthenticated proof submitter.** Either party can broadcast the other's - signed lock transaction (broadcasting is permissionless on every supported - chain). The LEZ inclusion-proof submitter is also unauthenticated. This - eliminates "attest or be slashed" grief vectors: a malformed lock simply never - lands, the state machine times out, no slashing dispute occurs. -- **Bondless taker entry path.** First-time takers can complete a capped first - swap (worked example: US$100 equivalent notional) without posting a taker - bond. After the first swap, the taker has LEZ-denominated assets they can post - as bond against larger swap sizes. This is enforceable by the LEZ escrow - program directly; no reputation registry needed. -- **Upgrade clause for Tier 2.** When a non-disclosing Monero proof primitive - becomes production-ready (FCMP++ or equivalent; in specification phase per - [Monero, FCMP++ announcement, 2024-04-27](https://www.getmonero.org/2024/04/27/fcmps.html), - accessed 2026-05-21), Tier 2 collapses into Tier 1: Alice's XMR lock becomes - verifiable on LEZ without view-key disclosure, and the residual free option - closes. -- **Composes with RFP-023 reputation.** Maker reputation (and - zk-membership-proof taker reputation if available) compounds the cost of - defection. In Tier 2 specifically, taker reputation is load-bearing because it - is the only restraint on Alice's pre-lock free option. - -## High-level functionality and flow - -### Tier 1: LEZ to BTC (example) - -Bond notation: - -- `B_alice` = Alice's full bond, posted on LEZ at Commit. -- `B_bob` = Bob's full bond, posted on LEZ at Commit. - -Both bonds are posted before any external-chain lock, so the bonds are always -already on LEZ when slash conditions trigger. No phase-by-phase bond slicing; -each phase boundary creates an option that one of the two bonds prices. - -```mermaid -sequenceDiagram - participant Alice - participant LEZ as LEZ swap contract - participant BTC as Bitcoin network - participant Bob - - Note over Alice,Bob: Phase 0 - Quote - Alice->>Bob: Quote request (Logos Delivery) - Bob->>Alice: Signed quote (price, expiry, swap_id, refund_pubkeys) - Note over Alice,Bob: Joint-key setup for 2-of-2 Taproot output - - Note over Alice,LEZ: Phase 1 - Commit (atomic, joint signature) - Alice->>LEZ: Post B_alice - Bob->>LEZ: Post B_bob - - Note over Alice,BTC: Phase 2 - Lock-BTC - Alice->>BTC: Broadcast BTC lock tx directly - BTC-->>LEZ: Inclusion proof (submitted by anyone:
headers + merkle + raw_tx) - LEZ->>LEZ: Verify PoW, inclusion, scriptpubkey, amount - Note over LEZ: Slash window opens
If Bob does not advance in window:
B_bob -> Alice - - Note over LEZ,Bob: Phase 3 - Lock-Logos - Bob->>LEZ: Lock trade_amount conditioned on s - - Note over Alice,LEZ: Phase 4 - Reveal - Alice->>LEZ: Publish adaptor signature (reveals s) - Note over LEZ: If Alice does not reveal in window:
B_alice -> Bob - - Note over Bob,BTC: Phase 5 - Settle - Bob->>BTC: Claim BTC using s - LEZ-->>Alice: Refund B_alice - LEZ-->>Bob: Refund B_bob -``` - -Notes on the table: - -- **Phase 1 is atomic.** Both bonds are posted in the same LEZ transaction, - jointly signed. Abandonment at this point looks like abandoning a quote: - nobody is committed yet, no on-chain advancement occurred, no slash applies. - This eliminates a 1a/1b split where one party posts and the other doesn't. -- **Phase 2 has no Bob-broadcasts hop.** Alice broadcasts the BTC lock directly. - The LEZ inclusion-proof submitter remains unauthenticated (Bob, Alice, or a - watchtower service can post the proof once the BTC tx confirms). If Alice - signs and broadcasts a malformed lock (wrong amount, wrong scriptpubkey), the - LEZ contract rejects the inclusion proof, the state machine times out, both - bonds refund. No slashing dispute, no fraud-proof window. The swap fails - closed because the precondition for state advancement (a real BTC lock - matching the swap parameters) never holds. -- **Phase 3 locks only `trade_amount`.** Bob's bond `B_bob` was posted at Phase - 1 and remains in the bond escrow; Phase 3 is a separate lock of trade capital, - not the bond. This resolves an earlier draft where `B_bob` appeared both - spendable (slashable in Phase 2) and locked (Phase 3) in the same model. - -### Option-pricing audit - -For each phase boundary, name (a) who is short the option, (b) who is long the -option, (c) the premium instrument that prices it: - -| Boundary | Short the option (waiting) | Long the option (deciding) | Premium instrument | -| --------------------------------------- | ------------------------------------------------- | ----------------------------------------- | ---------------------------------------------- | -| After Phase 2 (BTC locked, Logos not) | Alice (her BTC is wedged for the timelock window) | Bob (he chooses whether to lock Logos) | `B_bob`, slashes to Alice on Bob's no-advance | -| After Phase 3 (Logos locked, no reveal) | Bob (his Logos is wedged) | Alice (she chooses whether to reveal `s`) | `B_alice`, slashes to Bob on Alice's no-reveal | -| After Phase 4 (reveal published) | nobody (settlement is deterministic) | n/a | n/a | - -Bond sizing must satisfy -`B_bob ≥ option_value(σ_BTC/Logos × √T_phase2 × notional)` and -`B_alice ≥ option_value(σ_BTC/Logos × √T_phase3 × notional)`. See the primer for -the notation. - -The audit closes the structural worry "are we adding new free options with each -phase?" by accounting for them: every boundary is named, the option holder is -named, and the bond pricing it is named. Phases without a one-sided commitment -(Phase 0 Quote, Phase 1 atomic Commit, Phase 5 Settle) create no option and need -no premium. - -### Direction symmetry - -The same phase table runs for the LEZ→BTC direction (a user wanting BTC -initiates against a BTC-holding maker) and the BTC→LEZ direction (a user with -BTC initiates against a Logos-holding maker). The locking order (BTC first, then -LEZ) is fixed by the cryptographic primitive (see overview); only the -taker/maker labels move. Bond sizing and slash conditions are -direction-symmetric. The same applies to LEZ↔ETH once the lock-ordering choice -is fixed for that pair. - -### Tier 2: LEZ to XMR - -Same phase structure as Tier 1, with the following differences driven by -Monero's unverifiable lock state on LEZ: - -- **Phase 2 (Lock-XMR) is not LEZ-observable.** The state machine cannot - auto-transition from Commit to Lock-Logos based on Alice's Monero lock. Bob - detects Alice's lock by running a Monero wallet himself (Alice sends him the - bilateral `check_tx_proof` privately; this does *not* go on LEZ). Bob's - decision to advance to Lock-Logos is off-chain. -- **If Alice never locks XMR after Commit**, the state machine times out and - both bonds refund. There is no LEZ-observable default, so no slash applies. - Alice has paid only gas; she keeps her pre-XMR-lock free option. **This is the - residual asymmetry of Tier 2:** the option Bob bears at this boundary cannot - be priced by a bond, because the trigger event (Alice's XMR lock) is not - LEZ-observable. Maker market competition and reputation (RFP-023) are the only - available premium instruments. See "Open question" below. -- **Phase 3 onwards is identical to Tier 1.** Bob's lock on LEZ is observable. - Alice's bond `B_alice` slashes on failure to reveal after Bob's lock; Bob's - bond `B_bob` slashes on failure to complete after the reveal (per Tier 1 - mechanics). - -#### Option-pricing audit (Tier 2) - -| Boundary | Short the option | Long the option | Premium instrument | -| ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | -------------------------------------------- | ------------------------------------------------------------------------------------------- | -| After Phase 2 (XMR locked off-LEZ, Logos not locked) | Bob (he committed in good faith to source XMR; if Alice never locked, Bob saw nothing and waits out the timer) | Alice (chooses whether to actually lock XMR) | **None**. Trigger event not LEZ-observable. Reputation + market competition only (RFP-023). | -| After Phase 3 (Logos locked, no reveal) | Bob (his Logos is wedged) | Alice (chooses whether to reveal `s`) | `B_alice`, slashes to Bob on Alice's no-reveal | -| After Phase 4 (reveal published) | nobody | n/a | n/a | - -#### Direction symmetry (XMR↔LEZ) - -The same Tier-2 phase structure runs for both XMR→LEZ and LEZ→XMR. In both -directions, **the XMR-side party holds the unverifiable lock**: that's the -cryptographic constraint (Monero outputs cannot be proven to LEZ without -view-key disclosure). The roles flip relative to taker/maker but the -protocol-level asymmetry is the same: the XMR-side party is reputation-gated; -the LEZ-side party is bonded. - -For XMR→LEZ (a user wanting Logos pays in XMR): Alice in the table holds XMR; -the residual unpriced option is held by Alice; Bob (LEZ-side) is the party with -the on-chain bond that can be slashed if he fails to advance after Alice's XMR -lock — but Bob's failure-to-advance is what's not provable on LEZ. Same -asymmetry, mirrored. - -#### Open question: off-chain verifiable maker reputation - -Tier 2's residual unpriced option (Phase 2 boundary) is reputation-only. A -natural follow-up is whether the reputation signal can be made *verifiable* by -third parties off-chain, rather than relying purely on on-chain attestation plus -dispute fallback. This is treated as a reputation-mechanism question and the -discussion lives in -[RFP-023 §Off-chain verifiable maker reputation](./RFP-023-reputation-atomic-swaps.md#off-chain-verifiable-maker-reputation-lezxmr-open-question). -RFP-022 applicants should ensure the protocol primitives (anchored quote -signatures, deterministic stealth-address derivation, joint-key transcript -retention) make such a layer possible, even if the layer itself is left to -RFP-023. - -### Bondless taker entry path - -A taker without LEZ-denominated assets initiates a "first-swap" mode flagged in -the LEZ escrow program: - -- Trade notional capped at a small value (worked example: US$100 equivalent), - sized against expected free-option value at the protocol's typical lock - window. -- No taker bond required. -- After completion, the taker has LEZ-denominated assets in their account from - the swap proceeds. They can post these as bond against subsequent larger - swaps. -- The cap is enforced by the LEZ escrow program; no reputation registry is - required to make the cap binding. This decouples the bondless entry path from - the (more complex) reputation infrastructure in RFP-023. - -## Pros - -- **Closes the free-option problem cryptoeconomically for BTC and ETH (Tier - 1).** No bilateral counterparty trust, no third-party attestation, no - validator federation. The slash is enforced by the LEZ smart contract directly - off the on-chain state of both chains. -- **Preserves the non-custodial property of atomic swaps.** No vault to drain, - no TSS to break, no validator set to compromise. Funds never leave Alice's or - Bob's control during the swap. -- **Builds cleanly on RFP-003.** Per-pair SDKs and the LEZ-side Risc0 escrow - programs from RFP-003 are reused; this RFP layers on the bond escrow and the - proof verification primitives. The dependency chain is clean. -- **Material improvement for the LEZ to XMR pair (Tier 2) on the maker side.** - Bob's free option is closed even though Alice's lock is not verifiable on LEZ. - This unblocks a category of makers who today refuse to post against - atomic-swap takers because they can be free-optioned. -- **Bondless taker entry path solves the onboarding chicken-and-egg.** A - privacy-seeking taker arriving from XMR or BTC does not need to acquire LEZ - assets before their first swap. They complete a small first swap, accumulate - LEZ assets, and bond from there. No KYC-tolerant on-ramp required. -- **Upgrade-clean for FCMP++.** When the non-disclosing Monero proof primitive - ships, Tier 2 collapses into Tier 1 with no protocol-level rewrite. The RFP - carries an explicit upgrade clause. - -## Cons - -- **Does not fix settlement time.** Settlement is still bounded by source-chain - finality plus LEZ finality plus the timelock window. Hours, not minutes. The - bond does not accelerate cryptographic settlement. -- **Does not fix interactivity.** Both parties must be online to lock, reveal, - and (if the other side defaults) submit the slash claim. The bond removes the - incentive to grief but not the requirement to participate. -- **Per-trade matching, no AMM.** No protocol-owned liquidity, no AMM pricing. - Each swap requires a willing counterparty for the exact pair and exact size. - RFP-021 wins decisively on liquidity gravity. -- **Bond opportunity cost.** Makers must lock LEZ-denominated bond capital, - which yields nothing during the lock window. This raises maker spreads - relative to the unbonded (free-option) atomic swap of RFP-003. -- **Bond can exceed spread in high-volatility regimes.** For pairs with - annualised volatility around 0.8 (a plausible regime for XMR) and the ~28h - deployed refund window, the option value `σ × √T × notional` works out to - roughly 4-5% of notional, which exceeds typical maker spreads on the BTC-XMR - corridor (1-2%). The bond is not a free-option closure under those regimes; it - shifts the problem from "makers are griefed" to "makers stop quoting because - the bond load exceeds their margin". Applicants must address what happens in - this regime: dynamic bond sizing, spread widening, fallback to fee-burn-only - (RFP-026), or accept the consequence that the design has a working-volatility - range it cannot serve. -- **Bond denomination friction.** First-time takers need LEZ-denominated bond - assets. The bondless-taker capped-entry path mitigates this but only for the - first swap. -- **Tier 2 is structurally weaker.** Alice retains a pre-XMR-lock free option on - the LEZ to XMR pair. Reputation (RFP-023) is the only available restraint on - this option under current Monero cryptography. Users must understand the - asymmetry. -- **More complex than RFP-003.** Bond accounting, slash conditions, light-client - modules, dispute windows. The protocol surface and audit surface both grow. - -## Risks - -- **Cross-chain bond correlation.** If Bob is matched against N concurrent swaps - and the LEZ chain re-orgs or his observer crashes, all N swaps may slash him. - Mitigation: per-maker concurrency caps; bond scaling with active-swap count; - explicit re-org tolerance windows. -- **Light-client implementation risk (Tier 1).** The BTC and ETH light-client - modules are the load-bearing primitive. A bug that lets an attacker submit a - false inclusion proof is a direct theft vector. Mitigation: fork from - well-audited references (ZeroSync, Citrea Clementine LCP for BTC; - Nimbus-derived for ETH); independent audit budget. -- **Bond sizing parameter risk.** Bond too small leaves residual optionality; - bond too large prices honest makers out of the market. Volatility regime - changes (e.g. XMR price moves of 20% in a session) widen the option value. - Mitigation: protocol-adjustable bond parameters; optional volatility-indexed - bond sizing. -- **Adversarial bond-bootstrap attack.** An attacker who controls the first set - of makers can credibly claim "reputation-rich" status and capture taker flow. - Mitigation: combine bond requirements with reputation accrual (RFP-023) so - reputation cannot be purchased without time-and-capital cost. -- **FCMP++ upgrade slippage (Tier 2).** If the non-disclosing Monero proof - primitive does not ship on the expected horizon, Tier 2 remains permanently - asymmetric. Mitigation: design the protocol assuming Tier 2 is the steady - state; treat FCMP++ as an optional improvement, not a dependency. -- **First-swap cap evasion.** A taker could split a large trade into many capped - first swaps under fresh pseudonyms. Mitigation: cap by IP, device fingerprint - (weak), or by Sybil-resistant identity proof (stronger); combine with rate - limits enforced at the LEZ escrow program. - -## Relationship to other RFPs in this bundle - -- **RFP-003 (Atomic Swaps with LEZ, open)** is the foundation this RFP extends. - The per-pair SDKs (LEZ-BTC, LEZ-XMR, LEZ-ETH), the Risc0 LEZ-side escrow, and - the custom-LEZ-token support (RFP-003 hard requirement 7) are dependencies. - RFP-022 layers bond escrow, slash conditions, and chain-watching light-client - modules on top. -- **RFP-021 (cross-chain privacy DEX)** is the federated-custody alternative. - RFP-021 sacrifices non-custody for AMM liquidity and one-step UX; RFP-022 - sacrifices liquidity gravity for non-custody. The two coexist in a complete - cross-chain DEX strategy. -- **RFP-023 (reputation-based atomic swaps)** is the bonding alternative. - RFP-022 consumes the maker-reputation primitive from RFP-023; in Tier 2 - specifically, the taker-reputation primitive is the only restraint on Alice's - residual pre-XMR-lock free option. If RFP-023 ships later, RFP-022 specifies a - stub interface and degrades to "count of completed swaps" reputation in the - interim. -- **RFP-024 (sXMR pure)** and **RFP-025 (sXMR with SLA)** are orthogonal. They - target synthetic XMR exposure inside LEZ DeFi; this RFP targets real-asset - atomic swaps. They could be deployed alongside. -- **RFP-026 (fee-burn atomic swaps)** is the *substitute* option-pricing - mechanism, not a complement. RFP-026's fee-burn lives in the external-chain - refund branch; RFP-022's bond lives on LEZ at Commit. They price the same free - option using different escrow locations. RFP-022's bond dominates on Tier 1 - (capital-efficient because it refunds on honest completion); RFP-026's - fee-burn dominates on Tier 2 (it can price the off-LEZ residual option that - Tier 2's bond cannot). Layering both on the same option boundary is - double-counting. - -See [appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) for -the underlying cryptographic mechanics, the free-option framing, and the -`σ × √T × notional` notation. See -[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) -for the federated-signer-vs-atomic-swap trust contrast that motivates this RFP. - -## References - -- [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) -- [eth-lez-atomic-swaps reference implementation](https://github.com/logos-co/eth-lez-atomic-swaps) - (accessed 2026-05-21) -- [Bitcoin to Monero atomic swaps (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) - (accessed 2026-05-21) -- [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) - (accessed 2026-05-21) -- [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332 (2021-01-29)](https://arxiv.org/abs/2101.12332) - (accessed 2026-05-21) -- [comit-network/xmr-btc-swap (BTC-XMR adaptor-signature reference implementation; unmaintained since 2024-11)](https://github.com/comit-network/xmr-btc-swap) - (accessed 2026-05-21) -- [eigenwallet/core (active fork of comit-network/xmr-btc-swap; v4.6.1, 2026-05-15)](https://github.com/eigenwallet/core) - (accessed 2026-05-21) -- [LLFourn one-time-VES: Verifiably Encrypted Signatures (Lloyd Fournier, adaptor signatures)](https://github.com/LLFourn/one-time-VES/blob/master/main.pdf) - (accessed 2026-05-21) -- [apoelstra/scriptless-scripts: atomic-swap protocol notes (Andrew Poelstra)](https://github.com/apoelstra/scriptless-scripts/blob/master/md/atomic-swap.md) - (accessed 2026-05-21) -- [BIP-340: Schnorr signatures for secp256k1](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) - (accessed 2026-05-21) -- [BIP-341: Taproot](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) - (accessed 2026-05-21) -- [Citrea Clementine: Trust-Minimized Bitcoin Bridge](https://docs.citrea.xyz/essentials/clementine-trust-minimized-bitcoin-bridge) - (accessed 2026-05-21) -- [ZeroSync](https://zerosync.org/) (accessed 2026-05-21) -- [Monero, Zero to Monero 2.0 (whitepaper, §Payment Proofs)](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) - (accessed 2026-05-21) -- [Monero, FCMP++ announcement (2024-04-27)](https://www.getmonero.org/2024/04/27/fcmps.html) - (accessed 2026-05-21) diff --git a/RFPs/RFP-023-reputation-atomic-swaps.md b/RFPs/RFP-023-reputation-atomic-swaps.md deleted file mode 100644 index 3b96b79..0000000 --- a/RFPs/RFP-023-reputation-atomic-swaps.md +++ /dev/null @@ -1,374 +0,0 @@ ---- -id: RFP-023 -title: Reputation-Based Atomic Swaps (Bonding Alternative) -tier: XL -funding: $TBD -status: draft -category: Applications & Integrations ---- - -# RFP-023 — Reputation-Based Atomic Swaps (Bonding Alternative) - -> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos -> team and the community compare cross-chain DEX designs across RFP-021 through -> RFP-025. Hard requirements, team profile, timeline, and contracting details -> are deliberately omitted; they will be filled in if the design is selected for -> funding. - -## 🧭 Overview - -Extend RFP-003 (Atomic Swaps with LEZ, open) with an on-chain reputation -registry that constrains the free-option problem inherent to atomic swaps, -*without* requiring bonded collateral as the primary cost-of-defection. - -The premise (a design conjecture to be validated in implementation, not a proven -theorem): a maker who has completed N successful swaps with zero defections has -built up a reputation asset whose net present value (discounted future fee -revenue) plausibly exceeds the expected value of any single grief attack. The -protocol does not need to slash bonded collateral; the *market* effectively -slashes the maker by refusing future trades. Reputation is therefore a -long-tailed bond the protocol does not have to size, hold, or directly enforce. -The closest deployed instance is Wormhole's Guardian set (Proof-of-Authority -committee), which operates on the same economic argument under a different -mechanism. - -The cryptographic challenge is taker reputation. Takers should be unlinkable -across swaps (a privacy-positioned cross-chain DEX should not require its users -to maintain a persistent on-chain identity that can be deanonymised). The RFP -requires applicants to address two complementary design paths: a -capped-pseudonym path (linkable, simple) and a zero-knowledge reputation path -(unlinkable, complex, reusing the LEZ Risc0 zkVM that RFP-003 already -establishes). - -Reputation as a primitive is consumed by other RFPs in the bundle: RFP-022 -(bonded atomic swaps) uses maker reputation to compound the cost of defection on -top of bonded collateral; RFP-025 (sXMR with SLA, option 2a) uses LP reputation -as the attestation layer for default attribution (because "LP defaulted" cannot -be rendered from atomic-swap state alone, per the cross-cutting analysis in the -trust-model contrast appendix). - -## Desired properties - -- **Maker reputation primitive.** A registry on LEZ that tracks per-maker (count - of completed swaps, slash history, time-in-protocol, total fee revenue, - optional liveness signals). Public read; write access gated by the LEZ - atomic-swap escrow program. -- **Taker reputation primitive with privacy options.** Two paths the RFP - requires applicants to consider and ship at least one of: - - **Capped anonymous takers.** First-swap takers are size-capped (worked - example: US$100 notional). Cap relaxes after N successful completions under - the same persistent pseudonym. Linkability is opt-in: a taker who wants - larger size accepts linkability as the cost. - - **Zero-knowledge reputation.** Takers prove "I have completed at least N - swaps with zero slashes" without revealing *which* swaps, via a Sparse - Merkle Tree of swap outcomes maintained by the LEZ escrow program plus a zk - membership proof generated by the taker. Preserves unlinkability across - swaps while letting the taker borrow against accumulated reputation. -- **Sybil-resistance by accrual rate.** Reputation accrual is rate-limited by - completed-swap throughput and per-pseudonym notional caps, so spinning up - fresh identities is bounded by the cost of N honest swaps over the accrual - window. -- **No protocol-held bond required for the core design.** The reputation asset - is the cost of defection; the protocol does not custody slashable collateral - as a precondition of participation. Bonds can be layered on top (per RFP-022) - but are not the load-bearing mechanism here. -- **Bootstrap path.** Reputation has zero value at launch. The protocol must - specify a bootstrap path: a combination of bondless capped entry (same - mechanic as RFP-022's first-swap cap) and RFP-022 bonds for early adopters, - transitioning to reputation-only as reputation accrues. -- **Maker exit.** A maker can withdraw from the protocol by transferring their - identity (selling the reputation as an asset, if the registry permits) or by - abandoning it (accepting reputation loss). Reputation is not refundable. - -## High-level functionality and flow - -### Maker reputation - -``` - LEZ escrow program (RFP-003) - + reputation registry (RFP-023) - - - Maker ----> register identity (one-time) - (deposit small registration fee) - - - per swap: - - escrow program records outcome (success / slash) on maker identity - - reputation field updates atomically with swap settlement - - Taker ----> query registry by maker identity - inspect (count, slashes, time, fee revenue) - decide whether to swap -``` - -Maker identity is a persistent on-chain pseudonym, publicly readable. Makers -want this property: it lets them receive quote requests over Logos Delivery, -accumulate fee revenue, amortise gas, and signal trustworthiness. Reputation as -a public good for makers maps cleanly to the existing maker daemon shape in -RFP-003. - -### Taker reputation: capped-pseudonym path - -``` - Taker ----> generate persistent pseudonym (Pi) - - - first swap under Pi: - - LEZ escrow enforces notional cap (e.g. US$100) - - on success, escrow increments completed-swap count on Pi - - later swaps under Pi: - - notional cap relaxes by formula (e.g. tier 1: $500 after 5 swaps; - tier 2: $5000 after 20; tier 3: unbounded after 50) - - linkability across swaps is intrinsic to using the same Pi -``` - -Trade-off: simple to implement and easy for users to reason about. But -large-volume takers expose a linkable identity across all their swaps; an -adversary who profiles makers can deanonymise large traders' patterns. - -### Taker reputation: zero-knowledge path - -``` - Taker ----> generate ephemeral pseudonym for each swap - - - on each completed swap: - - LEZ escrow inserts a swap-outcome leaf into a Sparse Merkle Tree - (SMT) keyed by a taker-side commitment H(secret_i || swap_id_i) - - taker holds the secret_i needed to re-prove membership - - later swaps: - - taker generates a zk membership proof: "I have at least N - leaves in the SMT with outcome=success and zero leaves with - outcome=slash, without revealing which leaves" - - escrow program verifies the proof and unlocks the corresponding - notional cap tier -``` - -Trade-off: preserves unlinkability across swaps (the taker uses a fresh -pseudonym per swap, joined only by the zk proof of accumulated reputation). -Engineering-expensive: requires a circuit-friendly execution layer on LEZ (the -Risc0 zkVM from RFP-003) and careful side-channel analysis. Reuses the same -proof infrastructure RFP-021's shielded swap intents and RFP-004's -private-account pattern depend on. - -### Slashable-event matrix and reputation counter design - -"Zero slashes" as a single counter is too crude in the LEZ↔XMR context (RFP-022 -Tier 2) because Monero's unverifiable lock state means several abandonment paths -are not slashable but are still reputation-relevant. The reputation registry -must distinguish: - -| Event | LEZ-observable? | Slashable? | Reputation counter | -| ----------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------- | -| Successful swap completion | yes (reveal + claim) | n/a | `completed_count` | -| Reveal-failure after counterparty Logos lock (LEZ↔BTC/ETH and Tier 2 post-Logos-lock) | yes | yes (`B_alice` slashes) | `slashed_count` | -| Post-Logos-lock no-claim (locker walks at Phase 5) | partially (Logos-side is on LEZ; external-chain claim is not) | no (capital loss is on the locker) | `no_claim_count` (low signal) | -| XMR-side party never locks XMR after Commit (RFP-022 Tier 2 Phase 2) | **no** | **no** (LEZ can't tell whether locking happened) | `abandoned_pre_xmr_lock_count` (maker-attested via complaint) | -| LEZ-side party never advances despite counterparty XMR lock (RFP-022 Tier 2 Phase 2-3 boundary, attestation flow) | partial (Logos-lock absence is on-LEZ; the trigger event is off-LEZ) | only with an on-LEZ attestation from the locker (see RFP-022 Tier 2 Open question) | `disputed_attestation_count` | - -A taker proving "I have completed at least N swaps with zero slashes" via zk -membership proof must specify *which counters the claim is over*. A meaningful -claim for the LEZ↔XMR pair would be "`completed_count ≥ N` and -`slashed_count = 0` and `abandoned_pre_xmr_lock_count ≤ K`" for tunable -thresholds — not a single zero-slash claim. The SMT keying must support these -per-counter membership / non-membership proofs. - -### Off-chain verifiable maker reputation (LEZ↔XMR open question) - -The non-slashable abandonment path in RFP-022 Tier 2 Phase 2 (the maker walks -after a taker's off-LEZ XMR lock; equivalently the taker walks pre-Phase-3 in -mirrored direction) cannot be priced by a bond, because the trigger event is not -LEZ-observable. The protocol's only response is to record the abandonment as a -reputation event. But the LEZ contract cannot itself verify the event (it cannot -see the XMR side); it depends on the counterparty posting an attestation. - -A natural follow-up: can the attestation be made *verifiable* by third parties -off-chain, rather than relying purely on on-chain claim plus dispute fallback? - -Concretely: could the complainant publish a proof bundle containing (a) the -counterparty's signed quote anchored on LEZ, (b) the Monero transaction(s) -locking the quoted amount to the shared stealth address derived from the quote, -(c) sufficient view-key material for a third party to verify the lock against -the quote, and (d) the absence of the counterparty's Logos lock on LEZ for that -`swap_id` within window — such that any party with both LEZ and Monero -blockchain access can verify the bundle and conclude "this maker received a -valid lock under its quote and did not advance"? - -Open sub-questions for the applicant: - -1. **Privacy cost.** A naive proof bundle leaks the shared view key, which - deanonymises the swap output to any holder of the bundle. Can the disclosure - be narrowed (a non-interactive zk proof over the Monero output structure that - proves "an output of the quoted amount exists at the stealth address matching - the quote" without exposing the view key)? FCMP++ may help; current Monero - proof primitives (`check_tx_proof`, OutProofV2/InProofV2) do not. -2. **Distribution.** Where does the complainant publish the bundle? LEZ - calldata? IPFS with a hash on LEZ? Logos Delivery? Each has different - censorship-resistance and durability tradeoffs. -3. **Aggregation.** Does the reputation system aggregate complaints across - complainants, weighting by complainant reputation, to produce a score? Or - does each maker carry an unaggregated list of verifiable complaints that - takers inspect directly? -4. **Spam resistance.** A malicious complainant could fabricate quote-shaped - artifacts and pair them with unrelated Monero outputs. The bundle must bind - the Monero output to *this specific swap's* stealth-address derivation in a - way the verifier can re-check from the joint-key transcript without trusting - the complainant. -5. **Defense.** Can the accused party rebut a false complaint with a proof of - its own (e.g. that the claimed Monero output is not the one corresponding to - the swap's stealth-address derivation, or that its on-LEZ behaviour did in - fact match)? -6. **Threshold for "valid complaint".** Off-chain reputation requires a - third-party verifier to make a judgement; the protocol itself does not - decide. Applicants should be honest that this is a social-layer construct - *enabled by* but not enforced by the protocol. - -The protocol can support such a reputation layer cheaply by ensuring (a) quote -signatures are anchored on LEZ with deterministic stealth-address derivation, -and (b) the joint-key transcript is preserved long enough that the bundle can -re-derive the stealth address from public components. Whether to design the -verifiable-complaint layer itself, or expose only the primitives that make it -possible, is part of this RFP's output. - -### Reputation primitive consumed by other RFPs - -- **RFP-022** consumes the maker reputation primitive to compound cost of - defection above the bond. In Tier 2 (LEZ to XMR) specifically, the taker - reputation primitive is the only restraint on Alice's pre-XMR-lock free option - (because her XMR lock cannot be proven on LEZ). The off-chain verifiable - complaint mechanism described above is the specific mechanism RFP-022 calls - out for that gap. -- **RFP-025** option 2a (bonded LP set) consumes LP reputation as the - default-attribution layer, because "LP defaulted" is not a verdict an on-chain - program can render from atomic-swap state alone (per the cross-cutting - analysis in - [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md)). - -## Pros - -- **No protocol-held bond required for the core mechanic.** Capital efficiency - is highest among the free-option mitigations: no LEZ-denominated bond locks up - maker capital during swap windows. -- **Scales with maker career.** Reputation accrues over many swaps; a maker who - has completed 10,000 swaps has a far larger implicit bond than any reasonable - explicit bond size. The mechanism strengthens as the protocol matures. -- **Closer to the cypherpunk "no third-party trust" ideal than RFP-022.** No - bond escrow contract holds funds; no LEZ-side slashing logic enforces - collateral forfeit. The only on-chain artefact is the reputation registry, - which records outcomes but does not custody assets. -- **Composable with bond designs.** RFP-022 can layer reputation on top of bonds - for compounded defection cost. The two are not exclusive. -- **Unlinkable taker reputation is genuinely novel.** The zk membership proof - path, if shipped, is one of the first deployable instances of "I have - reputation but you cannot tell which swaps built it". The privacy positioning - of Logos benefits directly. -- **Solves the LEZ to XMR Tier 2 gap (with RFP-022).** Where RFP-022 alone - leaves Alice with a pre-XMR-lock free option, RFP-023 taker reputation - constrains it by making defection cost reputation rather than collateral. - -## Cons - -- **Bootstrap problem is real.** At launch, reputation has zero value, so the - first cohort of swaps has the strongest free-option exposure. The protocol - must combine reputation with bondless caps (this RFP) plus optional RFP-022 - bonds for the bootstrap phase. The early protocol experience is worse than the - steady-state. -- **Zero-knowledge path is engineering-expensive.** Circuit design, side-channel - analysis, audit, and ongoing performance work. The capped-pseudonym path is - simpler but exposes linkability. -- **Sybil mitigation requires careful parametrisation.** If the per-pseudonym - accrual rate is too generous, attackers can mint reputation cheaply. If too - restrictive, honest takers cannot accumulate reputation fast enough to access - the trade sizes they need. -- **Maker reputation does not protect against first-time defection.** A new - maker with zero reputation can grief and walk away at no reputation cost. The - first swap any taker does with any new maker is unprotected. Mitigation: - combine with RFP-022 bonds during the maker's reputation-building phase. -- **Reputation transfer mechanics are governance-sensitive.** If reputation is - transferable (a maker can sell their identity), an attacker can purchase a - high-reputation identity and grief immediately. If non-transferable, maker - exit is painful (no salvage value). Both directions require careful policy. -- **Maker reputation is publicly linkable, by design.** This is the right - trade-off for the maker role (they want a persistent identity) but it must be - documented honestly: makers are deanonymised by the protocol. - -## Risks - -- **Sybil attacks at scale.** Cheap to mint new pseudonyms; defection from a - low-reputation identity is consequence-free. Mitigation: reputation accrual - rate-limited by completed-swap throughput and notional caps; cost of building - reputation equals the cost of N honest swaps plus the bond-equivalent capital - tied up over the accrual window. -- **Sidechannel deanonymisation of zk-reputation takers.** Even unlinkable - proofs leak via timing, notional distribution, maker-side counterparty - profiling, and (if poorly implemented) proof-construction telemetry. The - privacy claim is "unlinkable across the public ledger", not "unlinkable to a - maker who actively profiles its counterparties". This distinction must be - documented for users. -- **Reputation-purchase attack.** An attacker buys a high-reputation maker - identity (if transferable) and grief-attacks. Mitigation: non-transferable - reputation, or transfer with a notice period and a "decayed-reputation" - cooling window. -- **Bootstrap free-option exposure.** Until reputation accumulates, the protocol - depends on RFP-022 bonds for first-cohort security. If RFP-022 ships later - than RFP-023, the bootstrap window is unprotected. Mitigation: ship together, - or include a stub bond mechanism in RFP-023 itself. -- **zkVM proof cost regression.** If proof generation cost regresses (e.g. due - to LEZ zkVM upgrade), zk-reputation takers face a sudden cost increase. - Mitigation: proof-cost monitoring; protocol-adjustable proof-generation - parameters. -- **Privacy-positioning narrative risk.** "Reputation" reads to some users as - the opposite of "privacy". The communication challenge is real: explaining - that the protocol records *outcomes* (which can be private under zk proofs) - without recording *identities* (which it explicitly does not). Documentation - budget required. -- **Governance attack on the registry.** If the reputation registry is - upgradeable, an attacker who captures the upgrade key can wipe reputation or - insert false reputation. Mitigation: immutable registry contract, with - explicit migration path if upgrade is ever required. - -## Relationship to other RFPs in this bundle - -- **RFP-003 (Atomic Swaps with LEZ, open)** is the foundation. The per-pair - SDKs, Risc0 escrow programs, and Logos Delivery / Logos Chat coordination are - dependencies. RFP-023 layers the reputation registry and (in the zk path) the - SMT-of-outcomes infrastructure on top. -- **RFP-022 (bonded atomic swaps)** consumes the maker reputation primitive - defined here. In Tier 2 (LEZ to XMR), taker reputation is the only restraint - on Alice's residual pre-XMR-lock free option. RFP-022 and RFP-023 can be - implemented as a single workstream or sequenced (RFP-023 first to provide the - primitive, then RFP-022 consumes it). -- **RFP-021 (cross-chain privacy DEX)** is the federated-custody alternative. - Orthogonal: RFP-021 sacrifices non-custody for AMM-style liquidity; RFP-023 - sacrifices throughput for reputation-as-bond non-custody. -- **RFP-025 (sXMR with SLA, option 2a)** consumes LP reputation as the - default-attribution layer for slashing, because "LP defaulted" cannot be - rendered from atomic-swap state alone. RFP-023 is a prerequisite for the - credible deployment of RFP-025 option 2a. -- **RFP-024 (sXMR pure)** does not require reputation (the pure design has no - SLA to enforce), but could optionally consume maker reputation for the - LP-discovery UX. -- **RFP-004 (Privacy-Preserving DEX, open)** does not have a reputation - primitive; RFP-023's reputation registry is a distinct artefact and does not - collide. - -See -[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) -for the full reputation-as-bond analysis (mitigation 3) and the -taker-privacy-tension discussion. - -## References - -- [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) -- [Wormhole Guardian set (reputation-substituting-for-bond under Proof-of-Authority)](https://wormhole.com/docs/protocol/infrastructure/guardians/) - (accessed 2026-05-21) -- [Wormhole 101: Guardians (supporting context)](https://wormhole.com/blog/wormhole-101-guardians) - (accessed 2026-05-21) -- [Sparse Merkle Tree (Vitalik Buterin, "Optimizing sparse Merkle trees", ethresear.ch, 2018-10-09)](https://ethresear.ch/t/optimizing-sparse-merkle-trees/3751) - (accessed 2026-05-21) -- [Risc0 zkVM](https://dev.risczero.com/) (accessed 2026-05-21) -- [Logos Delivery and Logos Chat (referenced from RFP-003)](https://github.com/logos-co/logos-docs) - (accessed 2026-05-21) diff --git a/RFPs/RFP-024-synthetic-xmr-pure.md b/RFPs/RFP-024-synthetic-xmr-pure.md index d648086..78ff6da 100644 --- a/RFPs/RFP-024-synthetic-xmr-pure.md +++ b/RFPs/RFP-024-synthetic-xmr-pure.md @@ -55,15 +55,30 @@ peer-to-peer atomic-swap redemption. Source: noting: the same ring-signature properties that protect users prevent post-incident wallet identification and freezing. +**Inspired by existing prior art.** The minting side follows the well-known +**Synthetix CDP design** (SIP-302 Pools V3 for the V3 reference; the wider +sUSD/SNX collateralisation pattern dating to 2018). See +[appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) +§Oracle-priced over-collateralised synthetics for the deployed-protocol survey. +The redemption side follows the **eigenwallet/COMIT BTC-XMR atomic-swap +pattern** (peer-to-peer adaptor-signature swap, open LP set, no custody); see +the [atomic-swaps primer](../appendix/atomic-swaps-primer.md). The novelty is +the *combination*: a Synthetix-style CDP minted against stable collateral, +redeemed via an eigenwallet-style atomic swap to real XMR, with no protocol-held +custody at any step. Neither half is new; the join is. + **Trade-off accepted up front.** This RFP deliberately leaves the free option of -the redemption-leg atomic swap unpriced. RFP-022's LEZ bond and RFP-026's -external-chain fee-burn both price that option but at the cost of LP capital -efficiency or refund-branch principal loss. Goal 1's premise is that a +the redemption-leg atomic swap unpriced. Goal 1's premise is that a privacy-maximalist user base will tolerate variable redemption availability (LPs may be slow to show up, spreads may widen under stress) in exchange for the cleanest non-custody story. The unpriced free option is the explicit cost the -protocol pays for that positioning; LPs bear it. If you want the option priced, -choose RFP-022, RFP-026, or RFP-025 instead. +protocol pays for that positioning; LPs bear it. Anti-spam mechanisms that price +the option (see lambda prize +[LP-0018](../lambda-prizes/LP-0018-atomic-swap-anti-spam.md)) and off-chain +maker reputation (see +[LP-0019](../lambda-prizes/LP-0019-atomic-swap-maker-reputation.md)) may be +layered on top once available, but neither is a precondition of this RFP. If the +SLA matters more than non-custody, choose RFP-025 instead. This RFP positions itself as the first design where the redemption path itself is both privacy-preserving (deposits real XMR on Monero L1) and non-custodial @@ -155,7 +170,8 @@ freely. - **Cleanest privacy story in the bundle.** Successful redemption ends with real XMR on Monero L1. No protocol-side custody, no signer-set deposit-history leak (the RFP-021 and RFP-025 option 2b weakness), no view-key disclosure (the - RFP-022 Tier 2 constraint). + Monero unobservability constraint inherited from the underlying atomic-swap + primitive; see [atomic-swaps primer](../appendix/atomic-swaps-primer.md)). - **Cryptographic non-custody is full.** No vault, no bond, no SLA. The trust assumption is the oracle (for pricing) and the soundness of the RFP-003 atomic-swap protocol. The protocol cannot lose user funds in a custody breach @@ -199,8 +215,10 @@ freely. Delivery softens this but cannot remove it. - **No protocol-side enforcement of LP behaviour.** Refusing to proceed is *valid behaviour* under the atomic-swap protocol; the protocol cannot - distinguish malicious refusal from connectivity loss. Reputation (RFP-023) is - the only available restraint, and even then it operates as soft pressure, not + distinguish malicious refusal from connectivity loss. Off-chain maker + reputation (see lambda prize + [LP-0019](../lambda-prizes/LP-0019-atomic-swap-maker-reputation.md)) is the + only available restraint, and even then it operates as soft pressure, not enforcement. - **Oracle dependency.** The oracle is the only price signal; oracle attack or stale price degrades minting accuracy. Mitigation lives outside this RFP @@ -230,11 +248,16 @@ freely. jurisdiction. The protocol itself is insulated (it does not handle XMR) but the LP economy may concentrate in friendlier jurisdictions. Strategic, not technical. -- **Atomic-swap maker burnout.** The free-option problem RFP-022 addresses - applies here too: LPs can be free-optioned by takers. Without bonds (Goal 1's - premise), this can drive LPs away. Mitigation: optional layered consumption of - RFP-022 Tier 2 (bonded XMR atomic swaps) or RFP-023 (reputation) for the - redemption leg, as separate products on top of the same sXMR token. +- **Atomic-swap maker burnout.** The free-option problem + ([atomic-swaps primer §The free-option problem](../appendix/atomic-swaps-primer.md#the-free-option-problem)) + applies here too: LPs can be free-optioned by takers. The pure design accepts + this as the cost of Goal 1's non-custody positioning. Mitigation: optional + layered consumption of the anti-spam mechanism + ([LP-0018](../lambda-prizes/LP-0018-atomic-swap-anti-spam.md)) or off-chain + maker reputation + ([LP-0019](../lambda-prizes/LP-0019-atomic-swap-maker-reputation.md)) for the + redemption leg, as separate products on top of the same sXMR token. Neither is + a precondition. - **No protocol-side fee revenue capture.** Open LP set means LPs capture the spread; the protocol's only revenue is mint and burn fees on sXMR itself. Sustainability depends on mint/burn volume, which depends on LEZ DeFi @@ -250,13 +273,15 @@ freely. targets the SLA-needing audience accepting custody risk. The two together cover the synthetics design space. A reader should pick one or both based on which user segment they want to serve. -- **RFP-022 (bonded atomic swaps)** could optionally be consumed by RFP-024 as - the redemption-leg primitive: instead of bare atomic swaps, redemption uses - bonded atomic swaps. This compounds LP commitment but adds bond friction on - the LP side. The pure design in this RFP does not require this layering. -- **RFP-023 (reputation-based atomic swaps)** could optionally be consumed for - LP-discovery UX (takers see LP reputation before initiating). Not strictly - required for the core product. +- **Lambda prize + [LP-0018 (atomic-swap anti-spam mechanism)](../lambda-prizes/LP-0018-atomic-swap-anti-spam.md)** + could be layered on the redemption-leg atomic swap if and when a winning + mechanism ships. Not a precondition; the pure design works without it. +- **Lambda prize + [LP-0019 (off-chain maker reputation)](../lambda-prizes/LP-0019-atomic-swap-maker-reputation.md)** + could provide LP-discovery UX (takers see LP reputation before initiating). + Not a precondition; the open LP set with no reputation works for the + privacy-maximalist user base. - **RFP-021 (cross-chain privacy DEX)** is orthogonal. RFP-021 offers real-XMR cross-chain swaps with federated custody; RFP-024 offers synthetic-XMR exposure with atomic-swap redemption. Different products; same broad audience diff --git a/RFPs/RFP-025-synthetic-xmr-sla.md b/RFPs/RFP-025-synthetic-xmr-sla.md index 59f59cd..7b8145a 100644 --- a/RFPs/RFP-025-synthetic-xmr-sla.md +++ b/RFPs/RFP-025-synthetic-xmr-sla.md @@ -72,22 +72,26 @@ routed to an LP, they must complete the atomic swap within a window. If they default, their bond is slashed and paid to the redeemer. LPs may leave the set, but only after a notice period that exceeds the redemption SLA. -**Distinguish this bond from RFP-022's swap-bond.** RFP-022's bond prices the -*free option on a single in-flight swap* and refunds at swap completion. Option -2a's bond is a *persistent performance bond against the LP's SLA across many -swaps*; it is locked for the LP's tenure plus the notice period. An LP that -adopts both layers carries both bonds against each redemption (RFP-022's bond -escrowed for the duration of the specific swap; option 2a's bond locked across -the LP's tenure). Applicants must address how the two bonds compose: are they -additive against per-redemption notional, or does the SLA-bond subsume the -swap-bond? Aggregate bond load matters for LP economics and must be sized -against expected concurrent-redemption load, not just per-swap option value. +**Inspired by existing prior art.** Option 2a's bonded-LP design is closest in +shape to **Thorchain's bonded-validator model**: a set of operators each post +slashable stake (Thorchain RUNE bonded ≥ ~2× pooled liquidity) and the protocol +enforces performance on the stake. See +[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) +§Federated-signer middle chain for the Thorchain trust-model survey including +the May 2026 GG20/TSSHOCK exploit. The Logos adaptation differs in two respects: +(1) the bonded operators are *XMR sellers committing to redemption SLA*, not +protocol validators co-signing custody; (2) the LP bond is locked for the LP's +tenure plus the notice period, *separate* from any per-swap collateralisation. +The bond is a persistent performance bond against the LP's SLA across many +swaps, not a per-swap collateral. Option 2a inherits Thorchain's structural +problem — slashing requires attribution, and the protocol cannot adjudicate the +attribution from atomic-swap state alone (see the Enforceability caveat below). ``` sXMR LEZ program + LP registry - + slashing logic (consumes RFP-023 reputation - for default attribution) + + slashing logic (depends on an off-chain + attribution layer; see LP-0019) redemption LP bond request @@ -98,7 +102,7 @@ against expected concurrent-redemption load, not just per-swap option value. (adaptor-sig) forfeits bond if LP defaults: bond paid out as compensation, - attribution layered via RFP-023 reputation + attribution layered via LP-0019 reputation system ``` **Enforceability caveat.** "LP defaulted" is not a verdict an on-chain program @@ -106,13 +110,14 @@ can render from atomic-swap state alone (per the cross-cutting analysis in [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md)). Refusing to proceed is *valid behaviour* under the atomic-swap protocol; the LEZ contract cannot distinguish malicious refusal from connectivity loss. The -realistic implementation consumes the RFP-023 reputation primitive as the -attribution layer: an LP who repeatedly fails to honour redemptions loses +realistic implementation depends on the off-chain reputation system that lambda +prize [LP-0019](../lambda-prizes/LP-0019-atomic-swap-maker-reputation.md) is +expected to deliver: an LP who repeatedly fails to honour redemptions loses reputation; the bond is slashed against the *attested* default condition, not -against atomic-swap state directly. Without RFP-023 (or an equivalent attestor -mechanism), the bond can be used only to gate participation (priority, fee -tiers, future-slot access), not slashed with cryptographic certainty on a single -failed swap. +against atomic-swap state directly. Without LP-0019 (or an equivalent off-chain +attestation mechanism), the bond can be used only to gate participation +(priority, fee tiers, future-slot access), not slashed with cryptographic +certainty on a single failed swap. ## Option 2b: protocol XMR reserve @@ -136,16 +141,27 @@ settlement rail between the reserve custodian and the redeemer. (n-of-m, bonded signers, view-key-shared) ``` -At this point the design has adopted sBTC's (Stacks) threshold-signer custody -model, with an oracle-priced peg layer replacing sBTC's 1:1 redemption peg. The -structural overlap is the custody side (a bonded n-of-m signer set holding the -underlying asset on its native chain); the peg semantics differ (sBTC is 1:1 -redemption-backed, this design is oracle-priced). The atomic swap is the wire -format; trust lives in the signer set. The same view-key-shared TSS custody -constraint applies as in RFP-021: honest-but-curious signers learn the -protocol-side deposit history. This is the structural trade-off option 2b -accepts in exchange for the redemption SLA. The signer set must be bonded and -slashable to make the trust assumption explicit. +**Inspired by existing prior art.** Option 2b directly adopts **sBTC's (Stacks) +threshold-signer custody model**: a federation of bonded signers (15-signer, 70% +threshold in SIP-028; 14 currently operating with 10-of-14) holds the underlying +asset on its native chain and produces redemptions on-demand. See +[appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) +§Redeem-to-underlying with custody for the sBTC trust-shape survey. Option 2b +adds an **oracle-priced peg layer** on top of the sBTC-style custody, replacing +sBTC's 1:1 redemption with oracle-tracked redemption. The structural overlap +with sBTC is the custody side; the peg semantics differ. The same +view-key-shared TSS custody constraint applies as in RFP-021: honest-but-curious +signers learn the protocol-side deposit history. This is the structural +trade-off option 2b accepts in exchange for the redemption SLA. The signer set +must be bonded and slashable to make the trust assumption explicit. + +The TSS custody design itself follows **Serai's FROST-over-CLSAG** approach for +the Monero case (rather than Thorchain's GG20 ECDSA, which suffered the May 2026 +TSSHOCK exploit; see +[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) +§Federated-signer middle chain). Serai is pre-mainnet as of 2026-05; option 2b +applicants should track Serai's monero-oxide work as the production-ready +FROSTLASS instantiation. ## High-level functionality and flow (common) @@ -163,9 +179,9 @@ at oracle price; collateral sits in vault. LEZ-XMR SDK within the SLA window. 4. On success, Alice's sXMR is burned, LP claims the released collateral as their payout. -5. On failure (LP times out): bond slashing is triggered. RFP-023 reputation - attestation establishes that the failure was the LP's fault (not the - redeemer's); slashed bond is paid to the redeemer as compensation; LP's +5. On failure (LP times out): bond slashing is triggered. LP-0019 off-chain + reputation attestation establishes that the failure was the LP's fault (not + the redeemer's); slashed bond is paid to the redeemer as compensation; LP's reputation is decremented. ### Redemption (option 2b) @@ -236,9 +252,9 @@ at oracle price; collateral sits in vault. ## Cons (option 2a-specific) - **Slashing requires off-chain attribution.** The LEZ contract cannot - adjudicate "LP defaulted" from atomic-swap state. RFP-023 reputation is the - realistic attribution mechanism; without it, the bond gates participation but - does not slash on single defaults. + adjudicate "LP defaulted" from atomic-swap state. LP-0019 off-chain reputation + is the realistic attribution mechanism; without it, the bond gates + participation but does not slash on single defaults. - **Bond opportunity cost limits LP supply.** Locking stable collateral against XMR commitment is expensive; LP yield must clear the opportunity cost. Realistic capacity is constrained by the LP economy's appetite for the @@ -287,16 +303,19 @@ at oracle price; collateral sits in vault. jurisdiction's stance. - **First-swap cap evasion.** A redeemer could split a large redemption into many capped first-redemptions under fresh pseudonyms. Mitigation: rate limits - enforced at the LEZ escrow program; combine with reputation gating (RFP-023) - for higher tiers. + enforced at the LEZ escrow program; combine with off-chain reputation gating + (LP-0019) for higher tiers. ## Risks (option 2a-specific) -- **RFP-023 dependency.** Without a reputation primitive, the bond is not - actually slashable on default. If RFP-023 ships later than RFP-025 option 2a, - the protocol launches with a weaker enforcement story than its marketing - implies. Mitigation: sequence RFP-023 first, or include a stub-reputation - mechanism in RFP-025 itself. +- **Off-chain reputation dependency (LP-0019).** Without an off-chain + attribution mechanism, the bond is not actually slashable on default. If + lambda prize + [LP-0019](../lambda-prizes/LP-0019-atomic-swap-maker-reputation.md) is not yet + awarded when option 2a ships, the protocol launches with a weaker enforcement + story than its marketing implies. Mitigation: sequence LP-0019 first, or + include a stub-attestor mechanism in RFP-025 itself (with the limitations of + stub-attestor centralisation documented honestly). - **Reputation gaming attacks on the LP side.** An LP can build reputation cheaply by completing many small redemptions then default on a large one. Mitigation: notional-weighted reputation; cap per-LP redemption size @@ -329,12 +348,17 @@ at oracle price; collateral sits in vault. RFP-025. - **RFP-003 (Atomic Swaps with LEZ, open)** is the foundation: the LEZ-XMR atomic-swap SDK is the redemption settlement layer for both options. -- **RFP-023 (reputation-based atomic swaps)** is a hard dependency for option - 2a's slashing mechanism. The reputation primitive is what makes "LP defaulted" - attributable. -- **RFP-022 (bonded atomic swaps)** could optionally be consumed by either - option as the bonded-redemption-leg primitive on the atomic-swap settlement, - layered on top of the LP-side or reserve-side bond. +- **Lambda prize + [LP-0019 (off-chain maker reputation)](../lambda-prizes/LP-0019-atomic-swap-maker-reputation.md)** + is a hard dependency for option 2a's slashing mechanism. The off-chain + attribution it produces is what makes "LP defaulted" attributable; without it, + the bond gates participation but cannot be slashed on a single failed swap + with cryptographic certainty. +- **Lambda prize + [LP-0018 (atomic-swap anti-spam mechanism)](../lambda-prizes/LP-0018-atomic-swap-anti-spam.md)** + could optionally be layered on the redemption-leg atomic swap to deter + taker-side griefing. Not strictly required for either option; the LP-side bond + / reserve already addresses maker-side performance. - **RFP-021 (cross-chain privacy DEX)** is orthogonal: it offers real-asset cross-chain swaps with federated custody; this RFP offers synthetic-XMR exposure with managed redemption. Option 2b shares the view-key-shared TSS diff --git a/RFPs/RFP-026-fee-burn-atomic-swaps.md b/RFPs/RFP-026-fee-burn-atomic-swaps.md deleted file mode 100644 index bad7c14..0000000 --- a/RFPs/RFP-026-fee-burn-atomic-swaps.md +++ /dev/null @@ -1,386 +0,0 @@ ---- -id: RFP-026 -title: Fee-Burn Atomic Swaps (Refund-Side Free-Option Mitigation) -tier: M -funding: $TBD -status: draft -category: Applications & Integrations ---- - -# RFP-026 — Fee-Burn Atomic Swaps (Refund-Side Free-Option Mitigation) - -> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos -> team and the community compare cross-chain DEX designs across RFP-021 through -> RFP-026. Hard requirements, team profile, timeline, and contracting details -> are deliberately omitted; they will be filled in if the design is selected for -> funding. - -## 🧭 Overview - -Extend RFP-003 (Atomic Swaps with LEZ, open) with a **non-refundable fee on the -refund branch** that prices out the free option without requiring an on-LEZ -bond. The fee is burnt (sent to an unspendable output), not paid to the -counterparty, so it does not skew incentives. The mechanism is the proposal in -[eigenwallet PR #675](https://github.com/eigenwallet/core/pull/675) (open as of -2026-05-22), generalised to the LEZ-paired case. - -The protocol intuition: today, in the deployed BTC-XMR adaptor-signature swap, a -taker who has locked BTC can refund at the cost of one Bitcoin transaction fee -(a few thousand sats). This makes the refund branch effectively free, which is -exactly what creates the free-option problem documented in the -[atomic-swaps primer](../appendix/atomic-swaps-primer.md#the-free-option-problem). -The fee-burn fix splits the refund branch so that taking it costs the taker a -configurable fraction of the locked amount. The fraction is set by the maker per -quote; the taker sees it before initiating and decides whether to trade. - -The mechanism is a **substitute** for the bond-based approach in RFP-022, not a -complement. The two instruments price the same free option using different -escrow locations; layering both is double-counting (charging the option holder -twice for the same option). - -- **RFP-022 LEZ bond**: the option premium is a separate amount escrowed on LEZ - at Commit; slashes to the counterparty on LEZ-observable default; - capital-efficient because it refunds on honest completion. -- **RFP-026 fee-burn**: the option premium is a haircut on the refunded - principal taken on the external chain in the refund branch; burns rather than - slashes (to avoid skewing the counterparty's incentives); does not refund on - honest completion (only the *refund branch* is fee-burdened, so honest - completions pay nothing). - -Where each dominates: - -- **Tier 1 (LEZ↔BTC, LEZ↔ETH)**: the LEZ bond strictly dominates. The bond - returns on honest completion; the fee-burn destroys principal whenever the - refund branch is taken. With both sides' locks LEZ-observable, the bond gives - the same option-closure at lower expected capital cost. -- **Tier 2 (LEZ↔XMR)**: the fee-burn dominates the LEZ bond. RFP-022's bond - cannot price the residual Phase-2 free option (the trigger event, the XMR-side - lock, is off-LEZ; see RFP-022 §Tier 2). The fee-burn on the - script-bearing-chain refund branch *can* price it because the trigger (the - refund-branch transaction itself) is on a chain both parties observe directly. - The fee-burn closes the gap RFP-022's bond cannot. - -Applicants should not propose stacking both mechanisms on the same option -boundary. They should propose the fee-burn as the Tier-2-preferred primitive and -explicitly cede Tier 1 to RFP-022's LEZ bond, or argue why one mechanism alone -covers both tiers. - -## Background: the eigenwallet PR #675 design - -The eigenwallet PR (open, not yet merged as of 2026-05-22) modifies the -Bitcoin-side refund branch of the BTC-XMR adaptor-signature swap. Roles in the -eigenwallet convention: **Bob is the taker (BTC-side, locks BTC first); Alice is -the maker (XMR-side, locks XMR second).** This matches the deployed COMIT -direction. - -Current state without fee-burn: after `TxCancel` is published, Bob has two paths -to recover his BTC after a 24h timelock — `TxFullRefund` returns all of `[B]` -(the BTC amount) to Bob; or Alice publishes `TxPunish` if Bob has stayed -offline. Bob's refund costs roughly the transaction fee of `TxFullRefund` plus 2 -prior transactions. - -Proposed state with fee-burn: the `TxFullRefund` path is **replaced** by -`TxPartialRefund`, which splits the locked output into two pieces: `[B]` -(refunded to Bob immediately) and a `Deposit [A+B]` (held in an intermediate -output). The deposit goes through a sub-protocol: - -1. After a further short timelock (30 minutes in PR #675), Bob can publish - `TxReclaim` to retrieve the deposit himself. -2. Before that timelock, Alice can publish `TxWithhold` to take the deposit into - her control (because she observed Bob refunded against the spirit of the - protocol). -3. After Alice has withheld, she can either publish `TxMercy` to release the - deposit back to Bob (forgiving the refund), or burn it by not signing any - further transaction (the deposit becomes permanently unspendable as soon as - `TxWithhold`'s output spend conditions cannot be satisfied by either party - alone). - -The deposit fraction is set by the maker per quote (Alice configures her -`ask_spread` plus a refund-fee parameter); the taker sees the deposit fraction -before locking BTC and chooses whether to trade. The deposit is **burnt** (not -paid to Alice) so that Alice has no incentive to provoke a refund just to -collect the deposit; Alice's mercy path exists so honest refunds (e.g. Alice's -own connectivity loss) can be forgiven without permanent loss to Bob. - -Source: [eigenwallet/core PR #675](https://github.com/eigenwallet/core/pull/675) -(accessed 2026-05-22; archived in research vault). - -eigenwallet shipped a related-but-narrower mechanism in v4.0.0 (2026-03-16): an -**anti-spam deposit** where Alice can withhold part of a refund for up to 30 -minutes then release with "mercy". PR #675 generalises this into a -protocol-level fee-burn with maker-set fraction. Source: -[eigenwallet/core release 4.0.0](https://github.com/eigenwallet/core/releases/tag/4.0.0) -(accessed 2026-05-22). - -## Direction dependence: where the fee-burn works and where it does not - -This is the central design question and the RFP applicants must address it -explicitly. - -The fee-burn mechanism prices the option held by **the party that locks first -and would walk via the refund branch**. In the deployed BTC-XMR direction (BTC -locks first, eigenwallet's PR #675 case): - -- Bob (BTC taker, locks first) is the party who can grief via refund. The - fee-burn forces him to forfeit `[A+B]` deposit on every refund. The free - option Bob holds at the Phase 1-to-Phase 2 boundary (between his BTC lock and - Alice's XMR lock) is now priced. -- Alice (XMR maker, locks second) holds a different option at the Phase - 2-to-Phase 3 boundary (between her XMR lock and Bob's reveal of the secret). - The fee-burn on Bob's refund branch does *nothing* to price this. Alice's - option is priced separately, either by her own conduct (she chose to lock - against Bob; her downside is lock-window opportunity cost on XMR) or by an - LEZ-side bond on her side (which RFP-022 Tier 2 cannot fully provide because - her XMR lock is not LEZ-observable). - -Trade-direction analysis: - -| Trade direction | Who locks first | Who locks second | Fee-burn prices whose option? | -| -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | -| **LEZ→BTC** (user wants BTC, maker holds BTC) | LEZ-side party locks first (if the LEZ↔BTC pair follows the eigenwallet convention) | BTC-side party locks second | Option of the LEZ-side party who walks via LEZ-side refund branch. **Workable** because LEZ has script. | -| **BTC→LEZ** (user wants LEZ-side asset, maker holds LEZ asset) | BTC-side party locks first | LEZ-side party locks second | Option of the BTC-side party who walks via BTC-side refund branch. **Workable** because Bitcoin has script (PR #675 demonstrates the construction). | -| **LEZ→XMR** (user wants XMR, maker holds XMR) | LEZ-side party locks first (deployed eigenwallet convention has BTC first; for LEZ↔XMR, LEZ takes the BTC role as the script-bearing side) | XMR-side party locks second | Option of the LEZ-side party who walks via LEZ-side refund branch. **Workable** because LEZ has script. The fee-burn lives on LEZ. | -| **XMR→LEZ** (user wants LEZ-side asset, maker holds LEZ asset) | LEZ-side party still locks first (same as above by primitive role) | XMR-side party locks second | Same as above: fee-burn lives on the LEZ side. **Workable**. | - -**Where the fee-burn does not work**: the **reverse XMR-first variant** -described in Hoenisch and del Pino 2021 §4 (a CLSAG-adaptor-signature -construction where the XMR-side party locks first). In that variant the -locked-first leg is on Monero, which has no script; a Monero-side fee-burn on -the refund branch is not constructible because Monero has no refund-branch -script at all (Gugger 2020 §3.1: "Monero does not require any particular -on-chain primitives (hashlocks, timelocks)"). For this direction, the fee-burn -approach is structurally infeasible until non-disclosing Monero proof primitives -(FCMP++) ship and allow lock state to be verified on a script-bearing chain. - -**Where the fee-burn also does not work**: it does not price the -**second-locker's option** (the party who waits, sees the first lock, and -chooses whether to advance). That option lives on the no-fee-burn side of the -swap. For the BTC-XMR deployed direction, this is Alice's pre-XMR-lock option -(which she does not face as a real risk: walking away pre-lock costs her nothing -beyond the cancelled quote). For the LEZ↔XMR cases, Alice's pre-XMR-lock walk is -the residual non-bond-priceable option from RFP-022 Tier 2; the fee-burn does -not address it either. - -## Desired properties - -- **No on-LEZ bond required for the core mechanic.** The fee-burn lives in the - external-chain script; LEZ is uninvolved in the option-pricing instrument - itself. This is the structural difference from RFP-022. -- **Maker-set fraction.** Each maker chooses the deposit fraction per quote (a - percentage of the locked amount, configurable in the maker daemon analogous to - `ask_spread`). Takers see the fraction before initiating; choose not to trade - if the fraction is too high. -- **Burn destination is not the counterparty.** The deposit is sent to an - unspendable output (or to a 2-of-2 spend conditional on a transaction that - neither party will ever sign in equilibrium). This prevents the maker from - having an incentive to provoke refunds to collect the deposit. -- **Mercy path.** The maker can release the deposit back to the taker after - withholding it, so honest refunds (e.g. connectivity loss on either side) can - be forgiven. This is the analogue of bond-refund-on-honest-completion in - RFP-022. -- **Dominates the LEZ bond on Tier 2 (LEZ↔XMR).** Because the fee-burn lives on - the script-bearing chain where the refund-branch transaction itself is the - trigger, it prices the off-LEZ residual option that RFP-022's bond cannot. - Tier 2 swaps gain a real option-pricing mechanism (rather than only reputation - \+ market competition). -- **Layerable with RFP-023.** Maker reputation gates which fraction takers will - accept from which makers; takers building reputation can be offered lower - fractions over time. Reputation reduces the friction; fee-burn protects the - maker against new-identity griefing. - -## High-level functionality and flow - -```mermaid -sequenceDiagram - autonumber - participant A as Alice (maker) - participant LEZ as LEZ swap contract - participant Ext as External chain - participant B as Bob (taker) - - Note over A,B: Phase 0 - Quote (with fee-burn parameter) - A->>B: Quote (price, expiry, swap_id, refund_fee_fraction) - - Note over A,Ext: Phase 1 - Lock-Ext (taker locks first; deployed direction) - B->>Ext: Lock to script with three exit paths:
(a) claim by Alice with secret
(b) partial-refund by Bob splits
[trade_amount] + [deposit = fee_fraction × trade_amount]
(c) Alice's punish path if Bob disappears - Ext-->>LEZ: Inclusion proof (verified by LEZ light client) - - Note over A,LEZ: Phase 2 - Lock-LEZ - A->>LEZ: Lock trade_amount conditioned on s - - Note over B,LEZ: Phase 3 - Reveal - B->>LEZ: Publish adaptor signature (reveals s) - A->>Ext: Use s to claim external-chain output - - Note over A,B: Or: Phase 2' - Cancel (refund branch) - B->>Ext: Publish TxPartialRefund:
[trade_amount] back to Bob immediately
[deposit] into intermediate output - Note over A,B: After short timelock (e.g. 30 min) - alt Maker forgives - A->>Ext: TxMercy: deposit released to Bob - else Maker withholds (deposit burns) - A->>Ext: TxWithhold (deposit becomes unspendable) - else Maker no-shows - B->>Ext: TxReclaim: deposit returned to Bob - end -``` - -The crucial detail: the deposit path is the *only* difference from a vanilla -refund. Honest completion is unchanged. Only the refund branch carries the -option premium. - -## Pros - -- **No LEZ capital lockup.** Takers and makers do not need LEZ-denominated - assets to participate. The mechanism works on any pair where the - script-bearing chain has refund-branch scripting. -- **Composable with the eigenwallet ecosystem.** Adopting the same construction - as eigenwallet PR #675 means the LEZ atomic-swap protocol can interoperate - with eigenwallet makers on the BTC-XMR pair. This is materially valuable for - the BTC-XMR direction specifically. -- **Maker-set, not protocol-set.** Each maker chooses their fee fraction; the - protocol does not impose a single rate. Markets discover the right fraction - over time. -- **Burn destination avoids incentive skew.** Unlike a "refund fee paid to - counterparty" design, the burn cannot motivate either party to grief the - other. The deposit going to an unspendable output (after mercy timeout) is - bounded loss for both sides. -- **Layerable with RFP-022 bonds.** A taker can post an LEZ bond *and* face a - fee-burn on the external chain. The compound cost of the abort branch is the - sum of the two. -- **Survives Monero-non-observability**: the fee-burn lives on the - script-bearing chain. LEZ does not need to witness anything on the Monero - side, so the LEZ↔XMR Tier 2 problem (from RFP-022) does not apply to the - fee-burn mechanism itself. - -## Cons - -- **Does not price the second-locker's option.** The fee-burn lives in the - first-locker's refund branch only. The option held by the second-locker (Alice - in the BTC-XMR direction, between her XMR lock and Bob's reveal) is not priced - by this mechanism. For full bilateral mitigation, layer with RFP-022 Tier 1 - (where both sides are LEZ-observable) or accept the asymmetry. -- **Does not work for XMR-first direction.** The reverse XMR-first variant - (Hoenisch and del Pino 2021 §4) requires Monero-side refund-branch scripting, - which does not exist. Pairs where the script-bearing side is unable to play - the locks-first role at all (currently none in this bundle) would also be - excluded. -- **Maker reputation is load-bearing.** The maker's mercy path is a - discretionary choice; in the limit, a malicious maker could withhold every - deposit and force burns. The deposit fraction must be sized small enough that - honest takers tolerate the worst-case loss, which constrains how much option - premium the mechanism can collect. Reputation (RFP-023) on the maker side is - the soft pressure that keeps mercy honest. -- **External-chain transaction-fee overhead.** The fee-burn protocol requires - multiple transactions on the external chain (cancel, partial-refund, withhold - or reclaim or mercy). At high external-chain fee regimes, the protocol's gas - cost competes with the deposit value. -- **Withhold/mercy/reclaim adds protocol surface.** Auditing and testing the - additional sub-protocol is a real engineering cost. eigenwallet PR #675 is the - reference, but adapting it to LEZ-paired swaps requires the LEZ-side analogue - (when LEZ takes the script-bearing role). -- **Not a bond.** The deposit is not slashed to the counterparty (by design); - the protocol cannot use the deposit to *compensate* the wronged party. - Compensation requires RFP-022's on-LEZ bond mechanism layered on top. - -## Risks - -- **Withhold-mercy race conditions.** The - Alice-withholds-then-mercifully-releases path must be atomic from a UX - perspective; partial-protocol-completion (Alice withholds and disappears - without mercy or final burn) leaves the deposit in limbo. Mitigation: design - the deposit script so that Bob's reclaim path is always available after a hard - deadline regardless of Alice's actions. PR #675 already has this property (the - 30-min timelock to `TxReclaim`). -- **Fraction-too-high griefing of takers.** A malicious maker could post an - unreasonably high deposit fraction in their quote, then trade-and-withhold to - permanently burn taker funds. Mitigation: discovery-layer fraction caps; - reputation-weighted fraction acceptance; protocol-level upper bound on the - deposit fraction (e.g. ≤ 20%). -- **Fraction-too-low under-pricing the option.** If the fraction is set below - the option's true value (`σ × √T × notional`), the abort branch is still - EV-positive for adversarial takers. Mitigation: applicants validate the - maker-set fraction against actual observed volatility; document a sizing - guidance comparable to the σ×√T×notional rule from the primer. -- **Coordinated fraction-collusion.** If most makers settle on the same fraction - (a Schelling point), takers cannot route around abusive levels. Mitigation: - discovery-layer transparency on per-maker fraction history; reputation rewards - for makers who use lower fractions and honour mercy. -- **External-chain fee-spike defeats burn economics.** During Bitcoin mempool - congestion, the cost of the refund-branch transactions can exceed the deposit - value. Mitigation: dynamic deposit-sizing relative to recent external-chain - fee rates; minimum-deposit floor. -- **Adoption fragmentation with eigenwallet.** If the LEZ-adapted fee-burn - diverges from eigenwallet's PR #675 in non-backwards-compatible ways, LEZ - takers cannot route to eigenwallet makers and vice versa. Mitigation: - implement the same on-the-wire construction PR #675 specifies, with LEZ-side - script primitives substituted only where LEZ takes the BTC role. - -## Relationship to other RFPs in this bundle - -- **RFP-003 (Atomic Swaps with LEZ, open)** is the foundation. RFP-026 modifies - the refund branch of the per-pair atomic-swap construction; the joint-key - setup, lock, and reveal flow are inherited from RFP-003. -- **RFP-022 (bonded atomic swaps)** is the *substitute* option-pricing - mechanism. Both RFPs price the same free option but with different escrow - locations and different capital efficiency. RFP-022's LEZ bond is more - capital-efficient on Tier 1 (LEZ↔BTC, LEZ↔ETH) because it refunds on honest - completion. RFP-026's fee-burn is the only mechanism that can price the - residual off-LEZ option in Tier 2 (LEZ↔XMR). Applicants should propose the - fee-burn for Tier 2 only and let RFP-022 cover Tier 1, or justify why one - mechanism alone should cover both. -- **RFP-023 (reputation-based atomic swaps)** is the soft-pressure layer for the - maker's mercy path. A maker who systematically withholds (rather than - mercifully releases) earns reputation cost. RFP-023's slashable-event matrix - should be extended to record `mercy_path_invoked` and `withhold_to_burn` - separately. -- **RFP-021 (cross-chain privacy DEX)** is orthogonal: federated-custody middle - chains have no atomic-swap refund branch to attach a fee-burn to. The two - designs solve different problems. -- **RFP-024 (sXMR pure)** and **RFP-025 (sXMR with SLA)** could optionally adopt - the fee-burn on the redemption-leg atomic swap. RFP-024's LP economy would - benefit from refund-branch fee-burns reducing taker-side free-option exposure; - RFP-025 option 2a could layer fee-burn on top of the LP bond. - -## A note on the locks-first direction - -This RFP's fee-burn mechanism is constructively dependent on which side locks -first. The bundle (see RFP-022 overview and the -[atomic-swaps primer](../appendix/atomic-swaps-primer.md#locking-order)) treats -locking order as driven by the draining-attack economic analysis, not by the -cryptographic primitive. For the deployed BTC-XMR direction (Bob = BTC taker -locks first), the fee-burn lives on Bitcoin and works as PR #675 specifies. For -LEZ-paired swaps following the same convention (LEZ-side locks first), the -fee-burn lives on LEZ and is implemented via the LEZ-side escrow script. - -Applicants must: - -1. **State the locks-first direction explicitly** for each pair the RFP targets. - Default to the deployed convention (BTC-side / LEZ-side locks first); justify - any deviation. -2. **Show that the fee-burn lives on the locks-first chain.** The fee-burn - cannot be added to the second-locker's refund branch in a way that prices the - first-locker's option; the geometry of the protocol forbids it. -3. **Mark which trade directions the chosen pair handles.** A fee-burn on the - LEZ-side refund branch prices both LEZ→external and external→LEZ trade - directions (since LEZ locks first either way under the deployed convention). - A fee-burn on the BTC-side refund branch in a BTC-XMR pair only handles the - BTC-first direction; the reverse XMR-first direction is structurally - unaddressed by this mechanism. - -## References - -- [eigenwallet/core PR #675: fee-burn on refunds](https://github.com/eigenwallet/core/pull/675) - (accessed 2026-05-22; body archived in research vault) -- [eigenwallet/core release 4.0.0: anti-spam deposit (cancel timelock reduction + 30-minute withhold/mercy)](https://github.com/eigenwallet/core/releases/tag/4.0.0) - (accessed 2026-05-22) -- [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) -- [RFP-022: Bonded Atomic Swaps](./RFP-022-bonded-atomic-swaps.md) -- [RFP-023: Reputation-Based Atomic Swaps](./RFP-023-reputation-atomic-swaps.md) -- [appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) — - free-option framing and locking-order analysis -- [Han et al., On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) - (accessed 2026-05-22) -- [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) - (accessed 2026-05-22) -- [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332](https://arxiv.org/abs/2101.12332) - (accessed 2026-05-22) diff --git a/lambda-prizes/LP-0018-atomic-swap-anti-spam.md b/lambda-prizes/LP-0018-atomic-swap-anti-spam.md new file mode 100644 index 0000000..68e0d36 --- /dev/null +++ b/lambda-prizes/LP-0018-atomic-swap-anti-spam.md @@ -0,0 +1,277 @@ + + + + +# LP-0018: Anti-Spam Mechanism for Atomic Swaps [Draft] + +**`Status`**: + +- Draft: Not yet ready +- Open: Ready for application +- Completed: Submission accepted, prize completed + +**`Logos Circle: N/A`** + +## Overview + +Atomic swaps are deliberately symmetric: either party can refuse the next +message at any stage and both sides refund at timeout. This is the design, not a +bug. But it lets a malicious taker spam makers: lock funds against a maker's +quote, wait until the price moves, complete or refund accordingly. The refund +branch costs the taker only a few external-chain transaction fees, while the +maker's inventory is wedged for the lock window and the maker absorbs the loss +when the taker walks. Han et al. (IACR 2019/896) prove this is formally +equivalent to a premium-free American Call Option and quantify the implicit +premium at approximately 2% of asset value for crypto pairs. + +This prize is for an **innovative mechanism that prices out the taker's free +option** in the LEZ atomic-swap protocol (RFP-003), without specifying the +mechanism. The bar is a working implementation that demonstrably deters spam and +free-option exploitation while preserving the non-custodial +cryptographic-trust-only properties of the underlying atomic swap. Reference +prior art exists +([eigenwallet PR #675](https://github.com/eigenwallet/core/pull/675)); the prize +does not prescribe that approach. Solvers are free to design bonds, fee-burns, +reputation, deposits, slashing schemes, or any combination, as long as the +chosen mechanism survives the evaluation against the success criteria below. + +## Motivation + +The atomic-swap branch of the cross-chain DEX design tree has known structural +weakness on the free-option problem. The Logos cross-chain DEX bundle (RFPs 021, +024, 025) keeps the vanilla RFP-003 atomic swap as the privacy-non-custodial +primitive, but vanilla atomic swaps remain economically unattractive for makers +at any scale because of the free-option exposure. Without a credible anti-spam +mechanism, the maker side of the LEZ atomic-swap market collapses to a hobbyist +scale (see [eigenwallet](https://github.com/eigenwallet/core/): community-scale, +single-digit active makers, BTC→XMR direction only). + +A competitive prize is the right mechanism because the design space is large and +the right answer is not obvious: + +- **On-LEZ bonds** price the option premium via slashable collateral; they + require LEZ-denominated capital from at least one side and they only work at + boundaries that LEZ can observe (Tier 1 pairs like LEZ↔BTC, LEZ↔ETH). +- **External-chain fee-burns on the refund branch** + ([eigenwallet PR #675](https://github.com/eigenwallet/core/pull/675)) price + the option premium by destroying a fraction of locked principal on the + script-bearing chain. They reach boundaries that LEZ cannot observe but they + cost real principal on every refund (no refund on honest completion) and they + require careful incentive design so the maker cannot weaponise the deposit. +- **Reputation-based deterrence** (the subject of the companion prize + [LP-0019](./LP-0019-atomic-swap-maker-reputation.md)) provides soft pressure + on repeat makers; first-time and anonymous takers escape this entirely. +- **Hybrid designs** combining the above in different proportions. + +Each carries trade-offs in capital efficiency, capital denomination, anti-DDoS +coverage, and how it interacts with the LEZ↔XMR asymmetric case (where the +XMR-side lock is not LEZ-observable). The Logos team does not want to pre-judge +the answer; this prize is open to any approach. + +## Success Criteria + +### Functionality + +- [ ] Demonstrably deters a taker who would otherwise lock an external-chain + asset against a maker's quote and walk via the refund branch at near-zero + cost. The submission must include a clearly-documented adversarial scenario + and show how the mechanism makes the abort branch EV-negative for the taker. +- [ ] Works in at least one trade direction for the LEZ↔BTC pair (the corridor + with the most existing prior art) and clearly states which other pairs + (LEZ↔ETH, LEZ↔XMR in both directions) the mechanism covers, with justification + for any exclusions. +- [ ] Compatible with the RFP-003 LEZ atomic-swap SDK as the underlying + primitive; does not require changes to the cryptographic core (joint-key + setup, adaptor signature, lock, reveal). +- [ ] Preserves non-custody: no third party (signer set, validator, oracle, + attestor) holds user funds at any stage. The mechanism cannot reintroduce the + federated-custody trust assumption. +- [ ] Survives the maker-locks-first case (in BTC→XMR direction, the Bitcoin + side locks first by deployed convention). The mechanism must price the option + held by whichever side locks first. +- [ ] Burnt or escrowed principal in adverse paths is **not** payable to the + counterparty in a way that creates new griefing incentives (e.g. if the maker + can profit by provoking a refund, that defeats the purpose). The submission + must include an incentive-compatibility argument. +- [ ] Handles connectivity-loss / honest-refund cases gracefully: an honest + party who refunds due to connectivity issues should not lose + disproportionately. +- [ ] Discoverable parameters: the cost the taker faces under the mechanism + (deposit fraction, bond size, etc.) is known to the taker before they initiate + the swap; quote-level discovery is acceptable. + +### Usability + +- [ ] Provide a module/SDK that can be used to build Logos modules for + interacting with the program. +- [ ] Provide a Logos Basecamp app GUI with local build instructions, + downloadable assets, and loadable in Logos app (Basecamp). +- [ ] Provide an IDL for the LEZ program, using the + [SPEL framework](https://github.com/logos-co/spel). + +### Reliability + +- [ ] The mechanism does not introduce new failure modes that lock user funds + permanently in protocol-construction-error states. Every escrowed amount must + have a finite-time recovery path under all adversarial choices the + counterparty can make. +- [ ] Race conditions between counterparty actions (e.g. simultaneous refund and + claim attempts) are documented and resolved deterministically. + +### Performance + +- [ ] Document the compute unit (CU) cost of each on-chain operation introduced + by the mechanism, on both LEZ devnet/testnet and the external chain (Bitcoin, + Ethereum, etc.) if the mechanism touches those. +- [ ] Quantify the additional transaction count vs vanilla RFP-003 atomic swap + (e.g. how many additional Bitcoin transactions does a refund involve). +- [ ] State the expected external-chain transaction-fee cost ranges under normal + and high-fee regimes (Bitcoin mempool congestion in particular). + +### Supportability + +- [ ] The program is deployed and tested on LEZ devnet/testnet. +- [ ] End-to-end integration tests run against a LEZ sequencer (standalone mode) + and are included in CI. +- [ ] CI must be green on the default branch. +- [ ] A README documents end-to-end usage: deployment steps, program addresses, + and step-by-step instructions for interacting with the program via CLI and + Basecamp app. +- [ ] A reproducible end-to-end demo script is provided and works against a real + local sequencer with `RISC0_DEV_MODE=0`. +- [ ] A recorded video demo of the end-to-end flow is included in the + submission; the recording must show terminal output (including proof + generation) to confirm `RISC0_DEV_MODE=0` was active. +- [ ] The demo includes at least one "adversarial taker spams the maker" + scenario where the mechanism deters the attack, plus the honest-completion + scenario where the mechanism imposes no cost on honest users. + +## Scope + +### In Scope + +- The anti-spam mechanism itself: design, on-chain components (LEZ program, + external-chain script changes if any), client-side SDK, and integration with + RFP-003's per-pair atomic-swap modules. +- Incentive analysis: a written argument for why the mechanism is + incentive-compatible and what attacker strategies it deters or admits. +- One concrete pair (LEZ↔BTC is the recommended starting point; LEZ↔ETH or + LEZ↔XMR is acceptable if justified). +- A reference integration: working demo of a swap that uses the mechanism, + including at least one adversarial path that exercises the deterrent. + +### Out of Scope + +- Modifying the underlying RFP-003 atomic-swap cryptography (joint-key setup, + adaptor signature, lock/reveal). Solvers may add escrow logic around the swap + but must not alter the swap primitive itself. +- Reintroducing federated trust (TSS custody, signer sets, oracle attestors). + RFP-021 covers the federated-custody design space; this prize is for + non-custodial mechanisms. +- A polished consumer UI beyond what's needed for the demo. +- Ongoing maintenance, security audit, or mainnet deployment beyond the testnet + integration. +- Solving the LEZ↔XMR direction-symmetry problem in full (the residual off-LEZ + option that vanilla atomic swaps inherently leave open; see also the companion + prize [LP-0019](./LP-0019-atomic-swap-maker-reputation.md) on the off-chain + reputation side of the same problem). A submission that addresses the LEZ↔BTC + case cleanly is sufficient; addressing LEZ↔XMR is a bonus. + +## Prize Structure + +- **Total Prize:** $X +- **Effort:** L + +> Leave prize pool blank — this will be determined by the Logos team. Single +> winner by default. + +## Eligibility + +Open to any individual or team. Submissions must be original work. Teams must +hold the rights to all submitted code and agree to license it under MIT or +Apache-2.0. + +## Submission Requirements + +A submission must include: + +- A public repository containing the LEZ program(s), client SDK, integration + tests, demo script, and any external-chain script changes. +- A written design document (in the repo) covering the mechanism, the + adversarial model, the incentive-compatibility argument, and any honest-refund + / connectivity-loss handling. +- A narrated video walkthrough demo showing (a) honest completion, (b) at least + one adversarial-taker scenario where the mechanism deters the attack, and (c) + any external-chain transactions involved. The demo must show terminal output + including proof generation with `RISC0_DEV_MODE=0`. +- A FURPS self-assessment (see + [solution template](https://github.com/logos-co/lambda-prize/blob/main/solutions/LP-0000.md)). +- A short comparison section against the reference prior art (at minimum: + eigenwallet PR #675), stating what the submission borrows, where it diverges, + and why. + +## Evaluation Process + +By default, submissions are evaluated first-come-first-served against the +success criteria. The first submission that meets all criteria wins. + +Evaluators will independently clone the repository and run the demo script from +a clean environment; the script must succeed without modification. Evaluators +will also exercise at least one adversarial-taker scenario themselves to verify +the deterrent. + +Because the design space is large and multiple valid approaches exist, +evaluators may rank tied submissions on: + +1. Coverage across pairs (a mechanism that handles LEZ↔BTC, LEZ↔ETH, and at + least one direction of LEZ↔XMR ranks above one that handles only LEZ↔BTC). +2. Capital efficiency (mechanisms that impose less cost on honest users rank + above mechanisms that always impose cost). +3. Incentive-compatibility argument quality. +4. Integration cleanliness with RFP-003's existing per-pair modules. + +The following policies apply to all prizes (see +[evaluation policies](https://github.com/logos-co/lambda-prize/blob/main/README.md#evaluation-policies)): + +- **Submissions:** each builder (or team) is allowed a maximum of **3 + submissions** per prize, with at most **one submission/review per week**. +- **Feedback:** initial evaluation feedback is limited to a pass/fail indication + against the success criteria. + +## Resources + +- [RFP-003: Atomic Swaps with LEZ](https://github.com/logos-co/rfp/blob/master/RFPs/RFP-003-atomic-swaps.md) + — the vanilla atomic-swap protocol this mechanism builds on. +- [eigenwallet PR #675: fee-burn on refunds](https://github.com/eigenwallet/core/pull/675) + — reference prior art; an open proposal that introduces a non-refundable burn + on the refund branch via maker-set deposit fraction, withhold path, and mercy + release. Solvers are free to adopt, adapt, or reject this approach. +- [eigenwallet/core release 4.0.0 anti-spam deposit](https://github.com/eigenwallet/core/releases/tag/4.0.0) + — shipped narrower mechanism (cancel-timelock reduction plus 30-minute + withhold/mercy) that PR #675 generalises. +- [appendix/atomic-swaps-primer.md](https://github.com/logos-co/rfp/blob/master/appendix/atomic-swaps-primer.md) + — atomic-swap mechanics, free-option framing, `σ × √T × notional` notation for + sizing. +- [appendix/cross-chain-trust-model-contrast.md](https://github.com/logos-co/rfp/blob/master/appendix/cross-chain-trust-model-contrast.md) + — the federated-signers-vs-atomic-swaps trust contrast that motivates keeping + atomic swaps non-custodial. +- [Han, Lin, Yu, On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) + — the canonical free-option-problem paper; proves formal equivalence to a + premium-free American Call Option and estimates the implicit premium at ~2% of + asset value for crypto pairs. +- [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) + — protocol fundamentals; relevant for direction-dependence analysis. +- [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332](https://arxiv.org/abs/2101.12332) + — §4 covers the draining-attack analysis that determines which side locks + first, useful for solvers reasoning about XMR-first variants. +- [LP-0019: Off-Chain Verifiable Reputation for Atomic-Swap Makers](./LP-0019-atomic-swap-maker-reputation.md) + — companion prize that addresses the reputation layer. A submission may + consume LP-0019's reputation primitive as part of its design. + +## Potential for Subsequent λPrizes + +If this prize is awarded for a LEZ↔BTC-only mechanism, a follow-up prize may be +opened for LEZ↔XMR coverage once non-disclosing Monero proof primitives (FCMP++ +or equivalent) reach production-ready status, since LEZ↔XMR has structural +challenges (the off-LEZ lock is not observable from LEZ) that this prize does +not require solvers to address. diff --git a/lambda-prizes/LP-0019-atomic-swap-maker-reputation.md b/lambda-prizes/LP-0019-atomic-swap-maker-reputation.md new file mode 100644 index 0000000..b619ac9 --- /dev/null +++ b/lambda-prizes/LP-0019-atomic-swap-maker-reputation.md @@ -0,0 +1,287 @@ + + + + +# LP-0019: Off-Chain Verifiable Reputation for Atomic-Swap Makers [Draft] + +**`Status`**: + +- Draft: Not yet ready +- Open: Ready for application +- Completed: Submission accepted, prize completed + +**`Logos Circle: N/A`** + +## Overview + +In any atomic-swap protocol there are abandonment paths the on-chain settlement +contract cannot adjudicate. The clearest example sits in the LEZ↔XMR direction +(RFP-003 LEZ atomic-swap protocol's Tier-2 case): a maker who has received a +counterparty's Monero lock can refuse to advance on LEZ, and the LEZ contract +cannot tell whether the maker is malicious or the counterparty never actually +locked. The Monero side is not observable from LEZ without view-key disclosure +(which would deanonymise the swap output). The protocol falls back to a +he-said-she-said dispute; the only recourse is *reputation*. + +The Logos cross-chain DEX bundle treats this as a real gap in the vanilla +atomic-swap protocol and does not pretend slashing or attestor-based mechanisms +can close it without reintroducing trust. This prize is for a **mechanism that +lets honest counterparties publish third-party-verifiable evidence of maker +misbehaviour**, so a reputation system built on top of vanilla atomic swaps +(RFP-003) can be both privacy-respecting and adversarially robust. The Logos +team does not pre-judge how. Solvers may use view-key disclosure with privacy +mitigations, FCMP++-grade zk proofs, multi-party attestation schemes, watchtower +designs, or any combination, as long as the resulting reputation system survives +the evaluation against the success criteria below. + +## Motivation + +A reputation system that records only successful swaps is useless: it cannot +deter misbehaviour because misbehaviour leaves no on-chain trace. A reputation +system that records every counterparty complaint without filtering is worse than +useless: a malicious *taker* can manufacture false complaints against an honest +maker. + +The hard problem is producing evidence of "maker received a counterparty lock +and did not advance" that **any third party with access to the relevant +blockchain state can verify, without trusting the complainant**. This is +non-trivial in the LEZ↔XMR case because the Monero output is not directly +readable from outside the bilateral context, and the natural disclosure +(view-key + lock-amount) deanonymises the swap. + +A competitive prize is the right mechanism because the design space is large and +no published solution exists: + +- **Naive view-key disclosure**: complainant publishes the shared view key plus + the lock transaction so any third party can verify the lock against the + maker's signed quote. Cost: the swap output is deanonymised forever to anyone + holding the proof bundle. +- **Selective-disclosure zk proofs over Monero output structure**: prove "an + output of the quoted amount exists at the stealth address derived from this + quote's joint-key transcript" without exposing the view key. Cost: requires + either FCMP++-grade primitives that are pre-production, or a custom proof + system over Monero's CLSAG ring-signatures. +- **Multi-party attestation**: a small committee of attestors observes both + chains and signs off on disputed cases. Cost: reintroduces a trust layer the + bundle is trying to avoid. +- **Watchtower designs**: paid third parties run both Monero and LEZ nodes and + earn fees for issuing attested verdicts. Cost: the watchtower itself becomes a + target. +- **Hybrid**: tiered reputation where most claims are unverifiable but the + highest-stakes claims demand a verifiable proof bundle. + +Each carries trade-offs in privacy cost, cryptographic complexity, deployability +today, and adversarial robustness. The Logos team does not want to pre-judge the +answer; this prize is open to any approach. + +The prize complements but does not depend on LP-0018 (atomic-swap anti-spam +mechanism): a robust reputation system reduces the need for protocol-level +deterrents by making repeated misbehaviour visible across swaps; LP-0018's +mechanisms deter individual misbehaviour without needing cross-swap history. +Both can coexist. + +## Success Criteria + +### Functionality + +- [ ] An honest counterparty (taker or maker) can publish a proof bundle for a + failed swap that a third party with access to the relevant blockchain state + (LEZ + the relevant external chain) can verify *without trusting the + complainant*. The verification produces one of: valid complaint, invalid + complaint, indeterminate (with documented reason). +- [ ] Covers at least the LEZ↔BTC and LEZ↔ETH cases. Bonus: covers LEZ↔XMR with + documented trade-offs (privacy cost of disclosure, dependency on future Monero + primitives if relevant). +- [ ] The mechanism distinguishes: + - The complainant fabricating a quote: caught by signature verification on the + quote. + - The complainant fabricating a lock: caught by the verifier checking the + external-chain lock against the quote's derived stealth-address / script / + contract. + - The accused successfully rebutting (e.g. presenting their own LEZ activity + proving they advanced): caught by the verifier checking LEZ state. +- [ ] **Sybil resistance.** The cost of building a high-reputation identity to + then defect must exceed the expected gain from defecting. Sybil identities + should not be able to manufacture clean reputation cheaply. +- [ ] **Spam resistance.** A malicious taker cannot mass-publish fake complaints + to deny-of-service the reputation system. Either the cost of publishing a + complaint is bounded below (e.g. micro-fee) or the verifier filters cheaply. +- [ ] **Aggregation method documented.** A maker's overall reputation score is a + function of (verified positive completions, verified valid complaints, + possibly weighted by complainant reputation). The submission must specify the + function and justify it. +- [ ] **Privacy on the complainant side.** A taker complaining about a maker + should not be forced to reveal which other swaps that taker has done, unless + they choose to. (The accused maker is necessarily identifiable since the + complaint is about their identity.) +- [ ] **Existing-project comparison.** The submission must identify at least one + existing reputation system (e.g. Wormhole Guardian set behaviour reporting, + Thorchain bond-to-pooled slashing rules, decentralised review aggregators, + EigenLayer AVS slashing, or other) and explain how the chosen design relates + to or differs from it. + +### Usability + +- [ ] Provide a module/SDK that can be used to build Logos modules for + interacting with the reputation system (querying maker reputation, publishing + complaints, generating proof bundles). +- [ ] Provide a Logos Basecamp app GUI with local build instructions, + downloadable assets, and loadable in Logos app (Basecamp). +- [ ] Provide an IDL for any LEZ programs introduced, using the + [SPEL framework](https://github.com/logos-co/spel). +- [ ] Surface the maker's reputation in a way takers can inspect *before* + initiating a swap. + +### Reliability + +- [ ] Disputed claims (where the verifier returns "indeterminate") are handled + with a documented policy: they are recorded as such, not silently dropped, and + do not falsely degrade either party's reputation. +- [ ] The reputation database is censorship-resistant: it does not depend on a + single host or central index. +- [ ] Storage primitives for the proof bundles (where they live, how long they + persist) are specified. Logos Delivery is the expected substrate. + +### Performance + +- [ ] Document the storage and bandwidth cost per complaint, per verification, + and per reputation query. +- [ ] State the latency from publishing a complaint to it being aggregated into + the maker's reputation score. +- [ ] Document compute unit (CU) cost of any on-chain LEZ operations introduced. + +### Supportability + +- [ ] Any LEZ programs introduced are deployed and tested on LEZ devnet/testnet. +- [ ] End-to-end integration tests run against a LEZ sequencer (standalone mode) + and are included in CI. +- [ ] CI must be green on the default branch. +- [ ] A README documents end-to-end usage: how to publish a complaint, how to + query reputation, how the verifier works. +- [ ] A reproducible end-to-end demo script is provided and works against a real + local sequencer with `RISC0_DEV_MODE=0`. +- [ ] A recorded video demo of the end-to-end flow is included in the + submission; the recording must show terminal output (including proof + generation) to confirm `RISC0_DEV_MODE=0` was active. +- [ ] The demo includes at least one "valid complaint" scenario and one + "fabricated complaint rejected" scenario. + +## Scope + +### In Scope + +- The reputation mechanism: data model, proof-bundle structure, verifier design, + aggregation function, anti-spam and anti-sybil mechanisms. +- Storage and distribution: where proof bundles live (Logos Delivery is the + expected substrate); how reputation scores are computed and propagated. +- Client-side: SDK for publishing complaints, generating proof bundles, and + querying reputation. +- A reference integration with RFP-003 LEZ atomic-swap maker daemon, where the + maker's reputation is auto-updated on completed and failed swaps. +- Documentation: cryptographic approach, privacy guarantees, adversarial model, + comparison against at least one existing reputation system in the wild. + +### Out of Scope + +- Changing the underlying RFP-003 atomic-swap cryptography. +- Building a protocol-level slashing mechanism on top of the reputation (that + would be the role of LP-0018 (anti-spam mechanism); this prize stops at + producing the verifiable evidence and reputation score). +- A polished consumer UI beyond what's needed for the demo. +- LEZ↔XMR coverage at FCMP++-grade privacy. A submission that addresses LEZ↔BTC + and LEZ↔ETH cleanly is sufficient; LEZ↔XMR with current Monero primitives + (potentially involving view-key disclosure) is a bonus. + +## Prize Structure + +- **Total Prize:** $X +- **Effort:** L + +> Leave prize pool blank — this will be determined by the Logos team. Single +> winner by default. + +## Eligibility + +Open to any individual or team. Submissions must be original work. Teams must +hold the rights to all submitted code and agree to license it under MIT or +Apache-2.0. + +## Submission Requirements + +A submission must include: + +- A public repository containing the LEZ program(s) (if any), client SDK, + proof-bundle format spec, verifier implementation, and aggregation logic. +- A written design document covering the data model, cryptographic primitives, + privacy analysis, adversarial model, and comparison against at least one + existing reputation system. +- A narrated video walkthrough demo showing (a) honest swap completion with + reputation update, (b) a valid complaint scenario where the verifier accepts + the proof bundle, (c) a fabricated complaint scenario where the verifier + rejects it, and (d) the maker reputation score visible to a prospective taker. + The demo must show terminal output including any proof generation with + `RISC0_DEV_MODE=0`. +- A FURPS self-assessment (see + [solution template](https://github.com/logos-co/lambda-prize/blob/main/solutions/LP-0000.md)). + +## Evaluation Process + +By default, submissions are evaluated first-come-first-served against the +success criteria. The first submission that meets all criteria wins. + +Evaluators will independently clone the repository and run the demo script from +a clean environment; the script must succeed without modification. Evaluators +will exercise the valid-complaint and fabricated-complaint scenarios themselves. + +Because the design space is large and multiple valid approaches exist, +evaluators may rank tied submissions on: + +1. Adversarial robustness: how many distinct attack vectors (sybil, spam, + false-complaint, false-rebuttal) the mechanism handles with explicit + countermeasures. +2. Privacy cost: lower disclosure to third parties is preferred. +3. Deployability today: solutions that work with currently-available Monero + primitives (where applicable) rank above solutions that depend on + pre-production cryptography. +4. Integration cleanliness with RFP-003's existing maker daemon. + +The following policies apply to all prizes (see +[evaluation policies](https://github.com/logos-co/lambda-prize/blob/main/README.md#evaluation-policies)): + +- **Submissions:** each builder (or team) is allowed a maximum of **3 + submissions** per prize, with at most **one submission/review per week**. +- **Feedback:** initial evaluation feedback is limited to a pass/fail indication + against the success criteria. + +## Resources + +- [RFP-003: Atomic Swaps with LEZ](https://github.com/logos-co/rfp/blob/master/RFPs/RFP-003-atomic-swaps.md) + — the underlying atomic-swap protocol whose makers this reputation system + tracks. +- [LP-0018: Anti-Spam Mechanism for Atomic Swaps](./LP-0018-atomic-swap-anti-spam.md) + — complementary prize on protocol-level deterrence. Both can be deployed + together. +- [appendix/atomic-swaps-primer.md](https://github.com/logos-co/rfp/blob/master/appendix/atomic-swaps-primer.md) + — atomic-swap mechanics; relevant for understanding what events the reputation + system records. +- [appendix/cross-chain-trust-model-contrast.md](https://github.com/logos-co/rfp/blob/master/appendix/cross-chain-trust-model-contrast.md) + — surveys existing reputation-adjacent mechanisms in deployed protocols + (Wormhole Guardian set, Thorchain bonded validators). +- [Monero, Zero to Monero 2.0 §Payment Proofs](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) + — `check_tx_proof` family (OutProofV2, InProofV2) for understanding what + bilateral disclosure looks like on Monero. +- [Monero, FCMP++ announcement (2024-04-27)](https://www.getmonero.org/2024/04/27/fcmps.html) + — research direction for non-disclosing Monero proofs. Solvers targeting + LEZ↔XMR may want to design with FCMP++ readiness in mind. +- [Wormhole Guardian set](https://wormhole.com/docs/protocol/infrastructure/guardians/) + — example of a reputation-substituting-for-bond mechanism (Proof-of-Authority + committee of named entities). +- [Thorchain RUNE bond-to-pooled docs](https://docs.thorchain.org/understanding-thorchain/rune) + — example of a slashable reputation mechanism in a federated-signer DEX (the + contrast point against atomic-swap-only protocols). + +## Potential for Subsequent λPrizes + +If this prize is awarded for a LEZ↔BTC and LEZ↔ETH mechanism, a follow-up prize +may be opened for LEZ↔XMR coverage once non-disclosing Monero proof primitives +reach production-ready status (FCMP++ is the leading candidate as of 2026-05). From db1ebb29e56d1cf85d98249f85a4cfcd3956b3b7 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 22 May 2026 19:26:47 +1000 Subject: [PATCH 12/17] rfp: apply fact-check minor fixes to appendices Two cosmetic touch-ups from the fact-check agent's report (no critical issues found): - atomic-swaps-primer.md: Han 2019 premium framing tightened from "approximately 2%" to "2-3%", matching the paper's exact "2% ~ 3%" range for cryptocurrency pairs. - cross-chain-trust-model-contrast.md: replaced "four orders of magnitude" with "roughly three-to-four orders of magnitude" for the Thorchain vs Liquality cumulative volume gap. Thorchain $112.2B / Liquality $35M is ~3,200x, which is 3.5 orders of magnitude. Co-Authored-By: Claude Opus 4.7 (1M context) --- appendix/atomic-swaps-primer.md | 8 ++++---- appendix/cross-chain-trust-model-contrast.md | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/appendix/atomic-swaps-primer.md b/appendix/atomic-swaps-primer.md index 89ccea7..a774395 100644 --- a/appendix/atomic-swaps-primer.md +++ b/appendix/atomic-swaps-primer.md @@ -221,10 +221,10 @@ This is the **free-option problem** of atomic swaps. It is not a bug in any particular implementation; it is the cost of atomicity itself. Han, Lin, and Yu 2019 prove the atomic swap is formally equivalent to a premium-free American Call Option and estimate the implicit premium using the Cox-Ross-Rubinstein -option-pricing model at approximately 2% of asset value for cryptocurrency pairs -(vs ~0.3% for stocks and fiat). The paper provides the mechanism and quantifies -the premium; it does not directly attribute deployed-protocol volume scarcity to -the free-option problem. Source: +option-pricing model at 2-3% of asset value for cryptocurrency pairs (vs ~0.3% +for stocks and fiat). The paper provides the mechanism and quantifies the +premium; it does not directly attribute deployed-protocol volume scarcity to the +free-option problem. Source: [Han et al., On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) (accessed 2026-05-22). diff --git a/appendix/cross-chain-trust-model-contrast.md b/appendix/cross-chain-trust-model-contrast.md index b290602..231a13f 100644 --- a/appendix/cross-chain-trust-model-contrast.md +++ b/appendix/cross-chain-trust-model-contrast.md @@ -223,8 +223,8 @@ Atomic-swap protocols: - COMIT, Farcaster, AtomicDEX: no comparable cumulative-volume figure published. Recent activity in all three is community-scale rather than volume-scale. -The gap is four orders of magnitude on cumulative volume in the published -evidence. +The gap is roughly three-to-four orders of magnitude on cumulative volume in the +published evidence. ### Stated rationale from the projects themselves From 03e58c5c06bca41363f1a56cfc3b4fb49089ca64 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 22 May 2026 21:56:16 +1000 Subject: [PATCH 13/17] rfp: apply Round 2 review fixes (10 comments + protocol-constraint correction) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Primer (atomic-swaps-primer.md): - C1: add refund-path Mermaid sequenceDiagram in Timelocks and refunds section showing TxLock → TxCancel → branch: TxRefund (Bob) or TxPunish (Alice after t_2). - C2: accept text suggestion at line 112; drop "The quote is not cryptographically signed" clause. - C3: add paragraph after Han 2019 citation noting eigenwallet runs a community-scale market (3,000+ swaps via GUI in 2023, ~89k cumulative binary downloads, single-digit active makers), demonstrating the free-option problem is a friction rather than absolute blocker. - C3b (substantive): rewrite "Locking order" and "How locking order generalises across pairs" sections. BTC-first in BTC-XMR is now framed as a protocol-level constraint, not just economic. Monero today provides no on-chain primitive supporting the locks-first role in any published atomic-swap construction. Sources: Monero core team's 2026-05-10 deprecating-unlock-time blog post ("no scheme has been specified" using Monero's existing timelock); eigenwallet/protocol commit 6151734 removing the XMR-first chapter; FCMP++ hardfork deprecating the timelock primitive. Economic draining-attack complements but does not replace the protocol constraint. Trust-model contrast (cross-chain-trust-model-contrast.md): - C4: add eigenwallet and Samourai Wallet (atomic-swap GUI) bullet entries to the atomic-swap representative protocols list. Includes vault-sourced adoption figures: eigenwallet 3,000+ swaps via GUI in 2023, ~89,400 cumulative binary downloads, ~2 active mainnet makers, third-party +180% growth attribution; Samourai 2023-08 announcement, 2024-01 beta, 2024-04 seizure, 5/4-year prison sentences in Nov 2025, several-hundred-thousand pre-seizure user base, no first-party swap- volume figure published. Softened the volume-gap prose to acknowledge community-scale adoption is real, not "unused". Synthetics design space (synthetics-design-space.md): - C5: add closing paragraph to sBTC bullet comparing it to Thorchain's bonded-validator model. Same trust class (federation of named or staked signers custodying the underlying asset); differences in size, threshold, and cryptographic construction documented. Lambda prize LP-0018 (anti-spam → spam-protection-for-makers): - C6, C7, C8, C9: retitle in-body to "Spam Protection for Atomic-Swap Makers" (filename unchanged per user). Introduce maker/taker architecture. State LEZ-side-locks-first as a protocol constraint for XMR↔LEZ. Add explicit two-sub-case direction analysis (A: LEZ- taker locks first; B: LEZ-maker locks first, DDoS-exposed). Scope to XMR↔LEZ. Single prize, two acceptable solution shapes. Replace FURPS subsections with three success criteria (proven spam reduction with stats/testimony; no reliability reduction for honest takers; no reliability reduction for honest makers). Move non-pass/fail items into a Design Constraints section. Clean Out-of-Scope: remove polished-UI and LEZ↔XMR-direction-symmetry exclusions. Lambda prize LP-0019 (off-chain reputation → taker reliability): - C10: retitle in-body to "Taker Reliability for Atomic Swaps". Strip the off-chain proof-bundle subsection entirely; replace with generic "design space is open" statement listing on-chain attestation, off-chain proof bundles, slashable bonds, watchtower designs, reputation systems, and hybrids as candidate approaches without prescribing. Mirror LP-0018 structure (maker/taker intro, XMR↔LEZ scope, two sub-cases, three success criteria, Design Constraints section). Decisions log (proposals-review/pr-57-decisions.md): - Append "Round 2 review resolutions 2026-05-22" section logging C1 through C10 plus the C3b protocol-constraint correction. Verification: 0 FURPS headers remain in prizes; both prizes mention XMR↔LEZ six times each; primer has 2 Mermaid sequence diagrams (happy path + refund); trust-model contrast lists eigenwallet and Samourai; all 5 off-chain mentions in LP-0019 are listed as one option among many rather than as the framing. Co-Authored-By: Claude Opus 4.7 (1M context) --- appendix/atomic-swaps-primer.md | 120 ++++-- appendix/cross-chain-trust-model-contrast.md | 50 ++- appendix/synthetics-design-space.md | 14 +- .../LP-0018-atomic-swap-anti-spam.md | 345 ++++++++-------- .../LP-0019-atomic-swap-maker-reputation.md | 388 ++++++++---------- 5 files changed, 484 insertions(+), 433 deletions(-) diff --git a/appendix/atomic-swaps-primer.md b/appendix/atomic-swaps-primer.md index a774395..b76f98f 100644 --- a/appendix/atomic-swaps-primer.md +++ b/appendix/atomic-swaps-primer.md @@ -109,32 +109,50 @@ protocols is key generation, not a quote. In practice, `xmr-btc-swap` and `eigenwallet/core` makers do publish a quote over libp2p before swap setup begins (the maker daemon `asb` computes price from -off-chain ticker data). The quote is not cryptographically signed; it relies on -libp2p's secure-channel authentication for transport-level integrity. This is an -implementation-layer convention used by maker software, not a step of the -protocol. +off-chain ticker data). It relies on libp2p's secure-channel authentication for +transport-level integrity. This is an implementation-layer convention used by +maker software, not a step of the protocol. ### Locking order -The deployed code locks BTC first, but the order is **not forced by the -cryptographic primitive**. Gugger 2020 presents an XMR-first variant; Hoenisch -and del Pino 2021 §4 discuss the same reverse direction. The deployed BTC-first -direction reflects an **economic constraint, not a cryptographic one**. - -The economic constraint (Hoenisch and del Pino 2021 §4, "draining attack"): the -party that locks first incurs the on-chain refund-transaction fee if the swap -aborts. A maker who locks first against an arbitrary counterparty can be -attacked by an adversary who repeatedly initiates swaps and abandons them, -forcing the maker to pay refund fees each time until inventory drains. The party -with the smaller refund-fee burden and the willingness to absorb it should lock -first; in practice this is the customer (Bob, BTC seller in the deployed -direction). - -A reverse XMR-first variant is implementable. It requires adaptor signatures -over Monero's CLSAG ring-signature scheme (rather than over secp256k1 ECDSA). -Hoenisch and del Pino 2021 §4 describe this construction; it was -"work-in-progress" as of the 2021 paper and is not present in `xmr-btc-swap` or -`eigenwallet/core` as of 2026-05. +The deployed code locks BTC first, and this is a **protocol-level constraint** +of the BTC-XMR construction: Monero today provides no on-chain primitive that +would let it play the locks-first role in any published atomic-swap protocol. + +Three primary-source data points support this: + +- The Monero core team's 2026-05-10 blog post *Deprecating Monero's Custom + Transaction Unlock Time* states: *"It is a common misconception that Monero's + Unlock Time is useful for known atomic swap or payment channel protocols. To + date, no scheme has been specified that utilizes Monero's Unlock Time + feature."* Source: + [getmonero.org, 2026-05-10](https://www.getmonero.org/2026/05/10/deprecating-unlock-time.html) + (accessed 2026-05-22). +- The eigenwallet team removed the XMR-first chapter from their compiled + protocol paper on 2025-11-04 with the explanatory comment: *"We don't care + about swaps where the Bitcoin seller is the maker because that is unsupported + by the current Monero protocol. It will require a hardfork to work."* Source: + [eigenwallet/protocol commit 6151734](https://github.com/eigenwallet/protocol) + (accessed 2026-05-22). +- The upcoming FCMP++ hardfork (mid-2026) is *deprecating* Monero's timelock + primitive rather than extending it, and does not introduce any of the + candidate primitives (CLSAG-adaptor signatures, DLSAG, hidden timelocks) that + an XMR-first construction would need. + +The Hoenisch and del Pino 2021 §4 paper describes a reverse XMR-first variant +that would depend on *"adaptor signatures based on Monero's ring signature +scheme, which is a work-in-progress"*. Five years later, no peer-reviewed +Monero-endorsed CLSAG-adaptor construction has been published, and the Monero +project is not pursuing one. Treat XMR-first BTC↔XMR atomic swaps as +structurally unavailable for the foreseeable horizon. Source: +[`projects/xmr-first-required-monero-features.md`](https://github.com/marclawclaw/research-cross-chain-dex) +documents the underlying primary sources; this primer summarises. + +The economic draining-attack analysis (Hoenisch and del Pino 2021 §4) +complements but does not replace the protocol constraint. Even if Monero gained +one of the missing primitives, the draining attack would still push the swap to +BTC-first for any pair where Bitcoin's refund-fee burden is smaller than +Monero's. Both layers point the same direction. ### Timelocks and refunds @@ -152,6 +170,29 @@ counterparty then uses to spend the jointly-locked Monero output. Source: [Hoenisch and del Pino 2021 §3.3](https://arxiv.org/abs/2101.12332). +Refund path (when the swap fails to reach reveal): + +```mermaid +sequenceDiagram + autonumber + participant A as Alice (XMR holder) + participant BTC as Bitcoin + participant B as Bob (BTC holder) + + Note over A,B: TxLock(BTC) confirmed; swap stalls before reveal + Note over A,B: Wait t_1 blocks + A->>BTC: Either party publishes TxCancel (consumes TxLock) + Note over A,B: TxCancel confirmed; refund window now open + + alt Bob refunds within t_2 + B->>BTC: Publish TxRefund (consumes TxCancel) + Note over A,B: Bob recovers BTC; swap unwinds with no settlement + else Bob stays offline past t_2 + A->>BTC: Publish TxPunish (consumes TxCancel after t_2) + Note over A,B: Alice takes Bob's BTC as punishment for non-participation + end +``` + Canonical mainnet values: - **`comit-network/xmr-btc-swap`** (upstream, unmaintained): `t_1 = 72` blocks @@ -228,6 +269,15 @@ free-option problem. Source: [Han et al., On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) (accessed 2026-05-22). +Empirically the free-option problem is a friction rather than an absolute +blocker. eigenwallet runs a community-scale BTC-XMR atomic-swap market with +single-digit active makers, ~89k cumulative binary downloads, and developer- +reported 3,000+ mainnet swaps via the GUI in 2023 alone, demonstrating that the +protocol is workable for privacy-maximalist user bases even without a +free-option mitigation. See the +[trust-model contrast appendix](./cross-chain-trust-model-contrast.md) for +adoption-scale comparison against federated-signer protocols. + ### Notation for option value The expected value of a free option held over a timelock window scales as: @@ -253,17 +303,19 @@ lock-ordering is conventional: both chains can play either role. Operational choice usually puts the chain with the **shorter refund-fee burden** or **stronger maker-side draining-attack protection** first. -For adaptor-signature swaps where one chain has restricted scripting (BTC-XMR, -BTC-Grin), the choice is driven by the draining-attack analysis above. The -deployed `xmr-btc-swap`/`eigenwallet` direction puts the script-bearing chain -(BTC) first because the customer-as-Bob model places the refund-fee burden on -the customer, who tolerates it. - -A reversed direction is implementable for any pair given the right cryptographic -primitives (CLSAG-based adaptor signatures for XMR-first; Schnorr adaptor -signatures for Grin-first, etc.). The choice of direction is not fixed by -cryptography; it is fixed by the economic constraints of who can absorb the -refund-fee burden under adversarial counterparty behaviour. +For adaptor-signature swaps **involving Monero**, the locking order is fixed by +protocol: **the non-Monero side must lock first**, because Monero today provides +no on-chain primitive that supports the locks-first role in any published +atomic-swap construction. This is the same constraint analysed under "Locking +order" above and applies to every XMR↔X pair: X must lock first. The situation +will not change without a Monero hardfork that adds at least one of: DLSAG, +hidden timelocks, or a published CLSAG-adaptor construction adopted by the +Monero project; none of these is on the Monero roadmap as of 2026-05. + +For adaptor-signature swaps with other restricted-scripting chains (Grin and +others), the locks-first rule may be driven by primitive availability or by the +draining-attack economic constraint, depending on what each chain's signature +scheme supports. Each pair must be analysed individually. ## A defensible "BTC-XMR took 4 years" claim diff --git a/appendix/cross-chain-trust-model-contrast.md b/appendix/cross-chain-trust-model-contrast.md index 231a13f..0208223 100644 --- a/appendix/cross-chain-trust-model-contrast.md +++ b/appendix/cross-chain-trust-model-contrast.md @@ -133,6 +133,41 @@ Representative protocols (XMR-BTC corridor specifically): `eigenwallet/core`. Source: [github.com/comit-network/xmr-btc-swap](https://github.com/comit-network/xmr-btc-swap) (accessed 2026-05-19). +- **eigenwallet** (`eigenwallet/core`). Active community fork of + `comit-network/xmr-btc-swap`. Latest release v4.6.4 (2026-05-21); 14 releases + in 47 days as of 2026-05-22. **Adoption signals**: developer self-report of + 3,000+ mainnet swaps via the GUI in 2023 alone (per fully-funded Monero CCS + proposal "From Prototype to Marketplace"); ~89,400 cumulative binary downloads + across `eigenwallet/core` (55,769) and the legacy + `eigenwallet/unstoppableswap-gui` (33,661) repos; ~2 visible mainnet makers on + the public registry on 2026-05-22. A third-party article attributes "+180% + BTC↔XMR atomic-swap volume growth in 2025 (Eigenwallet data)"; no first-party + dashboard exists to verify the percentage. Community-scale, BTC-XMR direction + only. Sources: [eigenwallet/core](https://github.com/eigenwallet/core) + (accessed 2026-05-22); + [Monero CCS: From Prototype to Marketplace](https://ccs.getmonero.org/proposals/mature-atomic-swaps-ecosystem.html) + (accessed 2026-05-22); + [xgram.io: Swap Crypto Between Unlinked Wallets](https://xgram.io/blog/swap-crypto-between-unlinked-wallets) + (accessed 2026-05-22; third-party attribution). +- **Samourai Wallet (atomic-swap GUI)**. Bitcoin privacy wallet that integrated + COMIT's `xmr-btc-swap` codebase via a Java wrapper, with Whirlpool CoinJoin + auto-applied to redeemed BTC. BTC↔XMR atomic-swap GUI announced 2023-08-14, + public beta 2024-01-16; service seized by US authorities on 2024-04-24; + founders sentenced to 5 and 4 years in prison in November 2025 for + money-laundering conspiracy (the prosecution concerned Whirlpool/Ricochet, not + the atomic-swap feature, but the takedown removed the atomic-swap distribution + channel with it). **Adoption signals**: Samourai's pre-seizure user base was + several hundred thousand Bitcoin-privacy-aware users (larger than the + eigenwallet community at the time); the atomic-swap GUI ran for approximately + three months between public beta and seizure, and no first-party swap-volume + number was ever published. The atomic-swap codebase lives on via two community + forks (`noosphere888/samourai-swaps`, `Dezirae-Stark/Atomic-Swaps`); the + latter ships under v1.1.0 on 2026-01-12 and is built on libp2p/Next.js, while + the former has 7 commits on main and no formal releases. Sources: + [DOJ sentencing press release](https://www.justice.gov/usao-sdny/pr/founders-samourai-wallet-cryptocurrency-mixing-service-sentenced-five-and-four-years) + (accessed 2026-05-22); + [news.bitcoin.com: Samourai unveils BTC↔XMR atomic swaps (2023-08-14)](https://news.bitcoin.com/revolutionizing-bitcoin-privacy-samourai-wallet-unveils-btc-to-xmr-atomic-swaps/) + (accessed 2026-05-22). - **Farcaster Project** (`farcaster-project/farcaster-node`). Independent BTC-XMR implementation. Still listed as actively maintained as of 2026, with Lightning BTC support added to reduce BTC-side confirmation time. @@ -220,11 +255,16 @@ Atomic-swap protocols: its wallet and interface" lifetime. Source: [defiprime.com: Liquality](https://defiprime.com/liquality) (accessed 2026-05-19). -- COMIT, Farcaster, AtomicDEX: no comparable cumulative-volume figure published. - Recent activity in all three is community-scale rather than volume-scale. - -The gap is roughly three-to-four orders of magnitude on cumulative volume in the -published evidence. +- COMIT, eigenwallet, Farcaster, AtomicDEX: no comparable cumulative-volume + figure published. Recent activity is community-scale rather than volume-scale. + eigenwallet specifically reports 3,000+ mainnet swaps via the GUI in 2023 + alone (developer self-report in a fully-funded Monero CCS) and ~89k cumulative + binary downloads, signals of a real if small user base. + +The cumulative-volume gap is roughly three-to-four orders of magnitude in the +published evidence. The atomic-swap protocols are not *unused* — they have +documented community-scale adoption — but they are not volume-competitive with +the federated-signer middle chains. ### Stated rationale from the projects themselves diff --git a/appendix/synthetics-design-space.md b/appendix/synthetics-design-space.md index 34a19b7..d5dbf14 100644 --- a/appendix/synthetics-design-space.md +++ b/appendix/synthetics-design-space.md @@ -84,7 +84,19 @@ valued by direct redemption. [docs.stacks.co/concepts/sbtc](https://docs.stacks.co/concepts/sbtc) (accessed 2026-05-22); [Hiro: Who are the sBTC signers, breaking down SIP-028](https://www.hiro.so/blog/who-are-the-sbtc-signers-breaking-down-sip-028) - (accessed 2026-05-22). + (accessed 2026-05-22). The trust shape is structurally similar to Thorchain's + bonded-validator model (see the + [trust-model contrast appendix](./cross-chain-trust-model-contrast.md) + §Federated-signer middle chain): a set of operators each hold a key in a + multisig and produce co-signed outputs on the underlying chain. The + differences are in size and recruitment of the signer set (15 elected entities + for sBTC vs ~103 active permissionless validators for Thorchain), threshold + (70% for sBTC vs 2/3 for Thorchain), and the cryptographic construction + (Bitcoin script multisig per Hiro's description for sBTC vs GG20 TSS for + Thorchain). Whether to call the difference structural or just operational is + debatable; both are "federation of named or staked signers custodying the + underlying asset", which is the same trust class as RFP-021-style federated + middle chains. - **Secret Monero Bridge** (Secret Network). Mainnet launched August 2021. Multi-signature Monero wallet operated by consensus-node signers (MSCNOs) communicating over I2P; users deposit XMR, receive sXMR (a SNIP-20 token on diff --git a/lambda-prizes/LP-0018-atomic-swap-anti-spam.md b/lambda-prizes/LP-0018-atomic-swap-anti-spam.md index 68e0d36..d53cc40 100644 --- a/lambda-prizes/LP-0018-atomic-swap-anti-spam.md +++ b/lambda-prizes/LP-0018-atomic-swap-anti-spam.md @@ -2,7 +2,7 @@ -# LP-0018: Anti-Spam Mechanism for Atomic Swaps [Draft] +# LP-0018: Spam Protection for Atomic-Swap Makers [Draft] **`Status`**: @@ -14,168 +14,150 @@ ## Overview -Atomic swaps are deliberately symmetric: either party can refuse the next -message at any stage and both sides refund at timeout. This is the design, not a -bug. But it lets a malicious taker spam makers: lock funds against a maker's -quote, wait until the price moves, complete or refund accordingly. The refund -branch costs the taker only a few external-chain transaction fees, while the -maker's inventory is wedged for the lock window and the maker absorbs the loss -when the taker walks. Han et al. (IACR 2019/896) prove this is formally -equivalent to a premium-free American Call Option and quantify the implicit -premium at approximately 2% of asset value for crypto pairs. - -This prize is for an **innovative mechanism that prices out the taker's free -option** in the LEZ atomic-swap protocol (RFP-003), without specifying the -mechanism. The bar is a working implementation that demonstrably deters spam and -free-option exploitation while preserving the non-custodial -cryptographic-trust-only properties of the underlying atomic swap. Reference -prior art exists +Atomic-swap markets have a maker/taker architecture. A **maker** is a persistent +identity that publishes quotes and holds inventory ready to swap; a **taker** is +a one-shot user who initiates a swap against a maker's quote. The maker invests +in identity (discovery, reputation, often capital) over many swaps; the taker +may be anonymous and one-shot. This asymmetry is the design. + +But it leaves the maker exposed to **spam by malicious takers**. In every +direction of an atomic-swap protocol, one side locks first and the other side +locks second. Whoever locks first incurs the on-chain refund-transaction fee if +the swap aborts, and the second party gets to observe the first lock and decide +whether to advance (the free-option problem; see +[atomic-swaps primer §The free-option problem](../appendix/atomic-swaps-primer.md#the-free-option-problem)). +When the maker is the locks-first side, an adversarial taker can spam by +initiating and abandoning swaps repeatedly, costing the maker only the refund +transaction fee per cycle — exactly the "draining attack" Hoenisch and del Pino +2021 §4 analyses. + +This prize is for a **mechanism that protects atomic-swap makers from taker +spam** in the LEZ atomic-swap protocol (RFP-003), without specifying the +mechanism. Solvers are free to design bonds, fee-burns, deposits, reputation, +slashing schemes, or any combination, as long as the chosen mechanism delivers +proven spam reduction while preserving honest-taker and honest-maker +reliability. Reference prior art exists ([eigenwallet PR #675](https://github.com/eigenwallet/core/pull/675)); the prize -does not prescribe that approach. Solvers are free to design bonds, fee-burns, -reputation, deposits, slashing schemes, or any combination, as long as the -chosen mechanism survives the evaluation against the success criteria below. +does not prescribe that approach. + +### Scope: XMR↔LEZ, both directions + +For BTC-XMR, the protocol design makes the *taker* the locks-first side (BTC +seller is the customer), which limits spam exposure to the standard +draining-attack cost. **For XMR↔LEZ this is not freely chooseable.** Monero +today provides no on-chain primitive that supports the locks-first role in any +published atomic-swap construction, so **the LEZ side must always lock first**, +regardless of trade direction. See +[atomic-swaps primer §Locking order](../appendix/atomic-swaps-primer.md#locking-order); +the constraint is protocol-level, not economic. This creates two distinct +sub-cases for XMR↔LEZ: + +- **Sub-case A: LEZ-side party is the *taker*** (trade direction LEZ→XMR; user + holds Logos, wants XMR). The taker locks LEZ first. The maker holds the + post-lock free option — he sees the taker's LEZ lock and decides whether to + lock XMR off-chain. The mechanism must price or close the maker's free option + without harming the taker's experience. Candidate examples include a fee-burn + or non-refundable deposit on the LEZ refund branch (cf. eigenwallet PR #675 + for BTC). Not prescribed. +- **Sub-case B: LEZ-side party is the *maker*** (trade direction XMR→LEZ; user + holds XMR, wants Logos). The maker locks LEZ first. The taker can spam the + maker by repeatedly initiating-and-abandoning swaps — exactly the + draining-attack condition the BTC-first ordering is meant to eliminate for + BTC-XMR, but which we cannot eliminate for XMR-LEZ in this direction because + LEZ must lock first regardless. The mechanism must protect the maker from this + spam. Candidate approaches include reputation, taker-side bonds, taker + fee-burns, or other. + +**Scope of this prize: XMR↔LEZ only.** Follow-up prizes can cover LEZ↔BTC, +LEZ↔ETH, or other pairs once the XMR↔LEZ case has a winning mechanism. + +**Single prize, two acceptable solution shapes.** Applicants may address +sub-case A only, sub-case B only, or both. A submission that addresses both +sub-cases coherently ranks above one that addresses only one, but a credible +single-sub-case mechanism is sufficient to win. ## Motivation -The atomic-swap branch of the cross-chain DEX design tree has known structural -weakness on the free-option problem. The Logos cross-chain DEX bundle (RFPs 021, -024, 025) keeps the vanilla RFP-003 atomic swap as the privacy-non-custodial -primitive, but vanilla atomic swaps remain economically unattractive for makers -at any scale because of the free-option exposure. Without a credible anti-spam -mechanism, the maker side of the LEZ atomic-swap market collapses to a hobbyist -scale (see [eigenwallet](https://github.com/eigenwallet/core/): community-scale, +The atomic-swap branch of the cross-chain DEX design tree has a known structural +weakness on the free-option / spam-the-maker problem. The Logos cross-chain DEX +bundle (RFPs 021, 024, 025) keeps the vanilla RFP-003 atomic swap as the +privacy-non-custodial primitive, but vanilla atomic swaps remain economically +unattractive for makers at scale because of the spam exposure. Without a +credible spam-protection mechanism, the maker side of the LEZ atomic-swap market +is likely to remain at hobbyist scale (see +[eigenwallet](https://github.com/eigenwallet/core/): community-scale, single-digit active makers, BTC→XMR direction only). A competitive prize is the right mechanism because the design space is large and -the right answer is not obvious: - -- **On-LEZ bonds** price the option premium via slashable collateral; they - require LEZ-denominated capital from at least one side and they only work at - boundaries that LEZ can observe (Tier 1 pairs like LEZ↔BTC, LEZ↔ETH). -- **External-chain fee-burns on the refund branch** - ([eigenwallet PR #675](https://github.com/eigenwallet/core/pull/675)) price - the option premium by destroying a fraction of locked principal on the - script-bearing chain. They reach boundaries that LEZ cannot observe but they - cost real principal on every refund (no refund on honest completion) and they - require careful incentive design so the maker cannot weaponise the deposit. -- **Reputation-based deterrence** (the subject of the companion prize - [LP-0019](./LP-0019-atomic-swap-maker-reputation.md)) provides soft pressure - on repeat makers; first-time and anonymous takers escape this entirely. -- **Hybrid designs** combining the above in different proportions. - -Each carries trade-offs in capital efficiency, capital denomination, anti-DDoS -coverage, and how it interacts with the LEZ↔XMR asymmetric case (where the -XMR-side lock is not LEZ-observable). The Logos team does not want to pre-judge -the answer; this prize is open to any approach. +the right answer is not obvious. On-LEZ bonds, external-chain fee-burns, +reputation gating, hybrid designs, or approaches we have not anticipated may all +qualify. The Logos team does not want to pre-judge. ## Success Criteria -### Functionality - -- [ ] Demonstrably deters a taker who would otherwise lock an external-chain - asset against a maker's quote and walk via the refund branch at near-zero - cost. The submission must include a clearly-documented adversarial scenario - and show how the mechanism makes the abort branch EV-negative for the taker. -- [ ] Works in at least one trade direction for the LEZ↔BTC pair (the corridor - with the most existing prior art) and clearly states which other pairs - (LEZ↔ETH, LEZ↔XMR in both directions) the mechanism covers, with justification - for any exclusions. -- [ ] Compatible with the RFP-003 LEZ atomic-swap SDK as the underlying - primitive; does not require changes to the cryptographic core (joint-key - setup, adaptor signature, lock, reveal). -- [ ] Preserves non-custody: no third party (signer set, validator, oracle, - attestor) holds user funds at any stage. The mechanism cannot reintroduce the - federated-custody trust assumption. -- [ ] Survives the maker-locks-first case (in BTC→XMR direction, the Bitcoin - side locks first by deployed convention). The mechanism must price the option - held by whichever side locks first. -- [ ] Burnt or escrowed principal in adverse paths is **not** payable to the - counterparty in a way that creates new griefing incentives (e.g. if the maker - can profit by provoking a refund, that defeats the purpose). The submission - must include an incentive-compatibility argument. -- [ ] Handles connectivity-loss / honest-refund cases gracefully: an honest - party who refunds due to connectivity issues should not lose - disproportionately. -- [ ] Discoverable parameters: the cost the taker faces under the mechanism - (deposit fraction, bond size, etc.) is known to the taker before they initiate - the swap; quote-level discovery is acceptable. - -### Usability - -- [ ] Provide a module/SDK that can be used to build Logos modules for - interacting with the program. -- [ ] Provide a Logos Basecamp app GUI with local build instructions, - downloadable assets, and loadable in Logos app (Basecamp). -- [ ] Provide an IDL for the LEZ program, using the - [SPEL framework](https://github.com/logos-co/spel). - -### Reliability - -- [ ] The mechanism does not introduce new failure modes that lock user funds - permanently in protocol-construction-error states. Every escrowed amount must - have a finite-time recovery path under all adversarial choices the - counterparty can make. -- [ ] Race conditions between counterparty actions (e.g. simultaneous refund and - claim attempts) are documented and resolved deterministically. - -### Performance - -- [ ] Document the compute unit (CU) cost of each on-chain operation introduced - by the mechanism, on both LEZ devnet/testnet and the external chain (Bitcoin, - Ethereum, etc.) if the mechanism touches those. -- [ ] Quantify the additional transaction count vs vanilla RFP-003 atomic swap - (e.g. how many additional Bitcoin transactions does a refund involve). -- [ ] State the expected external-chain transaction-fee cost ranges under normal - and high-fee regimes (Bitcoin mempool congestion in particular). - -### Supportability - -- [ ] The program is deployed and tested on LEZ devnet/testnet. -- [ ] End-to-end integration tests run against a LEZ sequencer (standalone mode) - and are included in CI. -- [ ] CI must be green on the default branch. -- [ ] A README documents end-to-end usage: deployment steps, program addresses, - and step-by-step instructions for interacting with the program via CLI and - Basecamp app. -- [ ] A reproducible end-to-end demo script is provided and works against a real - local sequencer with `RISC0_DEV_MODE=0`. -- [ ] A recorded video demo of the end-to-end flow is included in the - submission; the recording must show terminal output (including proof - generation) to confirm `RISC0_DEV_MODE=0` was active. -- [ ] The demo includes at least one "adversarial taker spams the maker" - scenario where the mechanism deters the attack, plus the honest-completion - scenario where the mechanism imposes no cost on honest users. +- [ ] **Proven spam reduction.** The submission must include hard stats (e.g. + measured per-maker spam-attempt rate before and after the mechanism over a + stated observation window) and/or testimony from at least two independent + active makers running the mechanism in production. Toy numbers from a testnet + alone are not sufficient — the prize requires the solution be polished, used, + and adopted. +- [ ] **No reduction in reliability for honest takers.** An honest taker + initiating a legitimate swap should not experience materially worse liveness, + settlement time, or failure rate than under the vanilla RFP-003 protocol. + Quantify against a baseline. +- [ ] **No reduction in reliability for honest makers.** An honest maker serving + legitimate takers should not experience materially worse liveness or capital + efficiency than under the vanilla RFP-003 protocol. Quantify against a + baseline. + +## Design constraints + +These are framing, not pass/fail criteria. Submissions that violate them are +unlikely to deliver the success criteria above, but the criteria above are what +evaluators measure. + +- **Compatible with the RFP-003 LEZ atomic-swap SDK as the underlying + primitive.** The mechanism should not require changes to the cryptographic + core (joint-key setup, adaptor signature, lock, reveal). Solvers may add + escrow logic around the swap. +- **Preserves non-custody.** No third party (signer set, validator, oracle, + attestor) should hold user funds at any stage. Reintroducing federated trust + defeats the purpose; RFP-021 already covers that design space. +- **Survives the LEZ-locks-first protocol constraint.** For XMR↔LEZ the LEZ side + locks first in both sub-cases (A and B). The mechanism must work under this + constraint, not assume it can be reversed. +- **Burnt or escrowed principal in adverse paths is not payable to the + counterparty in a way that creates new griefing incentives.** If a defaulting + taker's deposit is paid to the maker, the maker has an incentive to provoke + refunds; this defeats the purpose. Burn destinations (unspendable outputs) or + rebated-to-protocol designs are acceptable; counterparty-paid designs are not. +- **Honest-refund / connectivity-loss paths.** An honest party who refunds due + to connectivity issues should not lose disproportionately. The mechanism's + cost in adverse paths should be bounded. +- **Discoverable parameters.** The cost the taker faces under the mechanism + (deposit fraction, bond size, fee fraction, etc.) should be known to the taker + before they initiate the swap. Quote-level discovery is acceptable. ## Scope ### In Scope -- The anti-spam mechanism itself: design, on-chain components (LEZ program, - external-chain script changes if any), client-side SDK, and integration with - RFP-003's per-pair atomic-swap modules. -- Incentive analysis: a written argument for why the mechanism is - incentive-compatible and what attacker strategies it deters or admits. -- One concrete pair (LEZ↔BTC is the recommended starting point; LEZ↔ETH or - LEZ↔XMR is acceptable if justified). -- A reference integration: working demo of a swap that uses the mechanism, - including at least one adversarial path that exercises the deterrent. +- The spam-protection mechanism itself: design, on-chain components (LEZ + program, external-chain script changes if any), client-side SDK, integration + with RFP-003's per-pair atomic-swap modules. +- One or both XMR↔LEZ sub-cases (A and/or B), with an incentive-compatibility + argument that explains why the mechanism makes the abort branch EV-negative + for the attacker. +- A reference deployment with active makers and takers running the mechanism in + production long enough to gather the proven-reduction stats / testimony. ### Out of Scope - Modifying the underlying RFP-003 atomic-swap cryptography (joint-key setup, - adaptor signature, lock/reveal). Solvers may add escrow logic around the swap - but must not alter the swap primitive itself. + adaptor signature, lock/reveal). - Reintroducing federated trust (TSS custody, signer sets, oracle attestors). - RFP-021 covers the federated-custody design space; this prize is for - non-custodial mechanisms. -- A polished consumer UI beyond what's needed for the demo. -- Ongoing maintenance, security audit, or mainnet deployment beyond the testnet - integration. -- Solving the LEZ↔XMR direction-symmetry problem in full (the residual off-LEZ - option that vanilla atomic swaps inherently leave open; see also the companion - prize [LP-0019](./LP-0019-atomic-swap-maker-reputation.md) on the off-chain - reputation side of the same problem). A submission that addresses the LEZ↔BTC - case cleanly is sufficient; addressing LEZ↔XMR is a bonus. + RFP-021 covers that design space. +- LEZ↔BTC, LEZ↔ETH, or other non-XMR pairs. Follow-up prizes if needed. ## Prize Structure @@ -196,38 +178,36 @@ Apache-2.0. A submission must include: - A public repository containing the LEZ program(s), client SDK, integration - tests, demo script, and any external-chain script changes. -- A written design document (in the repo) covering the mechanism, the - adversarial model, the incentive-compatibility argument, and any honest-refund - / connectivity-loss handling. -- A narrated video walkthrough demo showing (a) honest completion, (b) at least - one adversarial-taker scenario where the mechanism deters the attack, and (c) - any external-chain transactions involved. The demo must show terminal output - including proof generation with `RISC0_DEV_MODE=0`. -- A FURPS self-assessment (see - [solution template](https://github.com/logos-co/lambda-prize/blob/main/solutions/LP-0000.md)). -- A short comparison section against the reference prior art (at minimum: - eigenwallet PR #675), stating what the submission borrows, where it diverges, - and why. + tests, and any external-chain script changes. +- A written design document covering the mechanism, the adversarial model, the + incentive-compatibility argument, and the honest-refund / connectivity-loss + handling. +- Proven-reduction evidence: hard stats from a real deployment, and/or signed + testimony from at least two independent active makers running the mechanism. +- A narrated video walkthrough demo showing (a) honest completion at no extra + cost to honest parties, and (b) at least one adversarial-taker scenario where + the mechanism deters the attack. +- A short comparison against reference prior art (minimum: eigenwallet PR #675), + stating what the submission borrows, where it diverges, and why. ## Evaluation Process By default, submissions are evaluated first-come-first-served against the success criteria. The first submission that meets all criteria wins. -Evaluators will independently clone the repository and run the demo script from -a clean environment; the script must succeed without modification. Evaluators -will also exercise at least one adversarial-taker scenario themselves to verify -the deterrent. +Evaluators will independently clone the repository, run the demo script, +exercise at least one adversarial-taker scenario, and verify the +proven-reduction evidence (cross-checking testimony with the named makers). Because the design space is large and multiple valid approaches exist, evaluators may rank tied submissions on: -1. Coverage across pairs (a mechanism that handles LEZ↔BTC, LEZ↔ETH, and at - least one direction of LEZ↔XMR ranks above one that handles only LEZ↔BTC). -2. Capital efficiency (mechanisms that impose less cost on honest users rank - above mechanisms that always impose cost). -3. Incentive-compatibility argument quality. +1. Coverage across sub-cases (a mechanism addressing both A and B ranks above + one addressing only one). +2. Magnitude of demonstrated spam reduction and quality of the adoption + evidence. +3. Capital efficiency: mechanisms that impose less cost on honest users rank + above mechanisms that always impose cost. 4. Integration cleanliness with RFP-003's existing per-pair modules. The following policies apply to all prizes (see @@ -243,35 +223,32 @@ The following policies apply to all prizes (see - [RFP-003: Atomic Swaps with LEZ](https://github.com/logos-co/rfp/blob/master/RFPs/RFP-003-atomic-swaps.md) — the vanilla atomic-swap protocol this mechanism builds on. - [eigenwallet PR #675: fee-burn on refunds](https://github.com/eigenwallet/core/pull/675) - — reference prior art; an open proposal that introduces a non-refundable burn - on the refund branch via maker-set deposit fraction, withhold path, and mercy - release. Solvers are free to adopt, adapt, or reject this approach. + — reference prior art; an open proposal introducing a non-refundable burn on + the refund branch via maker-set deposit fraction, withhold path, and mercy + release. Solvers may adopt, adapt, or reject. - [eigenwallet/core release 4.0.0 anti-spam deposit](https://github.com/eigenwallet/core/releases/tag/4.0.0) — shipped narrower mechanism (cancel-timelock reduction plus 30-minute withhold/mercy) that PR #675 generalises. - [appendix/atomic-swaps-primer.md](https://github.com/logos-co/rfp/blob/master/appendix/atomic-swaps-primer.md) - — atomic-swap mechanics, free-option framing, `σ × √T × notional` notation for - sizing. + — atomic-swap mechanics, free-option framing, locking-order protocol + constraint, `σ × √T × notional` notation. - [appendix/cross-chain-trust-model-contrast.md](https://github.com/logos-co/rfp/blob/master/appendix/cross-chain-trust-model-contrast.md) — the federated-signers-vs-atomic-swaps trust contrast that motivates keeping atomic swaps non-custodial. - [Han, Lin, Yu, On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) - — the canonical free-option-problem paper; proves formal equivalence to a - premium-free American Call Option and estimates the implicit premium at ~2% of - asset value for crypto pairs. -- [Gugger, Bitcoin-Monero Cross-chain Atomic Swap, IACR 2020/1126](https://eprint.iacr.org/2020/1126.pdf) - — protocol fundamentals; relevant for direction-dependence analysis. + — formal proof that an atomic swap is equivalent to a premium-free American + Call Option; quantifies the implicit premium at 2-3% of asset value for + cryptocurrency pairs. - [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332](https://arxiv.org/abs/2101.12332) — §4 covers the draining-attack analysis that determines which side locks - first, useful for solvers reasoning about XMR-first variants. -- [LP-0019: Off-Chain Verifiable Reputation for Atomic-Swap Makers](./LP-0019-atomic-swap-maker-reputation.md) - — companion prize that addresses the reputation layer. A submission may - consume LP-0019's reputation primitive as part of its design. + first under economic considerations, useful for solvers reasoning about + sub-cases A and B. +- [LP-0019: Taker Reliability for Atomic Swaps](./LP-0019-atomic-swap-maker-reputation.md) + — companion prize, the dual problem (taker exposure to maker misbehaviour). A + submission may consume LP-0019's reputation primitive as part of its design. ## Potential for Subsequent λPrizes -If this prize is awarded for a LEZ↔BTC-only mechanism, a follow-up prize may be -opened for LEZ↔XMR coverage once non-disclosing Monero proof primitives (FCMP++ -or equivalent) reach production-ready status, since LEZ↔XMR has structural -challenges (the off-LEZ lock is not observable from LEZ) that this prize does -not require solvers to address. +If this prize is awarded for an XMR↔LEZ mechanism, follow-up prizes may cover +other pairs (LEZ↔BTC, LEZ↔ETH) where the locks-first constraint is less +restrictive and the spam-protection design space differs. diff --git a/lambda-prizes/LP-0019-atomic-swap-maker-reputation.md b/lambda-prizes/LP-0019-atomic-swap-maker-reputation.md index b619ac9..30b7491 100644 --- a/lambda-prizes/LP-0019-atomic-swap-maker-reputation.md +++ b/lambda-prizes/LP-0019-atomic-swap-maker-reputation.md @@ -2,7 +2,7 @@ -# LP-0019: Off-Chain Verifiable Reputation for Atomic-Swap Makers [Draft] +# LP-0019: Taker Reliability for Atomic Swaps [Draft] **`Status`**: @@ -14,183 +14,160 @@ ## Overview -In any atomic-swap protocol there are abandonment paths the on-chain settlement -contract cannot adjudicate. The clearest example sits in the LEZ↔XMR direction -(RFP-003 LEZ atomic-swap protocol's Tier-2 case): a maker who has received a -counterparty's Monero lock can refuse to advance on LEZ, and the LEZ contract -cannot tell whether the maker is malicious or the counterparty never actually -locked. The Monero side is not observable from LEZ without view-key disclosure -(which would deanonymise the swap output). The protocol falls back to a -he-said-she-said dispute; the only recourse is *reputation*. - -The Logos cross-chain DEX bundle treats this as a real gap in the vanilla -atomic-swap protocol and does not pretend slashing or attestor-based mechanisms -can close it without reintroducing trust. This prize is for a **mechanism that -lets honest counterparties publish third-party-verifiable evidence of maker -misbehaviour**, so a reputation system built on top of vanilla atomic swaps -(RFP-003) can be both privacy-respecting and adversarially robust. The Logos -team does not pre-judge how. Solvers may use view-key disclosure with privacy -mitigations, FCMP++-grade zk proofs, multi-party attestation schemes, watchtower -designs, or any combination, as long as the resulting reputation system survives -the evaluation against the success criteria below. +Atomic-swap markets have a maker/taker architecture (see +[LP-0018 §Overview](./LP-0018-atomic-swap-anti-spam.md#overview)). The **maker** +is a persistent identity holding inventory; the **taker** is a one-shot user +initiating a swap against a maker's quote. This prize addresses the **taker's +exposure to maker misbehaviour**. + +Concrete maker misbehaviours that hurt takers include: + +- **Quote-and-walk.** Maker publishes a quote, taker initiates a swap, maker + refuses to lock the destination asset after the taker locks. Taker's funds are + wedged for the full refund window before recovery. +- **Refusal to advance after taker lock.** Maker received the taker's lock event + but chooses not to claim or advance. The protocol unwinds, but the taker pays + time and fees. +- **Selectively serving (maker discriminates).** Maker honours some takers and + griefs others, with no protocol-level recourse. +- **Disappearance mid-swap.** Maker goes offline after partial progress; the + swap times out via refund paths but the taker bears the latency cost. + +In the LEZ atomic-swap protocol (RFP-003), the on-chain settlement contract can +detect *some* maker misbehaviour from LEZ state alone (failure to lock the LEZ +leg before timeout, failure to publish the reveal). For events that LEZ cannot +see — particularly any event on the Monero side — the protocol cannot adjudicate +without help. + +This prize is for a **mechanism that delivers measurable taker-reliability +improvement against maker misbehaviour** in the LEZ atomic-swap protocol, +without specifying the mechanism. The design space is open: solvers may use +on-chain attestation, off-chain proof bundles, slashable bonds, watchtower +designs, reputation systems, or any combination, as long as the resulting +mechanism delivers proven taker-reliability improvement while preserving +honest-maker and honest-taker reliability. + +This prize is the **dual of LP-0018**: + +- LP-0018 protects the maker against malicious or spamming *takers*. +- LP-0019 (this prize) protects the taker against malicious or unreliable + *makers*. + +Both can be deployed together. + +### Scope: XMR↔LEZ, both directions + +For XMR↔LEZ, the LEZ side must lock first by protocol (Monero today provides no +on-chain primitive that supports the locks-first role in any published +atomic-swap construction; see +[atomic-swaps primer §Locking order](../appendix/atomic-swaps-primer.md#locking-order)). +This creates two sub-cases the prize covers: + +- **Sub-case A: LEZ-side party is the *taker*** (LEZ→XMR; taker holds Logos, + wants XMR). The taker locks LEZ first, then waits for the maker to lock XMR + off-chain. The maker can quote-and-walk by never locking XMR. From LEZ alone + the protocol cannot tell whether the maker walked or the taker's claim of a + quote-and-walk is fabricated. **Mechanisms that improve taker reliability in + this sub-case must produce maker-misbehaviour evidence that other parties can + verify** (so the taker is not left with a he-said-she-said dispute). +- **Sub-case B: LEZ-side party is the *maker*** (XMR→LEZ; taker holds XMR, wants + Logos). The maker locks LEZ first, then waits for the taker to advance with + the reveal. From LEZ the protocol can detect the maker's lock directly; + taker-reliability concerns here focus on **maker selective serving** (refusing + to quote, refusing to honour a quote, quoting deceptively) and on **liveness** + (maker disappearing mid-swap after their LEZ lock has confirmed). + +**Scope of this prize: XMR↔LEZ only.** Follow-up prizes may cover other pairs. + +**Single prize, two acceptable solution shapes.** Applicants may address +sub-case A only, sub-case B only, or both. A submission addressing both ranks +above one addressing only one, but a credible single-sub-case mechanism is +sufficient to win. ## Motivation -A reputation system that records only successful swaps is useless: it cannot -deter misbehaviour because misbehaviour leaves no on-chain trace. A reputation -system that records every counterparty complaint without filtering is worse than -useless: a malicious *taker* can manufacture false complaints against an honest -maker. - -The hard problem is producing evidence of "maker received a counterparty lock -and did not advance" that **any third party with access to the relevant -blockchain state can verify, without trusting the complainant**. This is -non-trivial in the LEZ↔XMR case because the Monero output is not directly -readable from outside the bilateral context, and the natural disclosure -(view-key + lock-amount) deanonymises the swap. +In an atomic-swap protocol with no reputation or attribution layer, every taker +swap is a first-time interaction. A maker who misbehaves once can disappear and +reappear under a new identity at zero cost; a maker who misbehaves +systematically against some takers but not others has no protocol-level +deterrent. Vanilla RFP-003 atomic swaps cannot offer the taker the kind of "I +know this counterparty has reliably served thousands of swaps" guarantee that +middle-chain DEXes get for free (their counterparty is the protocol). A competitive prize is the right mechanism because the design space is large and -no published solution exists: - -- **Naive view-key disclosure**: complainant publishes the shared view key plus - the lock transaction so any third party can verify the lock against the - maker's signed quote. Cost: the swap output is deanonymised forever to anyone - holding the proof bundle. -- **Selective-disclosure zk proofs over Monero output structure**: prove "an - output of the quoted amount exists at the stealth address derived from this - quote's joint-key transcript" without exposing the view key. Cost: requires - either FCMP++-grade primitives that are pre-production, or a custom proof - system over Monero's CLSAG ring-signatures. -- **Multi-party attestation**: a small committee of attestors observes both - chains and signs off on disputed cases. Cost: reintroduces a trust layer the - bundle is trying to avoid. -- **Watchtower designs**: paid third parties run both Monero and LEZ nodes and - earn fees for issuing attested verdicts. Cost: the watchtower itself becomes a - target. -- **Hybrid**: tiered reputation where most claims are unverifiable but the - highest-stakes claims demand a verifiable proof bundle. - -Each carries trade-offs in privacy cost, cryptographic complexity, deployability -today, and adversarial robustness. The Logos team does not want to pre-judge the -answer; this prize is open to any approach. - -The prize complements but does not depend on LP-0018 (atomic-swap anti-spam -mechanism): a robust reputation system reduces the need for protocol-level -deterrents by making repeated misbehaviour visible across swaps; LP-0018's -mechanisms deter individual misbehaviour without needing cross-swap history. -Both can coexist. +the right answer is not obvious. Reputation systems (on-chain or off-chain), +slashable bonds, watchtower designs, hybrid approaches, or solutions we have not +anticipated may all qualify. The Logos team does not want to pre-judge. ## Success Criteria -### Functionality - -- [ ] An honest counterparty (taker or maker) can publish a proof bundle for a - failed swap that a third party with access to the relevant blockchain state - (LEZ + the relevant external chain) can verify *without trusting the - complainant*. The verification produces one of: valid complaint, invalid - complaint, indeterminate (with documented reason). -- [ ] Covers at least the LEZ↔BTC and LEZ↔ETH cases. Bonus: covers LEZ↔XMR with - documented trade-offs (privacy cost of disclosure, dependency on future Monero - primitives if relevant). -- [ ] The mechanism distinguishes: - - The complainant fabricating a quote: caught by signature verification on the - quote. - - The complainant fabricating a lock: caught by the verifier checking the - external-chain lock against the quote's derived stealth-address / script / - contract. - - The accused successfully rebutting (e.g. presenting their own LEZ activity - proving they advanced): caught by the verifier checking LEZ state. -- [ ] **Sybil resistance.** The cost of building a high-reputation identity to - then defect must exceed the expected gain from defecting. Sybil identities - should not be able to manufacture clean reputation cheaply. -- [ ] **Spam resistance.** A malicious taker cannot mass-publish fake complaints - to deny-of-service the reputation system. Either the cost of publishing a - complaint is bounded below (e.g. micro-fee) or the verifier filters cheaply. -- [ ] **Aggregation method documented.** A maker's overall reputation score is a - function of (verified positive completions, verified valid complaints, - possibly weighted by complainant reputation). The submission must specify the - function and justify it. -- [ ] **Privacy on the complainant side.** A taker complaining about a maker - should not be forced to reveal which other swaps that taker has done, unless - they choose to. (The accused maker is necessarily identifiable since the - complaint is about their identity.) -- [ ] **Existing-project comparison.** The submission must identify at least one - existing reputation system (e.g. Wormhole Guardian set behaviour reporting, - Thorchain bond-to-pooled slashing rules, decentralised review aggregators, - EigenLayer AVS slashing, or other) and explain how the chosen design relates - to or differs from it. - -### Usability - -- [ ] Provide a module/SDK that can be used to build Logos modules for - interacting with the reputation system (querying maker reputation, publishing - complaints, generating proof bundles). -- [ ] Provide a Logos Basecamp app GUI with local build instructions, - downloadable assets, and loadable in Logos app (Basecamp). -- [ ] Provide an IDL for any LEZ programs introduced, using the - [SPEL framework](https://github.com/logos-co/spel). -- [ ] Surface the maker's reputation in a way takers can inspect *before* - initiating a swap. - -### Reliability - -- [ ] Disputed claims (where the verifier returns "indeterminate") are handled - with a documented policy: they are recorded as such, not silently dropped, and - do not falsely degrade either party's reputation. -- [ ] The reputation database is censorship-resistant: it does not depend on a - single host or central index. -- [ ] Storage primitives for the proof bundles (where they live, how long they - persist) are specified. Logos Delivery is the expected substrate. - -### Performance - -- [ ] Document the storage and bandwidth cost per complaint, per verification, - and per reputation query. -- [ ] State the latency from publishing a complaint to it being aggregated into - the maker's reputation score. -- [ ] Document compute unit (CU) cost of any on-chain LEZ operations introduced. - -### Supportability - -- [ ] Any LEZ programs introduced are deployed and tested on LEZ devnet/testnet. -- [ ] End-to-end integration tests run against a LEZ sequencer (standalone mode) - and are included in CI. -- [ ] CI must be green on the default branch. -- [ ] A README documents end-to-end usage: how to publish a complaint, how to - query reputation, how the verifier works. -- [ ] A reproducible end-to-end demo script is provided and works against a real - local sequencer with `RISC0_DEV_MODE=0`. -- [ ] A recorded video demo of the end-to-end flow is included in the - submission; the recording must show terminal output (including proof - generation) to confirm `RISC0_DEV_MODE=0` was active. -- [ ] The demo includes at least one "valid complaint" scenario and one - "fabricated complaint rejected" scenario. +- [ ] **Proven taker-reliability improvement.** The submission must include hard + stats (e.g. measured taker-side swap-success rate before and after the + mechanism, or measured incidence of maker misbehaviour detected/deterred by + the mechanism over a stated observation window) and/or testimony from at least + two independent active takers running against makers integrated with the + mechanism in production. Toy numbers from a testnet alone are not sufficient — + the prize requires the solution be polished, used, and adopted. +- [ ] **No reduction in reliability for honest makers.** An honest maker serving + legitimate takers should not experience materially worse liveness, capital + efficiency, or quote-distribution reach than under the vanilla RFP-003 + protocol. Quantify against a baseline. +- [ ] **No reduction in reliability for honest takers.** The mechanism's own + cost to honest takers (latency, gas, complexity) must not exceed the + unreliability it removes. Quantify against a baseline. + +## Design constraints + +These are framing, not pass/fail criteria. + +- **Compatible with the RFP-003 LEZ atomic-swap SDK as the underlying + primitive.** Do not require changes to the cryptographic core. +- **Preserves non-custody.** No third party (signer set, validator, oracle, + attestor) holds user funds at any stage. Reintroducing federated trust defeats + the purpose; RFP-021 already covers that design space. +- **Adversarially robust.** The mechanism must distinguish a *fabricated* taker + complaint about an honest maker from a *valid* taker complaint about a + malicious maker. Either the protocol detects the difference from observable + state, or the mechanism produces evidence a third party can verify, or the + mechanism penalises false complaints. Any approach is acceptable; the + submission must justify it. +- **Privacy of the taker.** A taker reporting a misbehaving maker should not be + forced to reveal which other swaps the taker has done (beyond the disputed + one), unless the taker chooses to. +- **Spam resistance.** A malicious taker should not be able to mass-publish + fabricated misbehaviour reports to deny-of-service the mechanism. Either the + cost of publishing is bounded below or the verifier filters cheaply. +- **Survives the LEZ↔XMR Monero-unobservability constraint.** For sub-case A + specifically, the Monero side is not directly observable from LEZ. The + mechanism must work under this constraint; it may use any approach (view-key + disclosure, FCMP++-grade zk proofs, watchtower nodes, multi-party attestation, + on-chain attestation by the maker, slashable maker bonds, off-chain proof + bundles, etc.). ## Scope ### In Scope -- The reputation mechanism: data model, proof-bundle structure, verifier design, - aggregation function, anti-spam and anti-sybil mechanisms. -- Storage and distribution: where proof bundles live (Logos Delivery is the - expected substrate); how reputation scores are computed and propagated. -- Client-side: SDK for publishing complaints, generating proof bundles, and - querying reputation. -- A reference integration with RFP-003 LEZ atomic-swap maker daemon, where the - maker's reputation is auto-updated on completed and failed swaps. -- Documentation: cryptographic approach, privacy guarantees, adversarial model, - comparison against at least one existing reputation system in the wild. +- The taker-reliability mechanism: data model, evidence/attribution scheme, + verification approach, aggregation if relevant, anti-spam and anti-fabrication + mechanisms. +- Storage and distribution of any data the mechanism produces (Logos Delivery is + the expected substrate for off-chain data; on-chain mechanisms use LEZ). +- Client-side: SDK for takers to query maker reliability and report + misbehaviour; SDK for makers to dispute false reports if applicable. +- A reference integration with RFP-003 LEZ atomic-swap maker daemon and taker + client. +- A reference deployment with active takers and makers running the mechanism in + production long enough to gather the proven-reliability stats / testimony. ### Out of Scope -- Changing the underlying RFP-003 atomic-swap cryptography. -- Building a protocol-level slashing mechanism on top of the reputation (that - would be the role of LP-0018 (anti-spam mechanism); this prize stops at - producing the verifiable evidence and reputation score). -- A polished consumer UI beyond what's needed for the demo. -- LEZ↔XMR coverage at FCMP++-grade privacy. A submission that addresses LEZ↔BTC - and LEZ↔ETH cleanly is sufficient; LEZ↔XMR with current Monero primitives - (potentially involving view-key disclosure) is a bonus. +- Modifying the underlying RFP-003 atomic-swap cryptography. +- Building a protocol-level slashing mechanism on top of the reliability + evidence (LP-0018 covers the maker-side equivalent; if the mechanisms produce + evidence usable for slashing, integration with LP-0018 is welcomed but not + required). +- LEZ↔BTC, LEZ↔ETH, or other non-XMR pairs. ## Prize Structure @@ -210,40 +187,41 @@ Apache-2.0. A submission must include: -- A public repository containing the LEZ program(s) (if any), client SDK, - proof-bundle format spec, verifier implementation, and aggregation logic. -- A written design document covering the data model, cryptographic primitives, - privacy analysis, adversarial model, and comparison against at least one - existing reputation system. -- A narrated video walkthrough demo showing (a) honest swap completion with - reputation update, (b) a valid complaint scenario where the verifier accepts - the proof bundle, (c) a fabricated complaint scenario where the verifier - rejects it, and (d) the maker reputation score visible to a prospective taker. - The demo must show terminal output including any proof generation with - `RISC0_DEV_MODE=0`. -- A FURPS self-assessment (see - [solution template](https://github.com/logos-co/lambda-prize/blob/main/solutions/LP-0000.md)). +- A public repository containing the LEZ program(s) if any, client SDK, + integration tests, and any external-chain components. +- A written design document covering the mechanism, the adversarial model + (sybil, spam, fabrication, false-rebuttal), the privacy analysis (what the + mechanism reveals about whom), and the LEZ↔XMR-specific handling of Monero + unobservability. +- Proven-reliability evidence: hard stats from a real deployment, and/or signed + testimony from at least two independent active takers running against makers + integrated with the mechanism. +- A narrated video walkthrough demo showing (a) honest swap completion with no + extra cost, (b) a maker-misbehaviour scenario where the mechanism detects and + surfaces the misbehaviour, and (c) a fabricated-complaint scenario where the + mechanism rejects or penalises the fabrication. ## Evaluation Process By default, submissions are evaluated first-come-first-served against the success criteria. The first submission that meets all criteria wins. -Evaluators will independently clone the repository and run the demo script from -a clean environment; the script must succeed without modification. Evaluators -will exercise the valid-complaint and fabricated-complaint scenarios themselves. +Evaluators will independently clone the repository, run the demo, exercise the +maker-misbehaviour and fabricated-complaint scenarios, and verify the +proven-reliability evidence. -Because the design space is large and multiple valid approaches exist, -evaluators may rank tied submissions on: +Tied submissions may be ranked on: -1. Adversarial robustness: how many distinct attack vectors (sybil, spam, - false-complaint, false-rebuttal) the mechanism handles with explicit - countermeasures. -2. Privacy cost: lower disclosure to third parties is preferred. -3. Deployability today: solutions that work with currently-available Monero - primitives (where applicable) rank above solutions that depend on - pre-production cryptography. -4. Integration cleanliness with RFP-003's existing maker daemon. +1. Coverage across sub-cases (a mechanism addressing both A and B ranks above + one addressing only one). +2. Magnitude of demonstrated reliability improvement and quality of the adoption + evidence. +3. Privacy cost (lower disclosure to third parties is preferred where the + mechanism uses disclosure). +4. Adversarial robustness across more distinct attack vectors (sybil, spam, + fabrication, false-rebuttal). +5. Integration cleanliness with RFP-003's existing maker daemon and taker + client. The following policies apply to all prizes (see [evaluation policies](https://github.com/logos-co/lambda-prize/blob/main/README.md#evaluation-policies)): @@ -256,32 +234,24 @@ The following policies apply to all prizes (see ## Resources - [RFP-003: Atomic Swaps with LEZ](https://github.com/logos-co/rfp/blob/master/RFPs/RFP-003-atomic-swaps.md) - — the underlying atomic-swap protocol whose makers this reputation system - tracks. -- [LP-0018: Anti-Spam Mechanism for Atomic Swaps](./LP-0018-atomic-swap-anti-spam.md) - — complementary prize on protocol-level deterrence. Both can be deployed - together. + — the underlying atomic-swap protocol whose makers this mechanism evaluates. +- [LP-0018: Spam Protection for Atomic-Swap Makers](./LP-0018-atomic-swap-anti-spam.md) + — companion prize, the dual problem. Both can be deployed together. - [appendix/atomic-swaps-primer.md](https://github.com/logos-co/rfp/blob/master/appendix/atomic-swaps-primer.md) - — atomic-swap mechanics; relevant for understanding what events the reputation - system records. + — atomic-swap mechanics, locking-order protocol constraint, free-option + framing. - [appendix/cross-chain-trust-model-contrast.md](https://github.com/logos-co/rfp/blob/master/appendix/cross-chain-trust-model-contrast.md) — surveys existing reputation-adjacent mechanisms in deployed protocols - (Wormhole Guardian set, Thorchain bonded validators). + (Wormhole Guardian set, Thorchain bonded validators, sBTC signer federation) + as reference points for solvers. - [Monero, Zero to Monero 2.0 §Payment Proofs](https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) - — `check_tx_proof` family (OutProofV2, InProofV2) for understanding what - bilateral disclosure looks like on Monero. + — `check_tx_proof` family for understanding what bilateral disclosure looks + like on Monero, relevant for sub-case A solvers reasoning about evidence + production. - [Monero, FCMP++ announcement (2024-04-27)](https://www.getmonero.org/2024/04/27/fcmps.html) - — research direction for non-disclosing Monero proofs. Solvers targeting - LEZ↔XMR may want to design with FCMP++ readiness in mind. -- [Wormhole Guardian set](https://wormhole.com/docs/protocol/infrastructure/guardians/) - — example of a reputation-substituting-for-bond mechanism (Proof-of-Authority - committee of named entities). -- [Thorchain RUNE bond-to-pooled docs](https://docs.thorchain.org/understanding-thorchain/rune) - — example of a slashable reputation mechanism in a federated-signer DEX (the - contrast point against atomic-swap-only protocols). + — research direction for non-disclosing Monero proofs. ## Potential for Subsequent λPrizes -If this prize is awarded for a LEZ↔BTC and LEZ↔ETH mechanism, a follow-up prize -may be opened for LEZ↔XMR coverage once non-disclosing Monero proof primitives -reach production-ready status (FCMP++ is the leading candidate as of 2026-05). +If this prize is awarded for an XMR↔LEZ mechanism, follow-up prizes may cover +other pairs once XMR↔LEZ has a winning mechanism. From b4dd216e16b57a77c2d1428d5855bbbfb9ab0637 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 22 May 2026 22:21:45 +1000 Subject: [PATCH 14/17] rfp: split synthetic XMR into three single-purpose RFPs (024/025/026) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The previous bundle conflated three distinct synthetic-XMR designs. The research-vault material supports a clean three-way split, with the team's preference for the CDP-backed design (RFP-024). RFP-024 rewritten as CDP-backed synthetic only: - Mint sXMR against stable collateral on LEZ at oracle price; burn to recover collateral. No atomic swap, no XMR custody, no redemption to Monero L1. Inspired by Synthetix CDP minting (SIP-302 Pools V3). - The atomic-swap-redemption mechanic that was in the old RFP-024 has been extracted to RFP-026. - This is the preferred sXMR design in the bundle. RFP-025 rewritten as real-XMR multisig only: - 1:1 backed by real XMR held in a threshold-signer multisig on Monero (FROST-over-CLSAG per Serai's monero-oxide work). Inspired by sBTC (Stacks) and Secret Network's Secret Monero Bridge. - Overview explicitly flags this as not the team's preferred design, with custody risk and Monero deposit-history leak as the reasons. - Option 2a (bonded LPs with redemption SLA) DROPPED. The slashable LP bond cannot be auto-slashed on a single failed swap because LEZ cannot adjudicate atomic-swap defaults from state alone; without LP-0019 the bond degrades to a gating deposit. The "two sub-designs" framing from the old RFP-025 is gone. RFP-026 created as atomic-swap-redemption module: - Strictly extends RFP-024. RFP-024 and RFP-003 are hard prerequisites. - Adds open-LP-set peer-to-peer atomic-swap redemption from sXMR to real XMR on Monero L1. Soft SLA; no protocol custody; no bonded LPs. - LP-0018 and LP-0019 layerable but not preconditions. RFP-021 slim trim: - Stripped the "Desired properties" FURPS-shaped bullet list per user direction ("all RFPs should be slim but Pros/Cons/Risks stay because that is the critical decision content"). - Bundle-range note updated to "RFP-021, RFP-024, RFP-025, RFP-026". - Relationship section updated to reflect the four-way split. All RFPs (021/024/025/026): - Bundle-range note updated to mention all four RFPs. - "Desired properties" section removed in favour of letting Overview and High-level flow carry the design intent. Pros/Cons/Risks kept in full — those are the decision content. - The note text explicitly says "FURPS detail" is among the omitted decision-stage content. Lambda prizes: - LP-0018 bundle-range mention updated to include RFP-026. - LP-0019 unchanged (no stale bundle references). - LP-0018 and LP-0019 explicitly noted in RFP-024 as not preconditions (the CDP design ships without atomic-swap-specific mitigations), and in RFP-026 as layerable but not preconditions. Decisions log: - Appended "Round 3 restructure 2026-05-22 (synthetics three-way split)" section documenting the design clarification and the new RFP mapping. Co-Authored-By: Claude Opus 4.7 (1M context) --- RFPs/RFP-021-cross-chain-privacy-dex.md | 45 +- RFPs/RFP-024-synthetic-xmr-pure.md | 413 +++++--------- RFPs/RFP-025-synthetic-xmr-sla.md | 505 ++++++------------ RFPs/RFP-026-sxmr-atomic-swap-redemption.md | 196 +++++++ .../LP-0018-atomic-swap-anti-spam.md | 2 +- 5 files changed, 495 insertions(+), 666 deletions(-) create mode 100644 RFPs/RFP-026-sxmr-atomic-swap-redemption.md diff --git a/RFPs/RFP-021-cross-chain-privacy-dex.md b/RFPs/RFP-021-cross-chain-privacy-dex.md index f331dd3..b55505a 100644 --- a/RFPs/RFP-021-cross-chain-privacy-dex.md +++ b/RFPs/RFP-021-cross-chain-privacy-dex.md @@ -10,10 +10,10 @@ category: Applications & Integrations # RFP-021 — Cross-Chain Privacy DEX (Federated Middle Layer) > **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos -> team and the community compare cross-chain DEX designs across RFP-021 through -> RFP-025. Hard requirements, team profile, timeline, and contracting details -> are deliberately omitted; they will be filled in if the design is selected for -> funding. +> team and the community compare cross-chain DEX designs across RFP-021, +> RFP-024, RFP-025, and RFP-026. Hard requirements, FURPS detail, team profile, +> timeline, and contracting details are deliberately omitted; they will be +> filled in if the design is selected for funding. ## 🧭 Overview @@ -37,33 +37,6 @@ This is the most ambitious option in the cross-chain bundle. It is also the one with the strongest empirical case (volume, user experience, asset coverage) and the strongest custody risk. -## Desired properties - -- **Native cross-chain swap.** User deposits BTC, ETH, or XMR; receives the - destination asset on the destination chain in a single user action. No wrapped - tokens linger on LEZ after the swap. -- **AMM-style liquidity.** A single ordered state machine maintains pool - invariants (`xy=k` or comparable). Large swaps clear against pooled liquidity, - not against a per-trade counterparty. -- **One-step UX.** Deposit-with-memo, await outbound. No counterparty - interactivity, no refund flows, no online-availability requirement past - broadcast. -- **Bonded validator set with slashable misbehaviour.** Validators stake against - the assets they custody; the bond-to-custodied-value ratio is enforced in - protocol (Serai uses a 33% custody cap; Thorchain uses 2:1 bonded plus 1:1 - pooled). -- **LEZ-native privacy execution.** Shielded swap intents (the user's swap is a - commitment, not a public memo); sealed-bid batch matching with threshold - decryption (collapses identity-based front-running); stealth outbound - addresses on destination chains (breaks destination-chain clustering even for - chains with no native privacy). -- **Permissioned-by-stake but censorship-resistant.** Anyone can join the - validator set by posting the required stake; validator-set rotation occurs on - a known cadence (Thorchain churns every 3 days; Serai per session). -- **Emergency halt mechanism.** Used three times in Thorchain's history; the - protocol must be able to freeze outbounds on suspected custody compromise or - consensus fault. - ## High-level functionality and flow ```mermaid @@ -204,10 +177,12 @@ solvency or signing failure. LEZ. RFP-021 is *cross-chain* with vault custody. Distinct scopes; the two could ship in parallel and serve different user journeys (intra-LEZ shielded trading vs cross-chain settlement). -- **RFP-024 (sXMR pure)** and **RFP-025 (sXMR with SLA)** target a different - product: synthetic XMR exposure inside LEZ DeFi, with atomic-swap redemption - to real XMR. They are orthogonal to RFP-021 and could ship alongside it, - sharing the same LEZ privacy primitives. +- **RFP-024 (sXMR CDP-backed)**, **RFP-025 (sXMR real-XMR multisig)**, and + **RFP-026 (sXMR atomic-swap redemption)** target a different product: + synthetic XMR exposure inside LEZ DeFi. They are orthogonal to RFP-021 and + could ship alongside it, sharing the same LEZ privacy primitives. RFP-025 + shares the federated-signer custody pattern with RFP-021 and could share + signer-set infrastructure. See [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) diff --git a/RFPs/RFP-024-synthetic-xmr-pure.md b/RFPs/RFP-024-synthetic-xmr-pure.md index 78ff6da..97c2871 100644 --- a/RFPs/RFP-024-synthetic-xmr-pure.md +++ b/RFPs/RFP-024-synthetic-xmr-pure.md @@ -1,322 +1,175 @@ --- id: RFP-024 -title: Synthetic XMR (sXMR), Pure Non-Custodial Design +title: Synthetic XMR (sXMR) — CDP-Backed Synthetic tier: XL funding: $TBD status: draft category: Applications & Integrations --- -# RFP-024 — Synthetic XMR (sXMR), Pure Non-Custodial Design +# RFP-024 — Synthetic XMR (sXMR), CDP-Backed Synthetic > **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos -> team and the community compare cross-chain DEX designs across RFP-021 through -> RFP-025. Hard requirements, team profile, timeline, and contracting details -> are deliberately omitted; they will be filled in if the design is selected for -> funding. +> team and the community compare cross-chain DEX designs across RFP-021, +> RFP-024, RFP-025, and RFP-026. Hard requirements, FURPS detail, team profile, +> timeline, and contracting details are deliberately omitted; they will be +> filled in if the design is selected for funding. ## 🧭 Overview -Build a synthetic XMR token (sXMR) on LEZ that tracks the XMR price via oracle, -is composable across LEZ DeFi, and redeems to real XMR via peer-to-peer atomic -swap. The protocol holds no XMR, runs no signer set, and offers no redemption -SLA. - -The wedge: no published, live synthetic redeems to real XMR on Monero L1 -*non-custodially, via peer-to-peer atomic swap*. Two distinct prior-art families -exist, neither of which fills this corner: - -- **Bridge-custodied real XMR.** Secret Network's Secret Monero Bridge (live - since August 2021) ran sXMR as a SNIP-20 token bridged via a multi-signature - Monero wallet operated by consensus-node operators; the trust shape is a - signer set, not peer-to-peer atomicity. Source: - [github.com/maxkoda-cpu/Secret-Monero-Bridge](https://github.com/maxkoda-cpu/Secret-Monero-Bridge) - (accessed 2026-05-22). -- **CDP-collateralised oracle-priced synth, no real XMR.** Synthetix listed sXMR - on Ethereum L1 (Hadar release, 2020-03-30) as an SNX-collateralised - oracle-priced ERC-20; the contract held no Monero, only SNX collateral was at - risk, and the synth was not redeemable to XMR. Source: - [Synthetix blog: Hadar release](https://blog.synthetix.io/new-synths-update-for-the-upcoming-hadar-release/) - (accessed 2026-05-22). The Synthetix sXMR and the Secret Network sXMR share a - ticker but are unrelated products; see - [appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) - §Two unrelated sXMR products. - -Other commodity-tracking synthetics (sBTC on Stacks, sETH-style synths) redeem -to transparent assets, leaving the destination on a public ledger. The Haven -Protocol xAsset family (xUSD and other privacy-preserving xAssets) ran on a -Monero-forked L1 from 2018 until project closure on 2024-12-12 (a range-proof -validation vulnerability allowed unbounded illicit minting; >94% of known XHV -supply was controlled by attackers at closure). Haven never offered an xXMR -product; its design was over-collateralised synthetics minted against XHV, not -peer-to-peer atomic-swap redemption. Source: -[Haven Protocol: Project Closure Announcement (2024-12-12)](https://havenprotocol.org/2024/12/12/project-closure-announcement/) -(accessed 2026-05-22). Haven's shutdown is a structural failure mode worth -noting: the same ring-signature properties that protect users prevent -post-incident wallet identification and freezing. - -**Inspired by existing prior art.** The minting side follows the well-known -**Synthetix CDP design** (SIP-302 Pools V3 for the V3 reference; the wider -sUSD/SNX collateralisation pattern dating to 2018). See +Build a synthetic XMR token (sXMR) on LEZ that tracks the XMR price via oracle. +Users mint sXMR by locking stable collateral (or other governance-approved LEZ +assets) into a CDP-style vault, similar to the Synthetix V3 Pools mechanic +(SIP-302). Users burn sXMR to recover their collateral. The protocol holds no +XMR at any point and does not deposit XMR on Monero L1 — sXMR is a *debt +instrument against stable collateral*, not a wrapped asset. + +Inspired by **Synthetix CDP minting** (SIP-302 Pools V3). The closest deployed +analogue: Synthetix's own historical sXMR ERC-20 (Hadar release, 2020-03-30), +which was SNX-collateralised and oracle-priced via Chainlink, never redeemable +for real XMR. See [appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) -§Oracle-priced over-collateralised synthetics for the deployed-protocol survey. -The redemption side follows the **eigenwallet/COMIT BTC-XMR atomic-swap -pattern** (peer-to-peer adaptor-signature swap, open LP set, no custody); see -the [atomic-swaps primer](../appendix/atomic-swaps-primer.md). The novelty is -the *combination*: a Synthetix-style CDP minted against stable collateral, -redeemed via an eigenwallet-style atomic swap to real XMR, with no protocol-held -custody at any step. Neither half is new; the join is. - -**Trade-off accepted up front.** This RFP deliberately leaves the free option of -the redemption-leg atomic swap unpriced. Goal 1's premise is that a -privacy-maximalist user base will tolerate variable redemption availability (LPs -may be slow to show up, spreads may widen under stress) in exchange for the -cleanest non-custody story. The unpriced free option is the explicit cost the -protocol pays for that positioning; LPs bear it. Anti-spam mechanisms that price -the option (see lambda prize -[LP-0018](../lambda-prizes/LP-0018-atomic-swap-anti-spam.md)) and off-chain -maker reputation (see -[LP-0019](../lambda-prizes/LP-0019-atomic-swap-maker-reputation.md)) may be -layered on top once available, but neither is a precondition of this RFP. If the -SLA matters more than non-custody, choose RFP-025 instead. - -This RFP positions itself as the first design where the redemption path itself -is both privacy-preserving (deposits real XMR on Monero L1) and non-custodial -(atomic-swap rather than signer-set bridge). See -[appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) -for the deployed-synthetics survey including the Secret Monero Bridge negative -case, and -[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) -for the federated-signer-vs-atomic-swap trust contrast. - -The honest framing: this is a synthetic with a soft, market-clearing peg, not a -hard-redeemable synthetic. The oracle is the *quoted* price; the *achievable* -price is whatever an XMR LP will swap for, when one is willing. Structurally -closer to a DEX trading pair than to sBTC (Stacks). The product fits a -privacy-maximalist audience that wants XMR-shaped exposure inside LEZ DeFi -without depending on protocol-held custody. +§Oracle-priced over-collateralised synthetics. -## Desired properties - -- **Non-custodial.** No vault holds XMR. No signer set. No bridge. -- **Soft peg.** The oracle is a reference price; the achievable redemption price - is whatever an LP quotes. Spread widens under stress without bound. -- **No redemption guarantee.** A counterparty may not exist when the user wants - to exit. The protocol does not commit to availability. -- **Composable on LEZ.** sXMR is a vanilla LEZ token (the LEZ token program - standard from RFP-003 hard requirement 7), callable by any other LEZ program: - lending markets, DEXes, governance, structured products. -- **Private exit.** Successful redemption deposits real XMR on Monero L1, - severing the public trail. The XMR side never touches LEZ. -- **Open LP set.** Anyone with XMR can quote. No permission required; no LP - registry; no bond. -- **Regulatory minimalism.** The protocol does not handle XMR; it is, in - defensible terms, a price feed plus a matching board for users to find each - other. -- **Off-chain orderbook.** Quotes and intents flow over Logos Delivery (the same - coordination primitive RFP-003 uses for maker advertisement). The on-chain - artefact is the atomic-swap settlement program; the matching itself is - bilateral and off-chain. +This is the preferred sXMR design in the bundle. RFP-025 (real-asset multisig) +carries custody risk and a Monero deposit-history leak; RFP-026 layers +atomic-swap redemption on top of this RFP for users who want to exit to real XMR +on Monero L1 (but does not change the CDP mint mechanic). ## High-level functionality and flow +```mermaid +flowchart LR + User[User] -- deposit stable collateral --> Vault[sXMR CDP vault on LEZ] + Vault -- mint sXMR at oracle price --> User + Oracle[XMR/USD oracle] -- price feed --> Vault + User -- burn sXMR + interest --> Vault + Vault -- release collateral --> User + Liq[Liquidation keeper] -- liquidate undercollateralised vault --> Vault ``` - sXMR LEZ program oracle (XMR/USD) Oracle program on LEZ - (token + stable vault) <---------------------- - - mint | burn - - Intent gossip match Open XMR LPs - (off-chain via Logos (anonymous; free - Delivery) to enter/exit) - sXMR <--> XMR quotes - - atomic swap (adaptor-sig protocol from RFP-003) - LEZ <------------------------------> Monero L1 - - sXMR holder gets XMR XMR LP gets sXMR, - on Monero L1 burns for stable -``` - -### Mint - -A user deposits a stable (or other LEZ-accepted asset) into the sXMR collateral -vault on LEZ; the protocol mints sXMR to the user at the current oracle price -(with a configurable mint fee). The vault holds the collateral; sXMR circulates -freely. - -### Redemption (the privacy-preserving exit) - -1. Alice (sXMR holder) signals intent to redeem over Logos Delivery. -2. Bob (open-set XMR LP) sees the intent, computes his quote (oracle price plus - his spread), and replies bilaterally. -3. Alice accepts; Alice and Bob execute an atomic swap using the RFP-003 LEZ-XMR - SDK. Alice's sXMR is burned on LEZ; Bob's XMR arrives on Monero at an address - Alice controls. The matching, the quote, and the bilateral acknowledgement - happen off-chain over Logos Delivery and Logos Chat. -4. Bob's swapped sXMR is burned by Bob; the released stable collateral becomes - Bob's payout (less any protocol fee). - -### Failure modes (no protocol enforcement) -- If Bob walks away mid-swap, the atomic-swap timelock returns Alice's sXMR; she - retains her position. -- If no Bob exists, Alice's sXMR trades at a discount to oracle until a Bob - shows up or Alice gives up. There is no protocol-side compensation for - redemption delay. +- **Mint.** A user deposits stable collateral (or other governance-approved LEZ + assets) into the sXMR vault on LEZ. The protocol mints sXMR at the current + oracle price, up to a configurable issuance ratio (minimum c-ratio). The user + holds sXMR; the vault holds the collateral. +- **Burn / unwind.** The user repays sXMR (plus any interest/fees) and the vault + releases the collateral. +- **Liquidation.** If the vault's c-ratio breaches the threshold (oracle price + moves against the user), a liquidation keeper closes the position and returns + surplus collateral to the user, less penalty. +- **Trading.** sXMR is a vanilla LEZ token; users trade it against stables on + RFP-004 or any other LEZ DEX. The price tracks oracle within whatever spread + the market clears. + +There is **no atomic swap and no XMR custody in this RFP**. A user who wants +real XMR on Monero L1 either sells sXMR on a DEX (and takes the spread), or uses +RFP-026 (atomic-swap redemption built on top of this RFP) once that ships. ## Pros -- **Cleanest privacy story in the bundle.** Successful redemption ends with real - XMR on Monero L1. No protocol-side custody, no signer-set deposit-history leak - (the RFP-021 and RFP-025 option 2b weakness), no view-key disclosure (the - Monero unobservability constraint inherited from the underlying atomic-swap - primitive; see [atomic-swaps primer](../appendix/atomic-swaps-primer.md)). -- **Cryptographic non-custody is full.** No vault, no bond, no SLA. The trust - assumption is the oracle (for pricing) and the soundness of the RFP-003 - atomic-swap protocol. The protocol cannot lose user funds in a custody breach - because it does not have custody. -- **Composable from day one.** sXMR is a vanilla LEZ token; lending markets and - DEXes can integrate without coordinating with the sXMR team. The product - surface scales with the rest of LEZ DeFi. -- **Regulatory defensibility is highest.** The protocol does not handle XMR. - Operators of price feeds and matching boards have meaningfully different - exposure from operators of XMR-custodying bridges. -- **Lowest engineering cost in the bundle's synthetics line.** No SLA - enforcement; no LP registry; no slashing logic; no signer-set custody. The - core deliverable is a token, a collateral vault, an oracle integration, and an - intent layer over Logos Delivery. -- **Open LP set is censorship-resistant.** No permissioned set; no KYC; no - operator that can be coerced into refusing service. +- **Strongest non-custody story.** The protocol never touches XMR; the vault + holds only LEZ-side stable collateral. No signer set, no multisig, no bridge, + no Monero deposit-history leak. +- **Composable from day one.** sXMR is a vanilla LEZ token; lending markets, + DEXes, governance, structured products can integrate without coordinating with + the sXMR team. +- **Regulatory defensibility highest in the bundle.** The protocol is, in + defensible terms, a price feed plus a collateral vault. Operators of price + feeds have meaningfully different exposure from operators of XMR-custodying + bridges. +- **Independent of atomic-swap UX issues.** Mint and burn are LEZ-native + operations; there is no atomic-swap latency, no maker discovery, no + counterparty interactivity required for the core product. +- **Lowest engineering cost in the bundle's synthetics line.** Existing CDP + designs (Synthetix, MakerDAO, Liquity) provide a well-mapped implementation + template; the work is adapting those patterns to LEZ. +- **Builders are not blocked on LP-0018 or LP-0019.** Atomic-swap-specific + concerns (taker spam, maker reliability) do not apply to the CDP mint path; + those issues affect RFP-026 only. ## Cons -- **Soft peg widens under stress without bound.** The achievable redemption - price is the marginal LP quote. If LPs vanish, sXMR can trade at any discount - to oracle; the protocol cannot intervene. -- **No redemption SLA.** Users who want guaranteed redemption (institutions, - market makers, structured products) cannot use sXMR directly under Goal 1; - they need RFP-025. -- **Predicted demand asymmetry.** Mint demand is expected to be easy - (privacy-curious DeFi users want XMR exposure inside LEZ); LP supply is - expected to be harder to source (XMR maximalists may not want a public LP role - at all, even pseudonymous). The LP side is the predicted structural - bottleneck; applicants should validate against early LP onboarding before - scaling. -- **Predicted adverse selection of LPs.** LPs are expected to show up when - oracle is below true market XMR price (free money for them on the redemption - leg) and to vanish when oracle is above (would-be loss). Redemption - availability is expected to be asymmetric across regimes; analogous to - uncollateralised peer-to-peer market-making in other venues but unverified for - this product. -- **Atomic-swap UX inherited.** Settlement time is dominated by Monero block - confirmations, typically under an hour but with variance from network - conditions; both parties online for the duration. The intent layer over Logos - Delivery softens this but cannot remove it. -- **No protocol-side enforcement of LP behaviour.** Refusing to proceed is - *valid behaviour* under the atomic-swap protocol; the protocol cannot - distinguish malicious refusal from connectivity loss. Off-chain maker - reputation (see lambda prize - [LP-0019](../lambda-prizes/LP-0019-atomic-swap-maker-reputation.md)) is the - only available restraint, and even then it operates as soft pressure, not - enforcement. -- **Oracle dependency.** The oracle is the only price signal; oracle attack or - stale price degrades minting accuracy. Mitigation lives outside this RFP - (existing oracle RFPs in the bundle, or oracle aggregation patterns). +- **No path to real XMR within this RFP.** A user who wants XMR on Monero L1 + must either accept the secondary-market discount (sell sXMR for stables, buy + XMR off-platform) or wait for RFP-026 to ship and use that. The "synthetic" is + genuinely synthetic: no underlying-asset redemption. +- **Soft peg only.** sXMR tracks oracle within whatever spread the secondary + market clears. Under stress (oracle staleness, collateral crunch, panicked + unwinds) the peg can widen meaningfully. +- **Debt pool socialisation considerations.** In a V2-style debt pool, all sXMR + holders share aggregate Synth debt; in V3-style per-pool debt, the same + accounting model applies within a pool. Applicants must pick a model and + document its failure modes. +- **Privacy is partial.** sXMR is *not* a private asset on LEZ on its own; the + token program is public state. Privacy must come from LEZ-native shielding + (RFP-004's shielded swap intents, deshield-swap-reshield patterns). The CDP + vault and the mint/burn flow are public. +- **Open question: does Logos want a synthetic that does not redeem to the + underlying?** Synthetix-style synths have proven they can sustain liquidity + for major asset classes (sUSD, sETH) but Synthetix sXMR itself never achieved + meaningful volume. The XMR audience may specifically want real XMR, not a debt + instrument that tracks it. ## Risks -- **LP exodus.** All XMR holders stop quoting. sXMR trades at an indefinite - discount to oracle until LPs return. Mitigation: design the protocol to - survive long discount regimes without auto-liquidation; let the discount be - the market signal that restores LP supply. - **Oracle manipulation.** A manipulated XMR/USD oracle lets an attacker mint - sXMR cheaply or under-collateralise existing positions. Mitigation: use a - redundant oracle stack with median-of-N pricing; impose configurable - price-deviation guards on minting. -- **Collateral solvency.** If the collateral asset (stables or otherwise) is - itself compromised (depeg, exploit, regulatory freeze), sXMR backing degrades. - Mitigation: accept only collateral with documented threat models; cap - protocol-wide collateral concentration by asset. -- **Privacy-claim overreach.** sXMR itself is *not* a private asset on LEZ (the - token program is public state). The privacy property applies *only* to the - redemption-to-XMR path. If users mint sXMR from a public LEZ account and never - redeem, no privacy is conferred. The communication challenge is non-trivial; - documentation must be honest. -- **Regulatory inflection on Monero.** If a jurisdiction outlaws Monero - entirely, the redemption path becomes legally fraught for LPs in that - jurisdiction. The protocol itself is insulated (it does not handle XMR) but - the LP economy may concentrate in friendlier jurisdictions. Strategic, not - technical. -- **Atomic-swap maker burnout.** The free-option problem - ([atomic-swaps primer §The free-option problem](../appendix/atomic-swaps-primer.md#the-free-option-problem)) - applies here too: LPs can be free-optioned by takers. The pure design accepts - this as the cost of Goal 1's non-custody positioning. Mitigation: optional - layered consumption of the anti-spam mechanism - ([LP-0018](../lambda-prizes/LP-0018-atomic-swap-anti-spam.md)) or off-chain - maker reputation - ([LP-0019](../lambda-prizes/LP-0019-atomic-swap-maker-reputation.md)) for the - redemption leg, as separate products on top of the same sXMR token. Neither is - a precondition. -- **No protocol-side fee revenue capture.** Open LP set means LPs capture the - spread; the protocol's only revenue is mint and burn fees on sXMR itself. - Sustainability depends on mint/burn volume, which depends on LEZ DeFi - composability adoption. + sXMR cheaply or under-collateralise existing positions. Mitigation: redundant + oracle stack with median-of-N pricing; configurable price-deviation guards; + oracle-staleness checks. +- **Collateral solvency.** If the collateral asset (stables) depegs or is + compromised, sXMR backing degrades. Mitigation: accept only collateral with + documented threat models; cap protocol-wide collateral concentration by asset; + require liquidation parameters that hold under collateral-asset volatility. +- **Liquidation infrastructure under-built.** A CDP design that does not have + working keeper bots and a profitable liquidation incentive will hit insolvency + on the first market shock. Mitigation: design liquidation incentives + carefully; budget engineering for keeper operations; document MEV + considerations. +- **Demand asymmetry.** Mint demand may be easy (LEZ-DeFi users want XMR + exposure inside LEZ) but secondary-market XMR liquidity may not materialise. + The CDP design absorbs this — there is no LP bottleneck — but the token's + tradability is bottlenecked by LEZ DEX adoption. +- **Privacy-claim overreach.** sXMR is not a private asset; the privacy property + is only that *the underlying asset XMR is private*. Mint/burn on LEZ is + public. Documentation must be honest. +- **Synthetix-sXMR precedent.** Synthetix listed sXMR in 2020 and it did not + achieve meaningful adoption. Mitigation: LEZ-native privacy positioning and + tight LEZ-DeFi integration may differentiate, but applicants should validate + demand before building. ## Relationship to other RFPs in this bundle -- **RFP-003 (Atomic Swaps with LEZ, open)** is the foundation: the LEZ-XMR - atomic-swap SDK is the redemption settlement layer. RFP-024 does not modify - RFP-003; it builds the sXMR product on top of it. -- **RFP-025 (sXMR with SLA)** is the complementary design. RFP-024 targets the - privacy-maximalist audience accepting market-clearing redemption; RFP-025 - targets the SLA-needing audience accepting custody risk. The two together - cover the synthetics design space. A reader should pick one or both based on - which user segment they want to serve. -- **Lambda prize - [LP-0018 (atomic-swap anti-spam mechanism)](../lambda-prizes/LP-0018-atomic-swap-anti-spam.md)** - could be layered on the redemption-leg atomic swap if and when a winning - mechanism ships. Not a precondition; the pure design works without it. -- **Lambda prize - [LP-0019 (off-chain maker reputation)](../lambda-prizes/LP-0019-atomic-swap-maker-reputation.md)** - could provide LP-discovery UX (takers see LP reputation before initiating). - Not a precondition; the open LP set with no reputation works for the - privacy-maximalist user base. -- **RFP-021 (cross-chain privacy DEX)** is orthogonal. RFP-021 offers real-XMR - cross-chain swaps with federated custody; RFP-024 offers synthetic-XMR - exposure with atomic-swap redemption. Different products; same broad audience - can use both. -- **RFP-004 (Privacy-Preserving DEX, open)** is the natural single-chain trading - venue for sXMR once minted. Trade sXMR against stables on RFP-004's AMM pools - under the deshield-swap-reshield pattern; redeem to real XMR via RFP-024. +- **RFP-003 (Atomic Swaps with LEZ, open)** is not a dependency of this RFP. + RFP-024 is a CDP design that does not interact with atomic swaps. RFP-026 + layers atomic-swap redemption on top of this RFP. +- **RFP-021 (cross-chain privacy DEX)** is the federated-custody alternative for + real-XMR exposure. Orthogonal product: RFP-024 gives synthetic XMR exposure + inside LEZ DeFi without custody; RFP-021 gives real XMR via a federated middle + layer. +- **RFP-025 (sXMR as real-XMR locked in trusted multisig)** is the not-preferred + alternative for real-XMR-backed sXMR. The two RFPs target the same audience + differently: RFP-024 says "we don't custody XMR"; RFP-025 says "we do, via a + federated multisig". RFP-024 is preferred. +- **RFP-026 (sXMR atomic-swap redemption to real XMR)** strictly extends this + RFP. RFP-024 ships first; RFP-026 adds an atomic-swap exit path for users who + want to redeem to Monero L1. RFP-026 does not re-spec the CDP mint mechanic. +- **RFP-004 (Privacy-Preserving DEX)** is the natural single-chain trading venue + for sXMR. Trade sXMR against stables on RFP-004's AMM pools under the + shield/deshield pattern. +- **LP-0018 and LP-0019** are atomic-swap-specific prizes; they affect RFP-026 + only. See [appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) -for the deployed-synthetics survey (Haven, Synthetix, sBTC, Secret Monero -Bridge) and the privacy-coin specific constraints. See -[appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) for -atomic-swap mechanics and the free-option framing relevant to the redemption-leg -LP economics. +for the deployed-synthetics taxonomy and the Synthetix CDP minting reference. ## References - [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) - [appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) -- [appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) - [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) -- [Bitcoin to Monero atomic swaps (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) - (accessed 2026-05-21) -- [eigenwallet/core (active fork of comit-network/xmr-btc-swap; v4.6.1, 2026-05-15)](https://github.com/eigenwallet/core) - (accessed 2026-05-21) -- [Secret Network Monero Bridge (custodial XMR-to-Secret Network bridge, deployed prior art)](https://github.com/maxkoda-cpu/Secret-Monero-Bridge) - (accessed 2026-05-22) -- [Haven Protocol documentation](https://docs.havenprotocol.org) (accessed - 2026-05-22) -- [docs.stacks.co/concepts/sbtc](https://docs.stacks.co/concepts/sbtc) (accessed - 2026-05-22) -- [Hiro: Who are the sBTC signers, breaking down SIP-028](https://www.hiro.so/blog/who-are-the-sbtc-signers-breaking-down-sip-028) - (accessed 2026-05-22) -- [Synthetix blog: New Synths update for the upcoming Hadar release](https://blog.synthetix.io/new-synths-update-for-the-upcoming-hadar-release/) - (accessed 2026-05-22) -- [Haven Protocol: Project Closure Announcement (2024-12-12)](https://havenprotocol.org/2024/12/12/project-closure-announcement/) - (accessed 2026-05-22) +- [Synthetix SIP-302 (Pools V3)](https://sips.synthetix.io/sips/sip-302) + (accessed 2026-05-22) — canonical CDP-minting reference, with direct relevance + to sXMR design. +- [Synthetix blog: Hadar release (sXMR ERC-20, 2020-03-30)](https://blog.synthetix.io/new-synths-update-for-the-upcoming-hadar-release/) + (accessed 2026-05-22) — historical Synthetix sXMR listing. diff --git a/RFPs/RFP-025-synthetic-xmr-sla.md b/RFPs/RFP-025-synthetic-xmr-sla.md index 7b8145a..93eb37d 100644 --- a/RFPs/RFP-025-synthetic-xmr-sla.md +++ b/RFPs/RFP-025-synthetic-xmr-sla.md @@ -1,390 +1,193 @@ --- id: RFP-025 -title: Synthetic XMR (sXMR) with Redemption SLA +title: Synthetic XMR (sXMR) — Real XMR in Threshold-Signer Multisig tier: XL funding: $TBD status: draft category: Applications & Integrations --- -# RFP-025 — Synthetic XMR (sXMR) with Redemption SLA +# RFP-025 — Synthetic XMR (sXMR) Backed by Real XMR in Trusted Multisig > **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos -> team and the community compare cross-chain DEX designs across RFP-021 through -> RFP-025. Hard requirements, team profile, timeline, and contracting details -> are deliberately omitted; they will be filled in if the design is selected for -> funding. +> team and the community compare cross-chain DEX designs across RFP-021, +> RFP-024, RFP-025, and RFP-026. Hard requirements, FURPS detail, team profile, +> timeline, and contracting details are deliberately omitted; they will be +> filled in if the design is selected for funding. +> +> **The Logos team's current preference is RFP-024 (CDP-backed synthetic) over +> this design.** RFP-025 is documented here so the design space is comparable, +> but the custody and privacy trade-offs (below) make it the less attractive +> option. Read this RFP as "what would it take to do sXMR the sBTC way?" — not +> as "the Logos plan". ## 🧭 Overview -Build a synthetic XMR token (sXMR) on LEZ with a redemption SLA: users can -redeem sXMR for real XMR at oracle price, on demand, up to the protocol's -committed capacity. The atomic swap is still the settlement primitive, but -counterparty availability is no longer left to the open market. +Build a synthetic XMR token (sXMR) on LEZ backed 1:1 by real XMR held in a +threshold-signer multisig on Monero. Users mint sXMR by depositing XMR into the +protocol's Monero-side multisig; users redeem sXMR by burning the LEZ-side token +to trigger a multisig-signed Monero spend back to the user. The token is a +*wrapped representation* of custodied XMR, not a debt instrument against stable +collateral. -The RFP requires applicants to commit to one of two sub-designs: - -- **Option 2a: Bonded LP set.** LPs join a registered set on LEZ, post stable - collateral as bond, and are obligated to honour redemption requests within a - window. Default triggers bond slashing paid to the redeemer. Non-custodial in - the strict sense (LPs hold their own XMR) but bonded for performance. -- **Option 2b: Protocol XMR reserve.** The protocol accumulates an XMR reserve - (from mint fees, a yield programme, or a one-time treasury seed) held in a - threshold-signer multisig on Monero. Redemption draws directly from the - reserve. Custodial: trust lives in the signer set. - -The RFP exists so applicants can argue for one of the two and the Logos team can -pick. The two options have different threat models, different LP economics, and -different regulatory exposures. They cannot be combined cleanly: option 2b's -reserve and option 2a's open-but-bonded LP set are different protocols sharing -only the sXMR token name. - -This RFP is the marketable companion to RFP-024 (sXMR pure non-custodial). A -reader should pick at least one of the two, and may pick both, depending on -which user segment they want to serve. - -## Desired properties (both options) - -- **Redemption SLA.** A user redeeming sXMR for XMR receives real XMR on Monero - L1 within a documented window (e.g. 60 minutes for option 2a; instant - settlement subject to atomic-swap timelock for option 2b). -- **Oracle-priced redemption.** Redemption price is within a documented - tolerance of the oracle reference; not subject to LP-quote dispersion. -- **Composable sXMR token on LEZ.** Vanilla LEZ token (the LEZ token program - standard from RFP-003 hard requirement 7), callable by lending, DEXes, - governance, structured products. -- **Private exit.** Successful redemption ends with real XMR on Monero L1. The - XMR side never leaks the redeemer's LEZ-side identity beyond the redemption - flow itself. -- **Bondless taker entry path.** First-time redeemers (the taker side, from the - atomic-swap perspective) are not required to post a LEZ-denominated bond for - the first redemption up to a capped notional (worked example: US$100 - equivalent). After the first redemption, the taker has LEZ-denominated assets - they can post against subsequent redemptions. The bond on the *LP side* - (option 2a) or the *reserve* (option 2b) is unaffected; those are maker-side - or protocol-side constructs. - -## Option 2a: bonded LP set - -LPs join a registered set on LEZ. Each LP posts stable collateral on LEZ equal -to (or some multiple of) their XMR commitment. When a redemption request is -routed to an LP, they must complete the atomic swap within a window. If they -default, their bond is slashed and paid to the redeemer. LPs may leave the set, -but only after a notice period that exceeds the redemption SLA. - -**Inspired by existing prior art.** Option 2a's bonded-LP design is closest in -shape to **Thorchain's bonded-validator model**: a set of operators each post -slashable stake (Thorchain RUNE bonded ≥ ~2× pooled liquidity) and the protocol -enforces performance on the stake. See -[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) -§Federated-signer middle chain for the Thorchain trust-model survey including -the May 2026 GG20/TSSHOCK exploit. The Logos adaptation differs in two respects: -(1) the bonded operators are *XMR sellers committing to redemption SLA*, not -protocol validators co-signing custody; (2) the LP bond is locked for the LP's -tenure plus the notice period, *separate* from any per-swap collateralisation. -The bond is a persistent performance bond against the LP's SLA across many -swaps, not a per-swap collateral. Option 2a inherits Thorchain's structural -problem — slashing requires attribution, and the protocol cannot adjudicate the -attribution from atomic-swap state alone (see the Enforceability caveat below). - -``` - sXMR LEZ program - + LP registry - + slashing logic (depends on an off-chain - attribution layer; see LP-0019) - - redemption LP bond - request - - sXMR holder Bonded LP - burns sXMR, atomic swap posts stable bond - receives XMR <----------------> delivers XMR or - (adaptor-sig) forfeits bond - - if LP defaults: bond paid out as compensation, - attribution layered via LP-0019 reputation system -``` - -**Enforceability caveat.** "LP defaulted" is not a verdict an on-chain program -can render from atomic-swap state alone (per the cross-cutting analysis in -[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md)). -Refusing to proceed is *valid behaviour* under the atomic-swap protocol; the LEZ -contract cannot distinguish malicious refusal from connectivity loss. The -realistic implementation depends on the off-chain reputation system that lambda -prize [LP-0019](../lambda-prizes/LP-0019-atomic-swap-maker-reputation.md) is -expected to deliver: an LP who repeatedly fails to honour redemptions loses -reputation; the bond is slashed against the *attested* default condition, not -against atomic-swap state directly. Without LP-0019 (or an equivalent off-chain -attestation mechanism), the bond can be used only to gate participation -(priority, fee tiers, future-slot access), not slashed with cryptographic -certainty on a single failed swap. - -## Option 2b: protocol XMR reserve - -The protocol holds an XMR reserve in a threshold-signer multisig on Monero. -Redemption draws from the reserve directly, with the atomic swap acting as the -settlement rail between the reserve custodian and the redeemer. - -``` - sXMR LEZ program - + reserve accounting - - burn sXMR trigger swap - - Reserve module - (LEZ program) - - atomic swap - (adaptor-sig) - - Threshold-signer reserve on Monero - (n-of-m, bonded signers, view-key-shared) -``` - -**Inspired by existing prior art.** Option 2b directly adopts **sBTC's (Stacks) -threshold-signer custody model**: a federation of bonded signers (15-signer, 70% -threshold in SIP-028; 14 currently operating with 10-of-14) holds the underlying -asset on its native chain and produces redemptions on-demand. See +Inspired by **sBTC (Stacks)** and **Secret Network's Secret Monero Bridge**. See [appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) -§Redeem-to-underlying with custody for the sBTC trust-shape survey. Option 2b -adds an **oracle-priced peg layer** on top of the sBTC-style custody, replacing -sBTC's 1:1 redemption with oracle-tracked redemption. The structural overlap -with sBTC is the custody side; the peg semantics differ. The same -view-key-shared TSS custody constraint applies as in RFP-021: honest-but-curious -signers learn the protocol-side deposit history. This is the structural -trade-off option 2b accepts in exchange for the redemption SLA. The signer set -must be bonded and slashable to make the trust assumption explicit. - -The TSS custody design itself follows **Serai's FROST-over-CLSAG** approach for -the Monero case (rather than Thorchain's GG20 ECDSA, which suffered the May 2026 -TSSHOCK exploit; see +§Redeem-to-underlying with custody for both reference projects. The TSS custody +for the Monero side follows Serai's FROST-over-CLSAG approach to avoid the +GG20/TSSHOCK class of failures (see [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) -§Federated-signer middle chain). Serai is pre-mainnet as of 2026-05; option 2b -applicants should track Serai's monero-oxide work as the production-ready -FROSTLASS instantiation. - -## High-level functionality and flow (common) - -### Mint - -Identical to RFP-024. User deposits accepted LEZ collateral; protocol mints sXMR -at oracle price; collateral sits in vault. - -### Redemption (option 2a) - -1. Alice (sXMR holder) submits a redemption request to the LEZ sXMR program. -2. Program routes the request to a bonded LP in the registry (round-robin, - reputation-weighted, or auction-priced). -3. LP receives the request; LP and Alice execute an atomic swap via the RFP-003 - LEZ-XMR SDK within the SLA window. -4. On success, Alice's sXMR is burned, LP claims the released collateral as - their payout. -5. On failure (LP times out): bond slashing is triggered. LP-0019 off-chain - reputation attestation establishes that the failure was the LP's fault (not - the redeemer's); slashed bond is paid to the redeemer as compensation; LP's - reputation is decremented. - -### Redemption (option 2b) - -1. Alice submits a redemption request. -2. Program signals the reserve module; threshold signers co-sign a Monero spend - from the reserve to a destination Alice supplies. -3. Atomic-swap protocol enforces the conditional: Alice's sXMR is burned only if - the Monero spend lands on chain. -4. Reserve accounting updates; if the reserve is depleted below a safety - threshold, mints are paused until the reserve is replenished from mint fees - or treasury. - -## Pros (both options) - -- **Redemption SLA is a real product feature.** Institutions, market makers, and - structured-products integrators can underwrite sXMR positions because they - have a documented exit window. -- **Hard peg within capacity.** Redemption price tracks oracle within a - documented tolerance, not LP-quote dispersion. The sXMR token becomes usable - as collateral inside other LEZ programs with predictable mark-to-market. -- **Composable from day one.** Vanilla LEZ token; the SLA is what makes - downstream integrations viable. -- **Private exit preserved.** Successful redemption ends with real XMR on Monero - L1, regardless of which option is chosen. Privacy on the destination chain is - intact. -- **Bondless taker entry path.** Privacy-seeking redeemers without LEZ assets - can complete a first capped redemption without bond friction. - -## Pros (option 2a-specific) - -- **Non-custodial in the strict sense.** LPs custody their own XMR; the protocol - does not hold the underlying asset. No vault to drain. -- **Decentralised LP set.** Anyone meeting the bond requirement can join the - registered set. -- **Slashing bounds the loss.** A defaulting LP's bond becomes the redeemer's - compensation; protocol-wide solvency is bounded by total bonded capacity. -- **No signer-set custody risk for sXMR holders.** Trust assumption is the - bonded-LP set's collective behaviour, which is bounded by the bond size, not - by signer-set integrity. - -## Pros (option 2b-specific) - -- **Strongest SLA guarantee.** Redemption draws from a protocol-managed reserve; - no LP discovery, no per-redemption matching. Settlement is deterministic up to - the atomic-swap protocol's timelock. -- **Predictable redemption capacity.** Bounded by the reserve size; capacity - planning is governance-driven rather than LP-supply-driven. -- **Lower operational complexity for redeemers.** Single counterparty (the - reserve module), not a matched LP. - -## Cons (both options) - -- **Some form of trust returns.** RFP-024 (pure) trusts only the oracle and the - atomic-swap protocol; RFP-025 trusts additionally an LP set (option 2a) or a - signer set (option 2b). The cypherpunk story is weaker. -- **Atomic-swap UX is still inherited.** Settlement time is dominated by Monero - block confirmations, typically under an hour but with variance from network - conditions; both parties online for the duration. The SLA constrains the - *availability* of the counterparty but not the cryptographic settlement time. -- **Oracle dependency is sharper.** With an SLA on oracle-priced redemption, an - oracle failure has SLA-breaking consequences, not just mint-side accuracy - consequences. -- **Regulatory exposure is higher.** A protocol that commits to redeeming a - privacy coin on demand draws more scrutiny than RFP-024's - price-feed-plus-matching-board posture. - -## Cons (option 2a-specific) - -- **Slashing requires off-chain attribution.** The LEZ contract cannot - adjudicate "LP defaulted" from atomic-swap state. LP-0019 off-chain reputation - is the realistic attribution mechanism; without it, the bond gates - participation but does not slash on single defaults. -- **Bond opportunity cost limits LP supply.** Locking stable collateral against - XMR commitment is expensive; LP yield must clear the opportunity cost. - Realistic capacity is constrained by the LP economy's appetite for the - bond/yield trade-off. -- **Coordinated default can exceed bonded capacity.** If many LPs default - simultaneously (e.g. during a Monero price shock), aggregate slashing may not - cover aggregate redemption demand. The peg breaks. -- **LP notice period limits flexibility.** LPs must wait out a notice period - exceeding the SLA before exiting the set; this raises the cost of becoming an - LP. - -## Cons (option 2b-specific) - -- **Custodial.** A signer set holds real XMR on Monero. Custody risk is real: - signer collusion, key compromise, or signing-software bug can drain the - reserve. This is the failure mode that hit Thorchain on 2026-05-15 (TSS - implementation weakness, $10.8M). The Wormhole February 2022 incident ($326M) - is a related-but-distinct category: a per-chain bridge-contract bug - (`load_instruction_at` on Solana) bypassed the signer set entirely rather than - compromising it; the lesson is that per-chain contract surface adds attack - vectors independent of the TSS itself. -- **View-key-shared custody leaks Monero deposit history to signers.** The same - compromise RFP-021 makes. Honest-but-curious signers learn the protocol-side - Monero deposit history; this is the structural cost of TSS custody of XMR with - current cryptography. -- **Adopts sBTC (Stacks)'s threshold-signer custody model, with an oracle-priced - peg replacing 1:1 redemption.** The custody novelty is small relative to - existing custodial XMR wraps (the differentiator is the LEZ privacy execution - on the sXMR token side, plus the explicit slashable-signer-bond posture). -- **Reserve undercollateralisation breaks the peg.** If the reserve is drawn - down faster than it can be replenished from fees, redemption capacity goes to - zero; sXMR loses its peg. -- **Signer-set membership is gated.** Lower decentralisation than option 2a; - signer set is a censorship and coercion target. - -## Risks (both options) - -- **Oracle manipulation.** A manipulated XMR/USD oracle lets an attacker mint - sXMR cheaply or extract reserve XMR (option 2b) at unfavourable rates. - Mitigation: redundant oracle stack with median-of-N pricing; configurable - price-deviation guards; SLA-aware oracle staleness checks. -- **Regulatory action.** Either option may attract jurisdiction-specific bans on - the protocol, LP participation, or reserve custody. Mitigation: jurisdictional - diversity in LP set or signer set; documented compliance posture; willingness - to operate as a permissionless smart contract regardless of any single - jurisdiction's stance. -- **First-swap cap evasion.** A redeemer could split a large redemption into - many capped first-redemptions under fresh pseudonyms. Mitigation: rate limits - enforced at the LEZ escrow program; combine with off-chain reputation gating - (LP-0019) for higher tiers. - -## Risks (option 2a-specific) - -- **Off-chain reputation dependency (LP-0019).** Without an off-chain - attribution mechanism, the bond is not actually slashable on default. If - lambda prize - [LP-0019](../lambda-prizes/LP-0019-atomic-swap-maker-reputation.md) is not yet - awarded when option 2a ships, the protocol launches with a weaker enforcement - story than its marketing implies. Mitigation: sequence LP-0019 first, or - include a stub-attestor mechanism in RFP-025 itself (with the limitations of - stub-attestor centralisation documented honestly). -- **Reputation gaming attacks on the LP side.** An LP can build reputation - cheaply by completing many small redemptions then default on a large one. - Mitigation: notional-weighted reputation; cap per-LP redemption size - proportional to accumulated reputation and bond. -- **Bond denomination volatility.** If the bond asset (stables on LEZ) depegs, - LPs become under-collateralised against their XMR commitments. Mitigation: cap - protocol-wide LP collateral concentration by asset; require LPs to top up on - bond-asset depeg events. +§Federated-signer middle chain). The custody trust model is the same trust class +as RFP-021. + +This design is **not the Logos team's preferred sXMR design** (RFP-024 is). The +custody risk and Monero deposit-history leak (both documented below) are real +and material. RFP-025 exists in the bundle as the deployed-prior-art comparison +point and as the design choice if real-XMR backing turns out to be a hard +product requirement. + +## High-level functionality and flow + +```mermaid +flowchart LR + User[User] -- deposit XMR on Monero --> MS[Threshold-signer multisig on Monero] + MS -- mint signal --> LEZ[sXMR LEZ program] + LEZ -- mint sXMR --> User + User -- burn sXMR + redemption request --> LEZ + LEZ -- spend signal --> MS + MS -- sign Monero spend --> Out[XMR back to user on Monero] +``` -## Risks (option 2b-specific) +- **Mint.** A user sends XMR to the protocol's Monero-side multisig with a memo + identifying the user's LEZ destination address. The signer set observes the + deposit, reaches consensus, and the LEZ sXMR program mints 1:1 sXMR to the + destination. +- **Burn / redeem.** A user burns sXMR on LEZ with a Monero destination address. + The signer set observes the burn, reaches threshold, and signs a Monero spend + from the multisig to the user's address. +- **Custody.** The protocol holds real XMR in a threshold-signer multisig + (FROST-over-CLSAG; per-coin threshold suitable for Monero). The signer set is + bonded and slashable; signer bond size scales with custody value. +- **Governance.** Signer set composition, threshold, bond requirements, and + slashing rules are protocol-governed. + +The atomic-swap protocol is *not* used in this RFP. Mint and redemption are +direct interactions with the multisig. + +## Pros + +- **Real XMR redemption with a documented SLA shape.** Unlike RFP-024 (no XMR + redemption) and unlike RFP-026 (best-effort matching, no guarantees), this + design lets a user mint and redeem on demand, bounded by the signer-set + responsiveness. +- **Hard peg within reserve capacity.** sXMR is 1:1 backed by real XMR; oracle + is not load-bearing (no oracle needed for the peg itself, only for any + auxiliary pricing). +- **Composable from day one.** sXMR is a vanilla LEZ token; lending, DEXes, + governance, structured products can integrate. +- **Audience overlap with sBTC and Secret Monero Bridge.** Users who already + accept federated-custody designs on Stacks/Secret will find the trust model + familiar. + +## Cons + +- **Custody risk is real and historically realised.** A signer set holding real + XMR is a target. Thorchain's 2026-05-15 GG20/TSSHOCK exploit drained $10.8M + from a similar architecture. Wormhole's 2022 Solana-side bug drained $326M. + sBTC's signer set is 15 entities and has not been exploited at time of + writing, but the failure-mode category is well-documented. +- **View-key-shared custody leaks Monero deposit history to signers.** Threshold + custody of XMR requires view-key sharing among signers. Honest-but-curious + signers learn the protocol-side mint and burn flow. This is the same + compromise RFP-021 accepts; it is the structural cost of TSS custody of XMR + under current Monero cryptography. +- **Signer-set bootstrap problem.** Bonded-security guarantees do not bind until + the signer-set stake catches up with custody value. Early in the protocol's + life the bond-to-custody ratio is unfavourable; the protocol is at its weakest + precisely when its custody is smallest. +- **Signer-set censorship and coercion vector.** Identifiable signers are a + chokepoint for legal, regulatory, and out-of-protocol pressure. The federation + cannot be made "fully decentralised" the way an atomic-swap design (RFP-026) + can be. +- **Redemption SLA depends on signer liveness.** If the signer set cannot reach + threshold to sign (network partition, mass offline event), redemption breaks + even with no malice. +- **Reinvents sBTC for a privacy-coin underlying.** The novelty relative to sBTC + is the LEZ privacy execution on the sXMR token side, not the custody model. + The custody side carries familiar risks; the LEZ side cannot compensate for + them. +- **Privacy-claim overreach.** sXMR on LEZ is private only insofar as LEZ-native + shielding makes it so. The protocol-side Monero deposit/redemption flow is + visible to signers and leaks the underlying-asset graph; users may misread + "sXMR is private" as "the protocol does not see my XMR activity". +- **Why this RFP is not preferred.** The custody and view-key disclosure issues + above mean RFP-025 reintroduces exactly the trust assumptions that RFP-024 + deliberately avoids. The Logos team's working assumption is that LEZ users + prefer the synthetic-with-no-custody trade-off (RFP-024) over the + wrapped-with-custody trade-off (this RFP). + +## Risks - **Signer-set compromise.** A captured signer set can drain the entire reserve. Mitigation: large signer set (Serai uses up to 600; Thorchain ~100); - permissionless entry; high bond-to-custodied ratio; emergency halt mechanism; - geographic diversity. -- **Signer-set offline event.** If the signer set cannot reach threshold to sign + permissionless entry once bootstrapped; high bond-to-custodied ratio; + emergency-halt mechanism; geographic and jurisdictional diversity. +- **TSS implementation bug.** Thorchain's GG20 TSS exploit on 2026-05-15 + ($10.8M) is the canonical example. Mitigation: choose FROST over GG20 for the + Monero side; budget for Cypher-Stack-equivalent audit; isolate signer-software + dependencies; track Serai's monero-oxide work as the production-grade + FROSTLASS instantiation. +- **Signer-set offline event.** If the signer set cannot reach threshold (network partition, mass node failure), redemption SLA breaks even with no malice. Mitigation: redundant signer geographic placement; documented signer - SLOs; emergency-halt mechanism that pauses redemption gracefully rather than - failing under load. -- **TSS implementation bug.** Thorchain's GG20 TSS exploit on 2026-05-15 - ($10.8M) is the canonical example. Mitigation: choose FROST over GG20; budget - for Cypher Stack-equivalent audit; isolate signer-software dependencies. + SLOs; emergency-halt mechanism that pauses redemption gracefully. +- **Bond denomination volatility.** If signer bonds are denominated in + LEZ-native assets that depeg or are volatile, bond-to-custodied ratio drifts. + Mitigation: cap bond-asset concentration; require signers to top up on + bond-asset depeg. +- **Regulatory exposure on XMR custody.** A protocol that custodies real XMR + draws more scrutiny than RFP-024's CDP design or RFP-026's + peer-to-peer-atomic-swap design. Mitigation: signer-set jurisdictional + diversity; documented compliance posture; willingness to operate as a + permissionless smart contract regardless of any single jurisdiction's stance. +- **Reserve undercollateralisation.** If the reserve is drawn down faster than + it can be replenished from fees or governance top-ups, redemption capacity + goes to zero; sXMR loses its peg. ## Relationship to other RFPs in this bundle -- **RFP-024 (sXMR pure non-custodial)** is the complementary design. RFP-025 - trades non-custody for SLA. A reader should pick one or both based on the - target audience: pure-cypherpunk users for RFP-024; SLA-needing users for - RFP-025. -- **RFP-003 (Atomic Swaps with LEZ, open)** is the foundation: the LEZ-XMR - atomic-swap SDK is the redemption settlement layer for both options. -- **Lambda prize - [LP-0019 (off-chain maker reputation)](../lambda-prizes/LP-0019-atomic-swap-maker-reputation.md)** - is a hard dependency for option 2a's slashing mechanism. The off-chain - attribution it produces is what makes "LP defaulted" attributable; without it, - the bond gates participation but cannot be slashed on a single failed swap - with cryptographic certainty. -- **Lambda prize - [LP-0018 (atomic-swap anti-spam mechanism)](../lambda-prizes/LP-0018-atomic-swap-anti-spam.md)** - could optionally be layered on the redemption-leg atomic swap to deter - taker-side griefing. Not strictly required for either option; the LP-side bond - / reserve already addresses maker-side performance. -- **RFP-021 (cross-chain privacy DEX)** is orthogonal: it offers real-asset - cross-chain swaps with federated custody; this RFP offers synthetic-XMR - exposure with managed redemption. Option 2b shares the view-key-shared TSS - custody trade-off with RFP-021's XMR support; the two RFPs could share - signer-set infrastructure if both are funded. -- **RFP-004 (Privacy-Preserving DEX, open)** is the natural single-chain trading - venue for sXMR. +- **RFP-024 (sXMR CDP-backed)** is the preferred alternative. RFP-024 says "we + don't custody XMR, sXMR is a debt instrument against stable collateral"; this + RFP says "we do custody XMR via a federated multisig". The two are mutually + exclusive product directions, not layered. +- **RFP-026 (sXMR atomic-swap redemption to real XMR)** is the non-custodial + alternative for delivering real XMR to users. RFP-026 builds on RFP-024 and + uses atomic swaps; RFP-025 holds real XMR in a multisig. RFP-026 has + best-effort SLA; RFP-025 has hard-peg-within-reserve. +- **RFP-021 (cross-chain privacy DEX)** shares the federated-signer trust model. + The two RFPs could share signer-set infrastructure if both are funded (same + FROST-over-CLSAG primitives, possibly same validator set), trading some + signer-set economies of scale. +- **RFP-003 (Atomic Swaps with LEZ, open)** is not used by this RFP. Mint and + redemption are direct multisig interactions, not atomic swaps. +- **LP-0018 and LP-0019** do not apply to this RFP. They address + atomic-swap-specific concerns; this RFP has no atomic-swap leg. See [appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) -for the deployed-synthetics survey (Haven, Synthetix, sBTC, Secret Monero -Bridge) including the redeem-to-underlying-with-custody design family (option -2b's pattern). See +§Redeem-to-underlying with custody for the deployed prior art (sBTC, Secret +Monero Bridge) and [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) -for the federated-signer custody analysis that applies to option 2b. +for the federated-signer trust analysis. ## References - [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) - [appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) - [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) -- [appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) - [docs.stacks.co/concepts/sbtc](https://docs.stacks.co/concepts/sbtc) (accessed 2026-05-22) — sBTC is a 1:1 BTC-backed asset on Stacks; custody is a 15-signer - federation with a 70% threshold (current operating set 14 signers, 10-of-14 to - sign peg-out); withdrawal latency ~6 Bitcoin blocks. + federation with 70% threshold (current operating set 14 signers, 10-of-14 to + sign); withdrawal latency ~6 Bitcoin blocks. - [Hiro: Who are the sBTC signers, breaking down SIP-028](https://www.hiro.so/blog/who-are-the-sbtc-signers-breaking-down-sip-028) (accessed 2026-05-22) - [Crypto Times: $10.8M drained from Thorchain on 2026-05-15](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/) @@ -393,3 +196,5 @@ for the federated-signer custody analysis that applies to option 2b. (accessed 2026-05-19) - [FROST: Flexible Round-Optimized Schnorr Threshold Signatures (Komlo and Goldberg, SAC 2020 / IACR 2020/852)](https://eprint.iacr.org/2020/852) (accessed 2026-05-21) +- [Announcing monero-oxide / FROSTLASS over CLSAG (Serai, 2025-09-09)](https://serai.exchange/2025/09/09/monero-serai-oxide.html) + (accessed 2026-05-19) — production-grade reference for Monero TSS custody. diff --git a/RFPs/RFP-026-sxmr-atomic-swap-redemption.md b/RFPs/RFP-026-sxmr-atomic-swap-redemption.md new file mode 100644 index 0000000..20ef473 --- /dev/null +++ b/RFPs/RFP-026-sxmr-atomic-swap-redemption.md @@ -0,0 +1,196 @@ +--- +id: RFP-026 +title: sXMR Atomic-Swap Redemption (extends RFP-024) +tier: L +funding: $TBD +status: draft +category: Applications & Integrations +--- + +# RFP-026 — sXMR Atomic-Swap Redemption to Real XMR + +> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos +> team and the community compare cross-chain DEX designs across RFP-021, +> RFP-024, RFP-025, and RFP-026. Hard requirements, FURPS detail, team profile, +> timeline, and contracting details are deliberately omitted; they will be +> filled in if the design is selected for funding. +> +> **This RFP strictly extends RFP-024.** RFP-024 (CDP-backed sXMR) is a hard +> prerequisite. RFP-026 adds an atomic-swap-based redemption path so that sXMR +> holders can exit to real XMR on Monero L1, without the protocol ever holding +> XMR. It does not re-specify the CDP mint mechanic. + +## 🧭 Overview + +Add a peer-to-peer atomic-swap redemption module on top of RFP-024's CDP-backed +sXMR. Holders of sXMR who want to receive real XMR on Monero L1 can post a +redemption intent over Logos Delivery; any XMR holder (an "LP") can quote and +counterparty the redemption via an atomic swap using the RFP-003 LEZ-XMR SDK. On +success, the user's sXMR is burned on LEZ, the LP receives the unlocked stable +collateral, and the user receives real XMR on Monero L1. + +The protocol holds no XMR at any step. There is no LP registry, no bond, no SLA. +Anyone with XMR can quote. Spreads widen under stress without bound; redemption +availability is whatever the LP market clears. This is the *non-custodial +real-XMR exit path* for RFP-024's CDP synthetic. Builders who want a guaranteed +redemption SLA backed by federated custody should look at RFP-025 instead. + +Inspired by **eigenwallet/COMIT BTC-XMR atomic swap** for the redemption-leg +cryptography. See +[appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) for the +underlying protocol mechanics and the locking-order protocol constraint +(LEZ-side locks first by protocol for XMR↔LEZ). + +## High-level functionality and flow + +```mermaid +flowchart LR + User[sXMR holder] -- redemption intent --> LD[Logos Delivery] + LP[Open XMR LP] -- quote --> LD + User -- accept quote --> LP + User -- lock sXMR vault on LEZ + atomic-swap setup --> LEZ[LEZ atomic-swap escrow] + LP -- lock XMR on Monero --> Mon[Monero] + User -- reveal secret --> LEZ + LP -- claim sXMR collateral, burn sXMR --> LEZ + Mon -- XMR to user's address --> UserExit[User on Monero L1] +``` + +Step-by-step: + +1. The sXMR holder publishes a redemption intent (notional, oracle price, + deadline) over Logos Delivery. +2. Any open-set XMR LP sees the intent, computes their quote (oracle ± spread), + and replies bilaterally over Logos Delivery / Logos Chat. +3. The holder accepts a quote and the two parties run the RFP-003 LEZ-XMR + atomic-swap protocol. The LEZ side (the sXMR + collateral release) locks + first; the LP locks XMR on Monero second. See + [primer §Locking order](../appendix/atomic-swaps-primer.md#locking-order) for + why this ordering is forced by protocol. +4. The holder reveals the secret on LEZ; the LP uses it to claim the sXMR-backed + stable collateral as their payout (less any protocol fee). The LP also has a + claim path on the Monero side to deliver real XMR to the holder. +5. On success, sXMR is burned on LEZ (collateral leaves the RFP-024 vault to the + LP); the holder receives real XMR on Monero L1. + +Failure modes: + +- **No LP shows up.** The holder's redemption intent expires; their sXMR + position is unchanged. They can retry, lower the price, or sell sXMR on a DEX + instead. +- **LP walks mid-swap.** The atomic-swap refund path unwinds; the holder retains + sXMR; the LP loses time and transaction fees. See + [primer §Timelocks and refunds](../appendix/atomic-swaps-primer.md#timelocks-and-refunds). +- **Holder walks mid-swap.** Symmetric; both parties refund. +- **The free-option problem applies.** Either party can walk and the other waits + out the refund window. This is intrinsic to atomic swaps; RFP-026 accepts it + as the cost of non-custody. LP-0018 (spam protection for makers) and LP-0019 + (taker reliability) may be layered on later but are not preconditions. + +## Pros + +- **Real XMR delivery without custody.** Successful redemption ends with real + XMR on Monero L1, with no protocol-side multisig holding the underlying. + RFP-025 carries custody risk; RFP-026 does not. +- **Composes cleanly with RFP-024.** The CDP mint mechanic from RFP-024 is + unchanged. RFP-026 adds a peer-to-peer exit path that LEZ DeFi users can use + alongside the standard burn-to-stables option. +- **Open LP set is censorship-resistant.** No permissioned set; no KYC; no + operator that can be coerced into refusing service. +- **Regulatory minimalism preserved from RFP-024.** The protocol does not handle + XMR; the atomic swap is a bilateral interaction between user and LP. The + protocol provides the LEZ-side escrow program, the matching board over Logos + Delivery, and the cryptographic primitives — nothing more. +- **Lowest-risk path to a real-XMR exit.** Other paths (RFP-021 federated DEX, + RFP-025 multisig wrap) require custody. RFP-026 keeps non-custody intact. + +## Cons + +- **Soft SLA only.** Redemption availability is whatever the LP market clears. + There is no protocol-side commitment to a delivery window. A user who wants a + hard SLA on real XMR must use RFP-025 (and accept its custody trade-off). +- **LP-side bottleneck likely.** Mint demand may be easy; LP supply (XMR holders + willing to atomic-swap their XMR for stables) is harder to source. + Privacy-maximalist XMR holders may not want a public LP role. +- **Atomic-swap UX inherited.** Settlement time is dominated by Monero block + confirmations (typically under an hour but with variance); both parties online + for the lock+reveal duration. Intent gossip over Logos Delivery softens but + cannot eliminate this. +- **Free-option problem applies.** Either party can walk mid-swap, costing the + other party time. This is intrinsic to atomic swaps. LP-0018 and LP-0019 + address it but are not preconditions; this RFP ships without those + mitigations. +- **Adverse-selection of LPs.** LPs likely show up when oracle is below true XMR + price (free money on the redemption leg) and vanish when oracle is above. + Redemption availability is expected to be asymmetric across price regimes. +- **No fee revenue capture for the protocol on the LP side.** Open LP set means + LPs capture the spread; the protocol's only revenue is mint/burn fees from + RFP-024 plus any explicit redemption-protocol fee. + +## Risks + +- **LP exodus.** All XMR holders stop quoting. Redemption becomes unavailable; + users fall back to RFP-024's sell-sXMR-on-DEX exit. The protocol cannot + intervene. Mitigation: design to survive long no-LP windows; let the market + discount on sXMR signal demand to bring LPs back. +- **Spam attacks on makers.** A malicious user can post redemption intents that + an LP locks against, then walks. LP loses time and fees per cycle. Mitigation: + LP-0018 if/when it ships; until then, LPs must filter intents at their own + discretion (e.g. requiring sXMR proof-of-balance or rate-limiting per + identity). +- **Maker-side reliability.** An unreliable LP can grief takers by + quote-and-walk. Mitigation: LP-0019 if/when it ships; until then, takers must + filter LPs by reputation gathered out-of-band. +- **Locking-order constraint.** The LEZ side must lock first for XMR↔LEZ (Monero + today provides no on-chain primitive supporting the locks-first role; see + [primer §Locking order](../appendix/atomic-swaps-primer.md#locking-order)). + For LEZ→XMR (this RFP's direction), this is the *taker* (sXMR holder) locking + first, which is the desired draining-attack posture (taker bears the + lock-window cost). Sub-case A in LP-0018's framing. +- **Atomic-swap protocol immaturity.** The deployed BTC-XMR atomic-swap + ecosystem (eigenwallet, Farcaster) is community-scale not volume-scale. + LEZ-XMR is a new pair; the LEZ-XMR module from RFP-003 must be built and + audited before this RFP can ship. Mitigation: RFP-003 is a prerequisite; + RFP-026 depends on its LEZ-XMR SDK. + +## Relationship to other RFPs in this bundle + +- **RFP-024 (sXMR CDP-backed)** is a **hard prerequisite**. RFP-026 does not + implement the CDP mint mechanic; it only adds the atomic-swap redemption path. + A builder funded for RFP-026 must build against a deployed (or jointly-built) + RFP-024. +- **RFP-003 (Atomic Swaps with LEZ, open)** is a **hard prerequisite**. The + LEZ-XMR atomic-swap SDK is the redemption settlement layer. RFP-026 does not + modify RFP-003; it consumes it. +- **RFP-025 (sXMR real-XMR multisig)** is the not-preferred alternative for + real-XMR delivery. RFP-025 promises a hard SLA at the cost of custody; RFP-026 + offers a soft SLA without custody. The two are mutually exclusive product + directions for the "deliver real XMR to sXMR holders" goal. +- **RFP-021 (cross-chain privacy DEX)** is orthogonal — federated-custody + real-XMR cross-chain swaps, not synthetic exposure with optional redemption. +- **LP-0018 (Spam protection for atomic-swap makers)** can be layered on the + redemption-leg atomic swap once the prize is awarded. Not a precondition; + RFP-026 ships with the free-option problem accepted as a known cost. +- **LP-0019 (Taker reliability for atomic swaps)** can be layered for + LP-discovery UX and maker-misbehaviour attribution. Not a precondition. +- **RFP-004 (Privacy-Preserving DEX, open)** is the natural single-chain trading + venue for sXMR pre-redemption (the alternative exit path that does not involve + atomic swaps at all). + +See [appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) for +atomic-swap mechanics and the locking-order protocol constraint, and +[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) +for the federated-signer-vs-atomic-swap trust contrast. + +## References + +- [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) +- [RFP-024: sXMR CDP-Backed Synthetic](./RFP-024-synthetic-xmr-pure.md) +- [appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) +- [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) +- [appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) +- [LP-0018: Spam Protection for Atomic-Swap Makers](../lambda-prizes/LP-0018-atomic-swap-anti-spam.md) +- [LP-0019: Taker Reliability for Atomic Swaps](../lambda-prizes/LP-0019-atomic-swap-maker-reputation.md) +- [Bitcoin to Monero atomic swaps (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) + (accessed 2026-05-21) +- [eigenwallet/core (active fork of comit-network/xmr-btc-swap; v4.6.4, 2026-05-21)](https://github.com/eigenwallet/core) + (accessed 2026-05-22) diff --git a/lambda-prizes/LP-0018-atomic-swap-anti-spam.md b/lambda-prizes/LP-0018-atomic-swap-anti-spam.md index d53cc40..9bf0551 100644 --- a/lambda-prizes/LP-0018-atomic-swap-anti-spam.md +++ b/lambda-prizes/LP-0018-atomic-swap-anti-spam.md @@ -80,7 +80,7 @@ single-sub-case mechanism is sufficient to win. The atomic-swap branch of the cross-chain DEX design tree has a known structural weakness on the free-option / spam-the-maker problem. The Logos cross-chain DEX -bundle (RFPs 021, 024, 025) keeps the vanilla RFP-003 atomic swap as the +bundle (RFPs 021, 024, 025, 026) uses the vanilla RFP-003 atomic swap as the privacy-non-custodial primitive, but vanilla atomic swaps remain economically unattractive for makers at scale because of the spam exposure. Without a credible spam-protection mechanism, the maker side of the LEZ atomic-swap market From b4845f678c4137ba3259f6279a4d4027eda22bdd Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 22 May 2026 22:55:44 +1000 Subject: [PATCH 15/17] rfp: clarify RFP-021 is not preferred standalone, but complementary to atomic swaps Add explicit "not preferred standalone, complementary to atomic swaps" framing to RFP-021's top-of-file note and Overview. The federated-signer custody model trades non-custody for AMM liquidity and one-step UX; the Logos team's working preference is the non-custodial atomic-swap path (RFP-003 + RFP-024 + RFP-026). RFP-021 stays in the bundle as a complementary design for users who prefer the better UX over cryptographic non-custody. Co-Authored-By: Claude Opus 4.7 (1M context) --- RFPs/RFP-021-cross-chain-privacy-dex.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/RFPs/RFP-021-cross-chain-privacy-dex.md b/RFPs/RFP-021-cross-chain-privacy-dex.md index b55505a..bd3b3bb 100644 --- a/RFPs/RFP-021-cross-chain-privacy-dex.md +++ b/RFPs/RFP-021-cross-chain-privacy-dex.md @@ -14,6 +14,13 @@ category: Applications & Integrations > RFP-024, RFP-025, and RFP-026. Hard requirements, FURPS detail, team profile, > timeline, and contracting details are deliberately omitted; they will be > filled in if the design is selected for funding. +> +> **RFP-021 is not the preferred standalone design** (the team's preference is +> the non-custodial atomic-swap path: RFP-024 + RFP-026 on RFP-003). However, it +> is **complementary to atomic swaps**: the federated middle chain handles +> high-liquidity bulk trading at AMM UX where users accept federated custody as +> the trade-off, while atomic swaps handle the privacy-maximalist niche where +> cryptographic non-custody beats UX convenience. The two can coexist. ## 🧭 Overview @@ -37,6 +44,18 @@ This is the most ambitious option in the cross-chain bundle. It is also the one with the strongest empirical case (volume, user experience, asset coverage) and the strongest custody risk. +**RFP-021 is not the preferred design on its own.** The federated-signer custody +model trades non-custody for AMM liquidity and one-step UX; the Logos team's +working preference is the non-custodial atomic-swap path (RFP-003 plus the sXMR +designs in RFP-024 and RFP-026) where users do not have to trust a validator +set. However, RFP-021 can be **complementary to atomic swaps**: the AMM-style +middle chain handles high-liquidity bulk trading where users are willing to +accept federated custody for better UX, while atomic swaps handle the +privacy-maximalist niche where users prefer cryptographic non-custody to UX +convenience. The two designs serve different audiences and can coexist in the +same LEZ ecosystem, with the user choosing the trust trade-off they want for +each swap. + ## High-level functionality and flow ```mermaid From 0b142486ea29ad14182618f16ec5c2e9c0273c64 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Fri, 22 May 2026 22:57:39 +1000 Subject: [PATCH 16/17] rfp: replace local vault paths with public GitHub repo links The research vault `~/src/marclawclaw/research-cross-chain-dex/` lives publicly at https://github.com/marclawclaw/research-cross-chain-dex. Replaced two local-folder references with the matching GitHub URLs so external readers can follow the citations. Co-Authored-By: Claude Opus 4.7 (1M context) --- appendix/atomic-swaps-primer.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/appendix/atomic-swaps-primer.md b/appendix/atomic-swaps-primer.md index b76f98f..c08f0e6 100644 --- a/appendix/atomic-swaps-primer.md +++ b/appendix/atomic-swaps-primer.md @@ -145,7 +145,7 @@ scheme, which is a work-in-progress"*. Five years later, no peer-reviewed Monero-endorsed CLSAG-adaptor construction has been published, and the Monero project is not pursuing one. Treat XMR-first BTC↔XMR atomic swaps as structurally unavailable for the foreseeable horizon. Source: -[`projects/xmr-first-required-monero-features.md`](https://github.com/marclawclaw/research-cross-chain-dex) +[`projects/xmr-first-required-monero-features.md`](https://github.com/marclawclaw/research-cross-chain-dex/blob/main/projects/xmr-first-required-monero-features.md) documents the underlying primary sources; this primer summarises. The economic draining-attack analysis (Hoenisch and del Pino 2021 §4) From b2f1ef32042194b021d2915efa25d54e92995489 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Thu, 4 Jun 2026 16:18:50 +1000 Subject: [PATCH 17/17] rfp: generalise RFP-024/026 from sXMR to any synthetic asset RFP-024 becomes a CDP-backed synthetic facility for any oracle-priced asset (the mint/burn/liquidate engine is asset-agnostic; oracle is the only per-asset input). RFP-026 becomes atomic-swap redemption for any asset with both a CDP synthetic and atomic-swap support (the intersection gates the redeemable set). XMR/ZEC/BTC/ETH used as lead examples; XMR remains the motivating case. Rename: - RFP-024-synthetic-xmr-pure.md -> RFP-024-cdp-backed-synthetic.md - RFP-026-sxmr-atomic-swap-redemption.md -> RFP-026-synthetic-atomic-swap-redemption.md Update RFP-021 and RFP-025 prose descriptions of 024/026 to the generic framing. RFP-025 stays XMR-specific (custodies real XMR). Co-Authored-By: Claude Opus 4.8 (1M context) --- RFPs/RFP-021-cross-chain-privacy-dex.md | 16 +- RFPs/RFP-024-cdp-backed-synthetic.md | 232 +++++++++++++++++ RFPs/RFP-024-synthetic-xmr-pure.md | 175 ------------- RFPs/RFP-025-synthetic-xmr-sla.md | 21 +- RFPs/RFP-026-sxmr-atomic-swap-redemption.md | 196 -------------- ...FP-026-synthetic-atomic-swap-redemption.md | 246 ++++++++++++++++++ 6 files changed, 497 insertions(+), 389 deletions(-) create mode 100644 RFPs/RFP-024-cdp-backed-synthetic.md delete mode 100644 RFPs/RFP-024-synthetic-xmr-pure.md delete mode 100644 RFPs/RFP-026-sxmr-atomic-swap-redemption.md create mode 100644 RFPs/RFP-026-synthetic-atomic-swap-redemption.md diff --git a/RFPs/RFP-021-cross-chain-privacy-dex.md b/RFPs/RFP-021-cross-chain-privacy-dex.md index bd3b3bb..5126196 100644 --- a/RFPs/RFP-021-cross-chain-privacy-dex.md +++ b/RFPs/RFP-021-cross-chain-privacy-dex.md @@ -46,8 +46,8 @@ the strongest custody risk. **RFP-021 is not the preferred design on its own.** The federated-signer custody model trades non-custody for AMM liquidity and one-step UX; the Logos team's -working preference is the non-custodial atomic-swap path (RFP-003 plus the sXMR -designs in RFP-024 and RFP-026) where users do not have to trust a validator +working preference is the non-custodial atomic-swap path (RFP-003 plus the +CDP-backed synthetic designs in RFP-024 and RFP-026) where users do not have to trust a validator set. However, RFP-021 can be **complementary to atomic swaps**: the AMM-style middle chain handles high-liquidity bulk trading where users are willing to accept federated custody for better UX, while atomic swaps handle the @@ -196,12 +196,12 @@ solvency or signing failure. LEZ. RFP-021 is *cross-chain* with vault custody. Distinct scopes; the two could ship in parallel and serve different user journeys (intra-LEZ shielded trading vs cross-chain settlement). -- **RFP-024 (sXMR CDP-backed)**, **RFP-025 (sXMR real-XMR multisig)**, and - **RFP-026 (sXMR atomic-swap redemption)** target a different product: - synthetic XMR exposure inside LEZ DeFi. They are orthogonal to RFP-021 and - could ship alongside it, sharing the same LEZ privacy primitives. RFP-025 - shares the federated-signer custody pattern with RFP-021 and could share - signer-set infrastructure. +- **RFP-024 (CDP-backed synthetics)**, **RFP-025 (real-XMR multisig)**, and + **RFP-026 (synthetic atomic-swap redemption)** target a different product: + synthetic-asset exposure inside LEZ DeFi (with XMR as the motivating case). + They are orthogonal to RFP-021 and could ship alongside it, sharing the same + LEZ privacy primitives. RFP-025 shares the federated-signer custody pattern + with RFP-021 and could share signer-set infrastructure. See [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) diff --git a/RFPs/RFP-024-cdp-backed-synthetic.md b/RFPs/RFP-024-cdp-backed-synthetic.md new file mode 100644 index 0000000..5791c67 --- /dev/null +++ b/RFPs/RFP-024-cdp-backed-synthetic.md @@ -0,0 +1,232 @@ +--- +id: RFP-024 +title: CDP-Backed Synthetic Assets (sASSET) for Any Oracle-Priced Asset +tier: XL +funding: $TBD +status: draft +category: Applications & Integrations +--- + +# RFP-024 — CDP-Backed Synthetic Assets (sASSET) + +> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos +> team and the community compare cross-chain DEX designs across RFP-021, +> RFP-024, RFP-025, and RFP-026. Hard requirements, FURPS detail, team profile, +> timeline, and contracting details are deliberately omitted; they will be +> filled in if the design is selected for funding. + +## 🧭 Overview + +Build a CDP-backed synthetic-asset facility on LEZ that can mint a synthetic +token (sASSET) tracking the price of *any oracle-priced asset* — `sXMR`, `sZEC`, +`sBTC`, `sETH`, and so on. Users mint sASSET by locking stable collateral (or +other governance-approved LEZ assets) into a CDP-style vault, similar to the +Synthetix V3 Pools mechanic (SIP-302). Users burn sASSET to recover their +collateral. The protocol holds none of the tracked asset at any point and does +not deposit it on the asset's home chain — sASSET is a *debt instrument against +stable collateral*, not a wrapped asset. + +The mint/burn/liquidate machinery is identical regardless of which asset is +tracked; the only per-asset input is the oracle price feed. Adding a new +synthetic (e.g. going from `sXMR` to `sZEC`) is a matter of wiring up a +documented oracle for the new asset and setting that synthetic's risk +parameters, not re-engineering the vault. This is exactly the property Synthetix +exploited to list `sUSD`, `sETH`, `sBTC`, `sXMR`, `sBCH`, `sADA`, and others off +a single CDP-minting engine. + +Inspired by **Synthetix CDP minting** (SIP-302 Pools V3). A directly relevant +deployed analogue is Synthetix's own historical sXMR ERC-20 (Hadar release, +2020-03-30), which was SNX-collateralised and oracle-priced via Chainlink, never +redeemable for real XMR — one of a whole family of oracle-priced synths off the +same engine. See +[appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) +§Oracle-priced over-collateralised synthetics. + +This is the preferred synthetic design in the bundle. For privacy-coin +underlyings such as XMR, RFP-025 (real-asset multisig) carries custody risk and +a deposit-history leak; RFP-026 layers atomic-swap redemption on top of this RFP +for users who want to exit to the real asset on its home chain (but does not +change the CDP mint mechanic). + +## Which assets fit this design + +Any asset for which a usable price oracle exists can be minted as a CDP-backed +synthetic here. The asset's own chain capabilities are irrelevant to *minting* — +the vault only ever holds LEZ-side collateral. Lead examples: + +- **`sXMR` (Monero).** The bundle's primary motivating case: privacy-coin + exposure inside LEZ DeFi with no XMR custody. Monero has no smart contracts and + no SPV proof, but none of that matters to a CDP synthetic because the protocol + never touches XMR. +- **`sZEC` (Zcash).** Same privacy-coin story as XMR; oracle-priced shielded-asset + exposure without custodying ZEC. +- **`sBTC` (Bitcoin).** Synthetic BTC exposure inside LEZ without a federation + custodying BTC (contrast Stacks sBTC, which is custody-backed — see the + appendix). +- **`sETH` (Ethereum).** Synthetic ETH exposure; a liquid, well-oracled asset + that is a natural low-risk first listing to validate the engine before adding + thinner-oracle assets. + +What *does* vary per asset is risk configuration, not mechanism: oracle quality +and redundancy, price volatility (which drives the c-ratio and liquidation +parameters), and whether a robust enough price feed exists at all. Thinly-traded +or poorly-oracled assets are out of scope until a defensible oracle exists for +them. Applicants should treat "is there a manipulation-resistant oracle for this +asset?" as the gating question for each listing. + +## High-level functionality and flow + +```mermaid +flowchart LR + User[User] -- deposit stable collateral --> Vault[sASSET CDP vault on LEZ] + Vault -- mint sASSET at oracle price --> User + Oracle[ASSET/USD oracle] -- price feed --> Vault + User -- burn sASSET + interest --> Vault + Vault -- release collateral --> User + Liq[Liquidation keeper] -- liquidate undercollateralised vault --> Vault +``` + +- **Mint.** A user deposits stable collateral (or other governance-approved LEZ + assets) into the sASSET vault on LEZ. The protocol mints sASSET at the current + oracle price for the tracked asset, up to a configurable issuance ratio + (minimum c-ratio). The user holds sASSET; the vault holds the collateral. +- **Burn / unwind.** The user repays sASSET (plus any interest/fees) and the + vault releases the collateral. +- **Liquidation.** If the vault's c-ratio breaches the threshold (oracle price + moves against the user), a liquidation keeper closes the position and returns + surplus collateral to the user, less penalty. +- **Trading.** sASSET is a vanilla LEZ token; users trade it against stables on + RFP-004 or any other LEZ DEX. The price tracks oracle within whatever spread + the market clears. + +There is **no atomic swap and no custody of the tracked asset in this RFP**. A +user who wants the real asset on its home chain (real XMR on Monero L1, real BTC +on Bitcoin, etc.) either sells sASSET on a DEX (and takes the spread), or uses +RFP-026 (atomic-swap redemption built on top of this RFP) once that ships and +the relevant chain's atomic-swap support exists. + +## Pros + +- **Strongest non-custody story.** The protocol never touches the tracked asset; + the vault holds only LEZ-side stable collateral. No signer set, no multisig, no + bridge, no deposit-history leak — true for `sXMR`, `sBTC`, `sZEC`, and any + other listing alike. +- **One engine, many assets.** A single audited CDP facility supports an open set + of synthetics. New listings cost an oracle integration and a risk-parameter + review, not a new protocol. This is the principal reason to prefer the CDP + design over per-asset custody bridges. +- **Composable from day one.** sASSET is a vanilla LEZ token; lending markets, + DEXes, governance, structured products can integrate without coordinating with + the synthetics team. +- **Regulatory defensibility highest in the bundle.** The protocol is, in + defensible terms, a price feed plus a collateral vault. Operators of price + feeds have meaningfully different exposure from operators of asset-custodying + bridges. +- **Independent of atomic-swap UX issues.** Mint and burn are LEZ-native + operations; there is no atomic-swap latency, no maker discovery, no + counterparty interactivity required for the core product. +- **Lowest engineering cost in the bundle's synthetics line.** Existing CDP + designs (Synthetix, MakerDAO, Liquity) provide a well-mapped implementation + template; the work is adapting those patterns to LEZ. +- **Builders are not blocked on LP-0018 or LP-0019.** Atomic-swap-specific + concerns (taker spam, maker reliability) do not apply to the CDP mint path; + those issues affect RFP-026 only. + +## Cons + +- **No path to the real asset within this RFP.** A user who wants the underlying + on its home chain must either accept the secondary-market discount (sell + sASSET for stables, buy the asset off-platform) or wait for RFP-026 to ship for + that asset and use it. The "synthetic" is genuinely synthetic: no + underlying-asset redemption. +- **Soft peg only.** sASSET tracks oracle within whatever spread the secondary + market clears. Under stress (oracle staleness, collateral crunch, panicked + unwinds) the peg can widen meaningfully. +- **Debt pool socialisation considerations.** In a V2-style debt pool, all + synth holders share aggregate Synth debt; in V3-style per-pool debt, the same + accounting model applies within a pool. Applicants must pick a model and + document its failure modes. With multiple synthetics off one engine, the debt + pool spans all of them — a sharp move in one asset's oracle is felt by holders + of the shared pool. +- **Per-asset oracle quality varies.** The engine is asset-agnostic but its + safety is not: a liquid asset like ETH has deep, redundant oracles, while a + thinner privacy coin may have fewer independent feeds and worse manipulation + resistance. Each listing inherits the strength (or weakness) of its oracle. +- **Privacy is partial.** sASSET is *not* a private asset on LEZ on its own; the + token program is public state. Privacy must come from LEZ-native shielding + (RFP-004's shielded swap intents, deshield-swap-reshield patterns). The CDP + vault and the mint/burn flow are public. (For non-privacy underlyings like ETH + or BTC this is a non-issue; it matters for the `sXMR`/`sZEC` privacy-coin case.) +- **Open question: does Logos want a synthetic that does not redeem to the + underlying?** Synthetix-style synths have proven they can sustain liquidity for + major asset classes (sUSD, sETH) but Synthetix's privacy-coin listing (sXMR) + itself never achieved meaningful volume. An audience that specifically wants the + real asset may not be satisfied by a debt instrument that merely tracks it. + +## Risks + +- **Oracle manipulation.** A manipulated ASSET/USD oracle lets an attacker mint + sASSET cheaply or under-collateralise existing positions. Mitigation: redundant + oracle stack with median-of-N pricing; configurable price-deviation guards; + oracle-staleness checks. This risk scales inversely with the asset's oracle + depth, so per-listing oracle review is mandatory. +- **Collateral solvency.** If the collateral asset (stables) depegs or is + compromised, sASSET backing degrades. Mitigation: accept only collateral with + documented threat models; cap protocol-wide collateral concentration by asset; + require liquidation parameters that hold under collateral-asset volatility. +- **Liquidation infrastructure under-built.** A CDP design that does not have + working keeper bots and a profitable liquidation incentive will hit insolvency + on the first market shock. Mitigation: design liquidation incentives carefully; + budget engineering for keeper operations; document MEV considerations. +- **Demand asymmetry.** Mint demand may be easy (LEZ-DeFi users want exposure to + the tracked asset inside LEZ) but secondary-market liquidity for that synthetic + may not materialise. The CDP design absorbs this — there is no LP bottleneck — + but the token's tradability is bottlenecked by LEZ DEX adoption. +- **Privacy-claim overreach (privacy-coin listings).** sASSET is not a private + asset; for `sXMR`/`sZEC` the privacy property is only that *the underlying + asset is private*. Mint/burn on LEZ is public. Documentation must be honest. +- **Synthetix-sXMR precedent.** Synthetix listed sXMR in 2020 and it did not + achieve meaningful adoption, even though its sUSD/sETH synths did. Mitigation: + LEZ-native privacy positioning and tight LEZ-DeFi integration may differentiate + privacy-coin listings, but applicants should validate demand per asset before + building. + +## Relationship to other RFPs in this bundle + +- **RFP-003 (Atomic Swaps with LEZ, open)** is not a dependency of this RFP. + RFP-024 is a CDP design that does not interact with atomic swaps. RFP-026 + layers atomic-swap redemption on top of this RFP for assets that have + atomic-swap support. +- **RFP-021 (cross-chain privacy DEX)** is the federated-custody alternative for + real-asset exposure. Orthogonal product: RFP-024 gives synthetic exposure + inside LEZ DeFi without custody; RFP-021 gives the real asset via a federated + middle layer. +- **RFP-025 (real-asset locked in trusted multisig)** is the not-preferred + custody-backed alternative, scoped specifically to XMR. The two RFPs target the + same audience differently *for the XMR case*: RFP-024 says "we don't custody the + asset"; RFP-025 says "we do, via a federated multisig". RFP-024 is preferred. +- **RFP-026 (atomic-swap redemption to the real asset)** strictly extends this + RFP. RFP-024 ships first; RFP-026 adds an atomic-swap exit path for users who + want to redeem to the asset's home chain (for any asset where atomic-swap + support exists). RFP-026 does not re-spec the CDP mint mechanic. +- **RFP-004 (Privacy-Preserving DEX)** is the natural single-chain trading venue + for sASSET. Trade sASSET against stables on RFP-004's AMM pools under the + shield/deshield pattern. +- **LP-0018 and LP-0019** are atomic-swap-specific prizes; they affect RFP-026 + only. + +See +[appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) +for the deployed-synthetics taxonomy and the Synthetix CDP minting reference. + +## References + +- [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) +- [appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) +- [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) +- [Synthetix SIP-302 (Pools V3)](https://sips.synthetix.io/sips/sip-302) + (accessed 2026-05-22) — canonical CDP-minting reference, with direct relevance + to the sASSET design. +- [Synthetix blog: Hadar release (sXMR ERC-20 and sibling oracle-priced synths, 2020-03-30)](https://blog.synthetix.io/new-synths-update-for-the-upcoming-hadar-release/) + (accessed 2026-05-22) — historical example of many oracle-priced synths off one + CDP engine. diff --git a/RFPs/RFP-024-synthetic-xmr-pure.md b/RFPs/RFP-024-synthetic-xmr-pure.md deleted file mode 100644 index 97c2871..0000000 --- a/RFPs/RFP-024-synthetic-xmr-pure.md +++ /dev/null @@ -1,175 +0,0 @@ ---- -id: RFP-024 -title: Synthetic XMR (sXMR) — CDP-Backed Synthetic -tier: XL -funding: $TBD -status: draft -category: Applications & Integrations ---- - -# RFP-024 — Synthetic XMR (sXMR), CDP-Backed Synthetic - -> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos -> team and the community compare cross-chain DEX designs across RFP-021, -> RFP-024, RFP-025, and RFP-026. Hard requirements, FURPS detail, team profile, -> timeline, and contracting details are deliberately omitted; they will be -> filled in if the design is selected for funding. - -## 🧭 Overview - -Build a synthetic XMR token (sXMR) on LEZ that tracks the XMR price via oracle. -Users mint sXMR by locking stable collateral (or other governance-approved LEZ -assets) into a CDP-style vault, similar to the Synthetix V3 Pools mechanic -(SIP-302). Users burn sXMR to recover their collateral. The protocol holds no -XMR at any point and does not deposit XMR on Monero L1 — sXMR is a *debt -instrument against stable collateral*, not a wrapped asset. - -Inspired by **Synthetix CDP minting** (SIP-302 Pools V3). The closest deployed -analogue: Synthetix's own historical sXMR ERC-20 (Hadar release, 2020-03-30), -which was SNX-collateralised and oracle-priced via Chainlink, never redeemable -for real XMR. See -[appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) -§Oracle-priced over-collateralised synthetics. - -This is the preferred sXMR design in the bundle. RFP-025 (real-asset multisig) -carries custody risk and a Monero deposit-history leak; RFP-026 layers -atomic-swap redemption on top of this RFP for users who want to exit to real XMR -on Monero L1 (but does not change the CDP mint mechanic). - -## High-level functionality and flow - -```mermaid -flowchart LR - User[User] -- deposit stable collateral --> Vault[sXMR CDP vault on LEZ] - Vault -- mint sXMR at oracle price --> User - Oracle[XMR/USD oracle] -- price feed --> Vault - User -- burn sXMR + interest --> Vault - Vault -- release collateral --> User - Liq[Liquidation keeper] -- liquidate undercollateralised vault --> Vault -``` - -- **Mint.** A user deposits stable collateral (or other governance-approved LEZ - assets) into the sXMR vault on LEZ. The protocol mints sXMR at the current - oracle price, up to a configurable issuance ratio (minimum c-ratio). The user - holds sXMR; the vault holds the collateral. -- **Burn / unwind.** The user repays sXMR (plus any interest/fees) and the vault - releases the collateral. -- **Liquidation.** If the vault's c-ratio breaches the threshold (oracle price - moves against the user), a liquidation keeper closes the position and returns - surplus collateral to the user, less penalty. -- **Trading.** sXMR is a vanilla LEZ token; users trade it against stables on - RFP-004 or any other LEZ DEX. The price tracks oracle within whatever spread - the market clears. - -There is **no atomic swap and no XMR custody in this RFP**. A user who wants -real XMR on Monero L1 either sells sXMR on a DEX (and takes the spread), or uses -RFP-026 (atomic-swap redemption built on top of this RFP) once that ships. - -## Pros - -- **Strongest non-custody story.** The protocol never touches XMR; the vault - holds only LEZ-side stable collateral. No signer set, no multisig, no bridge, - no Monero deposit-history leak. -- **Composable from day one.** sXMR is a vanilla LEZ token; lending markets, - DEXes, governance, structured products can integrate without coordinating with - the sXMR team. -- **Regulatory defensibility highest in the bundle.** The protocol is, in - defensible terms, a price feed plus a collateral vault. Operators of price - feeds have meaningfully different exposure from operators of XMR-custodying - bridges. -- **Independent of atomic-swap UX issues.** Mint and burn are LEZ-native - operations; there is no atomic-swap latency, no maker discovery, no - counterparty interactivity required for the core product. -- **Lowest engineering cost in the bundle's synthetics line.** Existing CDP - designs (Synthetix, MakerDAO, Liquity) provide a well-mapped implementation - template; the work is adapting those patterns to LEZ. -- **Builders are not blocked on LP-0018 or LP-0019.** Atomic-swap-specific - concerns (taker spam, maker reliability) do not apply to the CDP mint path; - those issues affect RFP-026 only. - -## Cons - -- **No path to real XMR within this RFP.** A user who wants XMR on Monero L1 - must either accept the secondary-market discount (sell sXMR for stables, buy - XMR off-platform) or wait for RFP-026 to ship and use that. The "synthetic" is - genuinely synthetic: no underlying-asset redemption. -- **Soft peg only.** sXMR tracks oracle within whatever spread the secondary - market clears. Under stress (oracle staleness, collateral crunch, panicked - unwinds) the peg can widen meaningfully. -- **Debt pool socialisation considerations.** In a V2-style debt pool, all sXMR - holders share aggregate Synth debt; in V3-style per-pool debt, the same - accounting model applies within a pool. Applicants must pick a model and - document its failure modes. -- **Privacy is partial.** sXMR is *not* a private asset on LEZ on its own; the - token program is public state. Privacy must come from LEZ-native shielding - (RFP-004's shielded swap intents, deshield-swap-reshield patterns). The CDP - vault and the mint/burn flow are public. -- **Open question: does Logos want a synthetic that does not redeem to the - underlying?** Synthetix-style synths have proven they can sustain liquidity - for major asset classes (sUSD, sETH) but Synthetix sXMR itself never achieved - meaningful volume. The XMR audience may specifically want real XMR, not a debt - instrument that tracks it. - -## Risks - -- **Oracle manipulation.** A manipulated XMR/USD oracle lets an attacker mint - sXMR cheaply or under-collateralise existing positions. Mitigation: redundant - oracle stack with median-of-N pricing; configurable price-deviation guards; - oracle-staleness checks. -- **Collateral solvency.** If the collateral asset (stables) depegs or is - compromised, sXMR backing degrades. Mitigation: accept only collateral with - documented threat models; cap protocol-wide collateral concentration by asset; - require liquidation parameters that hold under collateral-asset volatility. -- **Liquidation infrastructure under-built.** A CDP design that does not have - working keeper bots and a profitable liquidation incentive will hit insolvency - on the first market shock. Mitigation: design liquidation incentives - carefully; budget engineering for keeper operations; document MEV - considerations. -- **Demand asymmetry.** Mint demand may be easy (LEZ-DeFi users want XMR - exposure inside LEZ) but secondary-market XMR liquidity may not materialise. - The CDP design absorbs this — there is no LP bottleneck — but the token's - tradability is bottlenecked by LEZ DEX adoption. -- **Privacy-claim overreach.** sXMR is not a private asset; the privacy property - is only that *the underlying asset XMR is private*. Mint/burn on LEZ is - public. Documentation must be honest. -- **Synthetix-sXMR precedent.** Synthetix listed sXMR in 2020 and it did not - achieve meaningful adoption. Mitigation: LEZ-native privacy positioning and - tight LEZ-DeFi integration may differentiate, but applicants should validate - demand before building. - -## Relationship to other RFPs in this bundle - -- **RFP-003 (Atomic Swaps with LEZ, open)** is not a dependency of this RFP. - RFP-024 is a CDP design that does not interact with atomic swaps. RFP-026 - layers atomic-swap redemption on top of this RFP. -- **RFP-021 (cross-chain privacy DEX)** is the federated-custody alternative for - real-XMR exposure. Orthogonal product: RFP-024 gives synthetic XMR exposure - inside LEZ DeFi without custody; RFP-021 gives real XMR via a federated middle - layer. -- **RFP-025 (sXMR as real-XMR locked in trusted multisig)** is the not-preferred - alternative for real-XMR-backed sXMR. The two RFPs target the same audience - differently: RFP-024 says "we don't custody XMR"; RFP-025 says "we do, via a - federated multisig". RFP-024 is preferred. -- **RFP-026 (sXMR atomic-swap redemption to real XMR)** strictly extends this - RFP. RFP-024 ships first; RFP-026 adds an atomic-swap exit path for users who - want to redeem to Monero L1. RFP-026 does not re-spec the CDP mint mechanic. -- **RFP-004 (Privacy-Preserving DEX)** is the natural single-chain trading venue - for sXMR. Trade sXMR against stables on RFP-004's AMM pools under the - shield/deshield pattern. -- **LP-0018 and LP-0019** are atomic-swap-specific prizes; they affect RFP-026 - only. - -See -[appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) -for the deployed-synthetics taxonomy and the Synthetix CDP minting reference. - -## References - -- [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) -- [appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) -- [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) -- [Synthetix SIP-302 (Pools V3)](https://sips.synthetix.io/sips/sip-302) - (accessed 2026-05-22) — canonical CDP-minting reference, with direct relevance - to sXMR design. -- [Synthetix blog: Hadar release (sXMR ERC-20, 2020-03-30)](https://blog.synthetix.io/new-synths-update-for-the-upcoming-hadar-release/) - (accessed 2026-05-22) — historical Synthetix sXMR listing. diff --git a/RFPs/RFP-025-synthetic-xmr-sla.md b/RFPs/RFP-025-synthetic-xmr-sla.md index 93eb37d..4e20088 100644 --- a/RFPs/RFP-025-synthetic-xmr-sla.md +++ b/RFPs/RFP-025-synthetic-xmr-sla.md @@ -75,8 +75,9 @@ direct interactions with the multisig. ## Pros -- **Real XMR redemption with a documented SLA shape.** Unlike RFP-024 (no XMR - redemption) and unlike RFP-026 (best-effort matching, no guarantees), this +- **Real XMR redemption with a documented SLA shape.** Unlike RFP-024 (no + redemption to the real asset) and unlike RFP-026 (best-effort matching, no + guarantees), this design lets a user mint and redeem on demand, bounded by the signer-set responsiveness. - **Hard peg within reserve capacity.** sXMR is 1:1 backed by real XMR; oracle @@ -155,14 +156,14 @@ direct interactions with the multisig. ## Relationship to other RFPs in this bundle -- **RFP-024 (sXMR CDP-backed)** is the preferred alternative. RFP-024 says "we - don't custody XMR, sXMR is a debt instrument against stable collateral"; this - RFP says "we do custody XMR via a federated multisig". The two are mutually - exclusive product directions, not layered. -- **RFP-026 (sXMR atomic-swap redemption to real XMR)** is the non-custodial - alternative for delivering real XMR to users. RFP-026 builds on RFP-024 and - uses atomic swaps; RFP-025 holds real XMR in a multisig. RFP-026 has - best-effort SLA; RFP-025 has hard-peg-within-reserve. +- **RFP-024 (CDP-backed synthetics)** is the preferred alternative. Applied to + XMR, RFP-024 says "we don't custody XMR, sXMR is a debt instrument against + stable collateral"; this RFP says "we do custody XMR via a federated multisig". + The two are mutually exclusive product directions, not layered. +- **RFP-026 (synthetic atomic-swap redemption to the real asset)** is the + non-custodial alternative for delivering real XMR to users. RFP-026 builds on + RFP-024 and uses atomic swaps; RFP-025 holds real XMR in a multisig. RFP-026 + has best-effort SLA; RFP-025 has hard-peg-within-reserve. - **RFP-021 (cross-chain privacy DEX)** shares the federated-signer trust model. The two RFPs could share signer-set infrastructure if both are funded (same FROST-over-CLSAG primitives, possibly same validator set), trading some diff --git a/RFPs/RFP-026-sxmr-atomic-swap-redemption.md b/RFPs/RFP-026-sxmr-atomic-swap-redemption.md deleted file mode 100644 index 20ef473..0000000 --- a/RFPs/RFP-026-sxmr-atomic-swap-redemption.md +++ /dev/null @@ -1,196 +0,0 @@ ---- -id: RFP-026 -title: sXMR Atomic-Swap Redemption (extends RFP-024) -tier: L -funding: $TBD -status: draft -category: Applications & Integrations ---- - -# RFP-026 — sXMR Atomic-Swap Redemption to Real XMR - -> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos -> team and the community compare cross-chain DEX designs across RFP-021, -> RFP-024, RFP-025, and RFP-026. Hard requirements, FURPS detail, team profile, -> timeline, and contracting details are deliberately omitted; they will be -> filled in if the design is selected for funding. -> -> **This RFP strictly extends RFP-024.** RFP-024 (CDP-backed sXMR) is a hard -> prerequisite. RFP-026 adds an atomic-swap-based redemption path so that sXMR -> holders can exit to real XMR on Monero L1, without the protocol ever holding -> XMR. It does not re-specify the CDP mint mechanic. - -## 🧭 Overview - -Add a peer-to-peer atomic-swap redemption module on top of RFP-024's CDP-backed -sXMR. Holders of sXMR who want to receive real XMR on Monero L1 can post a -redemption intent over Logos Delivery; any XMR holder (an "LP") can quote and -counterparty the redemption via an atomic swap using the RFP-003 LEZ-XMR SDK. On -success, the user's sXMR is burned on LEZ, the LP receives the unlocked stable -collateral, and the user receives real XMR on Monero L1. - -The protocol holds no XMR at any step. There is no LP registry, no bond, no SLA. -Anyone with XMR can quote. Spreads widen under stress without bound; redemption -availability is whatever the LP market clears. This is the *non-custodial -real-XMR exit path* for RFP-024's CDP synthetic. Builders who want a guaranteed -redemption SLA backed by federated custody should look at RFP-025 instead. - -Inspired by **eigenwallet/COMIT BTC-XMR atomic swap** for the redemption-leg -cryptography. See -[appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) for the -underlying protocol mechanics and the locking-order protocol constraint -(LEZ-side locks first by protocol for XMR↔LEZ). - -## High-level functionality and flow - -```mermaid -flowchart LR - User[sXMR holder] -- redemption intent --> LD[Logos Delivery] - LP[Open XMR LP] -- quote --> LD - User -- accept quote --> LP - User -- lock sXMR vault on LEZ + atomic-swap setup --> LEZ[LEZ atomic-swap escrow] - LP -- lock XMR on Monero --> Mon[Monero] - User -- reveal secret --> LEZ - LP -- claim sXMR collateral, burn sXMR --> LEZ - Mon -- XMR to user's address --> UserExit[User on Monero L1] -``` - -Step-by-step: - -1. The sXMR holder publishes a redemption intent (notional, oracle price, - deadline) over Logos Delivery. -2. Any open-set XMR LP sees the intent, computes their quote (oracle ± spread), - and replies bilaterally over Logos Delivery / Logos Chat. -3. The holder accepts a quote and the two parties run the RFP-003 LEZ-XMR - atomic-swap protocol. The LEZ side (the sXMR + collateral release) locks - first; the LP locks XMR on Monero second. See - [primer §Locking order](../appendix/atomic-swaps-primer.md#locking-order) for - why this ordering is forced by protocol. -4. The holder reveals the secret on LEZ; the LP uses it to claim the sXMR-backed - stable collateral as their payout (less any protocol fee). The LP also has a - claim path on the Monero side to deliver real XMR to the holder. -5. On success, sXMR is burned on LEZ (collateral leaves the RFP-024 vault to the - LP); the holder receives real XMR on Monero L1. - -Failure modes: - -- **No LP shows up.** The holder's redemption intent expires; their sXMR - position is unchanged. They can retry, lower the price, or sell sXMR on a DEX - instead. -- **LP walks mid-swap.** The atomic-swap refund path unwinds; the holder retains - sXMR; the LP loses time and transaction fees. See - [primer §Timelocks and refunds](../appendix/atomic-swaps-primer.md#timelocks-and-refunds). -- **Holder walks mid-swap.** Symmetric; both parties refund. -- **The free-option problem applies.** Either party can walk and the other waits - out the refund window. This is intrinsic to atomic swaps; RFP-026 accepts it - as the cost of non-custody. LP-0018 (spam protection for makers) and LP-0019 - (taker reliability) may be layered on later but are not preconditions. - -## Pros - -- **Real XMR delivery without custody.** Successful redemption ends with real - XMR on Monero L1, with no protocol-side multisig holding the underlying. - RFP-025 carries custody risk; RFP-026 does not. -- **Composes cleanly with RFP-024.** The CDP mint mechanic from RFP-024 is - unchanged. RFP-026 adds a peer-to-peer exit path that LEZ DeFi users can use - alongside the standard burn-to-stables option. -- **Open LP set is censorship-resistant.** No permissioned set; no KYC; no - operator that can be coerced into refusing service. -- **Regulatory minimalism preserved from RFP-024.** The protocol does not handle - XMR; the atomic swap is a bilateral interaction between user and LP. The - protocol provides the LEZ-side escrow program, the matching board over Logos - Delivery, and the cryptographic primitives — nothing more. -- **Lowest-risk path to a real-XMR exit.** Other paths (RFP-021 federated DEX, - RFP-025 multisig wrap) require custody. RFP-026 keeps non-custody intact. - -## Cons - -- **Soft SLA only.** Redemption availability is whatever the LP market clears. - There is no protocol-side commitment to a delivery window. A user who wants a - hard SLA on real XMR must use RFP-025 (and accept its custody trade-off). -- **LP-side bottleneck likely.** Mint demand may be easy; LP supply (XMR holders - willing to atomic-swap their XMR for stables) is harder to source. - Privacy-maximalist XMR holders may not want a public LP role. -- **Atomic-swap UX inherited.** Settlement time is dominated by Monero block - confirmations (typically under an hour but with variance); both parties online - for the lock+reveal duration. Intent gossip over Logos Delivery softens but - cannot eliminate this. -- **Free-option problem applies.** Either party can walk mid-swap, costing the - other party time. This is intrinsic to atomic swaps. LP-0018 and LP-0019 - address it but are not preconditions; this RFP ships without those - mitigations. -- **Adverse-selection of LPs.** LPs likely show up when oracle is below true XMR - price (free money on the redemption leg) and vanish when oracle is above. - Redemption availability is expected to be asymmetric across price regimes. -- **No fee revenue capture for the protocol on the LP side.** Open LP set means - LPs capture the spread; the protocol's only revenue is mint/burn fees from - RFP-024 plus any explicit redemption-protocol fee. - -## Risks - -- **LP exodus.** All XMR holders stop quoting. Redemption becomes unavailable; - users fall back to RFP-024's sell-sXMR-on-DEX exit. The protocol cannot - intervene. Mitigation: design to survive long no-LP windows; let the market - discount on sXMR signal demand to bring LPs back. -- **Spam attacks on makers.** A malicious user can post redemption intents that - an LP locks against, then walks. LP loses time and fees per cycle. Mitigation: - LP-0018 if/when it ships; until then, LPs must filter intents at their own - discretion (e.g. requiring sXMR proof-of-balance or rate-limiting per - identity). -- **Maker-side reliability.** An unreliable LP can grief takers by - quote-and-walk. Mitigation: LP-0019 if/when it ships; until then, takers must - filter LPs by reputation gathered out-of-band. -- **Locking-order constraint.** The LEZ side must lock first for XMR↔LEZ (Monero - today provides no on-chain primitive supporting the locks-first role; see - [primer §Locking order](../appendix/atomic-swaps-primer.md#locking-order)). - For LEZ→XMR (this RFP's direction), this is the *taker* (sXMR holder) locking - first, which is the desired draining-attack posture (taker bears the - lock-window cost). Sub-case A in LP-0018's framing. -- **Atomic-swap protocol immaturity.** The deployed BTC-XMR atomic-swap - ecosystem (eigenwallet, Farcaster) is community-scale not volume-scale. - LEZ-XMR is a new pair; the LEZ-XMR module from RFP-003 must be built and - audited before this RFP can ship. Mitigation: RFP-003 is a prerequisite; - RFP-026 depends on its LEZ-XMR SDK. - -## Relationship to other RFPs in this bundle - -- **RFP-024 (sXMR CDP-backed)** is a **hard prerequisite**. RFP-026 does not - implement the CDP mint mechanic; it only adds the atomic-swap redemption path. - A builder funded for RFP-026 must build against a deployed (or jointly-built) - RFP-024. -- **RFP-003 (Atomic Swaps with LEZ, open)** is a **hard prerequisite**. The - LEZ-XMR atomic-swap SDK is the redemption settlement layer. RFP-026 does not - modify RFP-003; it consumes it. -- **RFP-025 (sXMR real-XMR multisig)** is the not-preferred alternative for - real-XMR delivery. RFP-025 promises a hard SLA at the cost of custody; RFP-026 - offers a soft SLA without custody. The two are mutually exclusive product - directions for the "deliver real XMR to sXMR holders" goal. -- **RFP-021 (cross-chain privacy DEX)** is orthogonal — federated-custody - real-XMR cross-chain swaps, not synthetic exposure with optional redemption. -- **LP-0018 (Spam protection for atomic-swap makers)** can be layered on the - redemption-leg atomic swap once the prize is awarded. Not a precondition; - RFP-026 ships with the free-option problem accepted as a known cost. -- **LP-0019 (Taker reliability for atomic swaps)** can be layered for - LP-discovery UX and maker-misbehaviour attribution. Not a precondition. -- **RFP-004 (Privacy-Preserving DEX, open)** is the natural single-chain trading - venue for sXMR pre-redemption (the alternative exit path that does not involve - atomic swaps at all). - -See [appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) for -atomic-swap mechanics and the locking-order protocol constraint, and -[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) -for the federated-signer-vs-atomic-swap trust contrast. - -## References - -- [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) -- [RFP-024: sXMR CDP-Backed Synthetic](./RFP-024-synthetic-xmr-pure.md) -- [appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) -- [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) -- [appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) -- [LP-0018: Spam Protection for Atomic-Swap Makers](../lambda-prizes/LP-0018-atomic-swap-anti-spam.md) -- [LP-0019: Taker Reliability for Atomic Swaps](../lambda-prizes/LP-0019-atomic-swap-maker-reputation.md) -- [Bitcoin to Monero atomic swaps (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) - (accessed 2026-05-21) -- [eigenwallet/core (active fork of comit-network/xmr-btc-swap; v4.6.4, 2026-05-21)](https://github.com/eigenwallet/core) - (accessed 2026-05-22) diff --git a/RFPs/RFP-026-synthetic-atomic-swap-redemption.md b/RFPs/RFP-026-synthetic-atomic-swap-redemption.md new file mode 100644 index 0000000..f63db5b --- /dev/null +++ b/RFPs/RFP-026-synthetic-atomic-swap-redemption.md @@ -0,0 +1,246 @@ +--- +id: RFP-026 +title: Synthetic Atomic-Swap Redemption (extends RFP-024) +tier: L +funding: $TBD +status: draft +category: Applications & Integrations +--- + +# RFP-026 — Atomic-Swap Redemption of Synthetics to the Real Asset + +> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos +> team and the community compare cross-chain DEX designs across RFP-021, +> RFP-024, RFP-025, and RFP-026. Hard requirements, FURPS detail, team profile, +> timeline, and contracting details are deliberately omitted; they will be +> filled in if the design is selected for funding. +> +> **This RFP strictly extends RFP-024.** RFP-024 (CDP-backed sASSET) is a hard +> prerequisite. RFP-026 adds an atomic-swap-based redemption path so that sASSET +> holders can exit to the real underlying asset on its home chain, without the +> protocol ever holding that asset. It does not re-specify the CDP mint mechanic. + +## 🧭 Overview + +Add a peer-to-peer atomic-swap redemption module on top of RFP-024's CDP-backed +synthetics. A holder of any sASSET (`sXMR`, `sZEC`, `sBTC`, `sETH`, …) who wants +to receive the real underlying asset on its home chain can post a redemption +intent over Logos Delivery; any holder of that real asset (an "LP") can quote and +counterparty the redemption via an atomic swap using the RFP-003 LEZ↔asset SDK. +On success, the user's sASSET is burned on LEZ, the LP receives the unlocked +stable collateral, and the user receives the real asset on its home chain. + +The protocol holds none of the real asset at any step. There is no LP registry, +no bond, no SLA. Anyone holding the asset can quote. Spreads widen under stress +without bound; redemption availability is whatever the LP market clears. This is +the *non-custodial real-asset exit path* for RFP-024's CDP synthetics. Builders +who want a guaranteed redemption SLA backed by federated custody should look at +RFP-025 instead. + +Inspired by **eigenwallet/COMIT BTC-XMR atomic swap** for the redemption-leg +cryptography. See +[appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) for the +underlying protocol mechanics and the locking-order protocol constraint. + +## Which assets fit this design + +Redemption works for an asset only when **both** conditions hold: + +1. **A CDP synthetic for it exists** (RFP-024 lists `sASSET` for that asset — + gated by the existence of a usable oracle), **and** +2. **Atomic-swap support for that asset's home chain exists** in the RFP-003 + LEZ↔asset SDK. + +The redeemable set is the *intersection* of those two. Oracle availability (the +RFP-024 gate) is the looser constraint; atomic-swap support is the tighter one, +because it depends on the asset's chain providing the cryptographic primitives +the swap protocol needs (adaptor signatures / scriptless-script locking, or +equivalent), and on the RFP-003 SDK having been built and audited for that pair. +Lead examples, in rough order of atomic-swap readiness: + +- **`sBTC` → BTC.** Bitcoin has the most mature atomic-swap tooling (the original + BTC-XMR swap was built around Bitcoin's scripting). The least exotic redemption + leg. +- **`sXMR` → XMR.** The bundle's motivating case. The eigenwallet/COMIT BTC-XMR + protocol is the reference; the LEZ↔XMR leg must be built in RFP-003. The Monero + side carries the locking-order constraint described below. +- **`sZEC` → ZEC.** Shielded-asset redemption; viable in principle, dependent on + the LEZ↔ZEC swap leg existing in RFP-003. Shielded-pool interaction adds + protocol work on the swap side. +- **`sETH` → ETH.** Mechanically the simplest swap counterparty (rich scripting), + though the demand case is weakest — ETH holders rarely need a non-custodial exit + from a synthetic. Listed mainly to show the design is not privacy-coin-specific. + +An asset that has a CDP synthetic (RFP-024) but **no** atomic-swap support is +*not* redeemable via this RFP; its holders are limited to RFP-024's +sell-on-a-DEX exit until the swap leg is built. Applicants should treat "is there +an audited LEZ↔asset atomic-swap leg?" as the gating question per asset, the same +way RFP-024 treats the oracle question. + +## High-level functionality and flow + +```mermaid +flowchart LR + User[sASSET holder] -- redemption intent --> LD[Logos Delivery] + LP[Open asset LP] -- quote --> LD + User -- accept quote --> LP + User -- lock sASSET vault on LEZ + atomic-swap setup --> LEZ[LEZ atomic-swap escrow] + LP -- lock asset on home chain --> Home[Asset home chain] + User -- reveal secret --> LEZ + LP -- claim sASSET collateral, burn sASSET --> LEZ + Home -- real asset to user's address --> UserExit[User on asset home chain] +``` + +Step-by-step (worked with XMR as the example; substitute the asset and its home +chain for other listings): + +1. The sASSET holder publishes a redemption intent (notional, oracle price, + deadline) over Logos Delivery. +2. Any open-set LP holding the real asset sees the intent, computes their quote + (oracle ± spread), and replies bilaterally over Logos Delivery / Logos Chat. +3. The holder accepts a quote and the two parties run the RFP-003 LEZ↔asset + atomic-swap protocol. The LEZ side (the sASSET + collateral release) locks + first where the asset's chain forces that ordering; the LP locks the real + asset on its home chain second. See + [primer §Locking order](../appendix/atomic-swaps-primer.md#locking-order) for + when and why this ordering is forced (it is a per-chain property of the + underlying, not a global rule). +4. The holder reveals the secret on LEZ; the LP uses it to claim the sASSET-backed + stable collateral as their payout (less any protocol fee). The LP also has a + claim path on the home-chain side to deliver the real asset to the holder. +5. On success, sASSET is burned on LEZ (collateral leaves the RFP-024 vault to + the LP); the holder receives the real asset on its home chain. + +Failure modes: + +- **No LP shows up.** The holder's redemption intent expires; their sASSET + position is unchanged. They can retry, lower the price, or sell sASSET on a DEX + instead. +- **LP walks mid-swap.** The atomic-swap refund path unwinds; the holder retains + sASSET; the LP loses time and transaction fees. See + [primer §Timelocks and refunds](../appendix/atomic-swaps-primer.md#timelocks-and-refunds). +- **Holder walks mid-swap.** Symmetric; both parties refund. +- **The free-option problem applies.** Either party can walk and the other waits + out the refund window. This is intrinsic to atomic swaps; RFP-026 accepts it as + the cost of non-custody. LP-0018 (spam protection for makers) and LP-0019 + (taker reliability) may be layered on later but are not preconditions. + +## Pros + +- **Real asset delivery without custody.** Successful redemption ends with the + real asset on its home chain (real XMR on Monero L1, real BTC on Bitcoin, …), + with no protocol-side multisig holding the underlying. RFP-025 carries custody + risk; RFP-026 does not. +- **Composes cleanly with RFP-024.** The CDP mint mechanic from RFP-024 is + unchanged. RFP-026 adds a peer-to-peer exit path that LEZ DeFi users can use + alongside the standard burn-to-stables option, for any asset whose swap leg + exists. +- **Open LP set is censorship-resistant.** No permissioned set; no KYC; no + operator that can be coerced into refusing service. +- **Regulatory minimalism preserved from RFP-024.** The protocol does not handle + the real asset; the atomic swap is a bilateral interaction between user and LP. + The protocol provides the LEZ-side escrow program, the matching board over + Logos Delivery, and the cryptographic primitives — nothing more. +- **Lowest-risk path to a real-asset exit.** Other paths (RFP-021 federated DEX, + RFP-025 multisig wrap) require custody. RFP-026 keeps non-custody intact. + +## Cons + +- **Redemption set narrower than the synthetic set.** Some assets will have a CDP + synthetic (RFP-024) but no atomic-swap leg, so they cannot be redeemed here. + The redeemable set lags the mintable set by however long the LEZ↔asset swap legs + take to build and audit in RFP-003. +- **Soft SLA only.** Redemption availability is whatever the LP market clears. + There is no protocol-side commitment to a delivery window. A user who wants a + hard SLA on the real asset must use RFP-025 (and accept its custody trade-off). +- **LP-side bottleneck likely.** Mint demand may be easy; LP supply (holders of + the real asset willing to atomic-swap it for stables) is harder to source. For + privacy-coin underlyings, privacy-maximalist holders may not want a public LP + role. +- **Atomic-swap UX inherited.** Settlement time is dominated by the home chain's + block confirmations (for XMR typically under an hour but with variance; varies + per asset); both parties online for the lock+reveal duration. Intent gossip over + Logos Delivery softens but cannot eliminate this. +- **Free-option problem applies.** Either party can walk mid-swap, costing the + other party time. This is intrinsic to atomic swaps. LP-0018 and LP-0019 address + it but are not preconditions; this RFP ships without those mitigations. +- **Adverse-selection of LPs.** LPs likely show up when oracle is below the true + asset price (free money on the redemption leg) and vanish when oracle is above. + Redemption availability is expected to be asymmetric across price regimes. +- **No fee revenue capture for the protocol on the LP side.** Open LP set means + LPs capture the spread; the protocol's only revenue is mint/burn fees from + RFP-024 plus any explicit redemption-protocol fee. + +## Risks + +- **LP exodus.** All LPs for an asset stop quoting. Redemption of that synthetic + becomes unavailable; users fall back to RFP-024's sell-on-DEX exit. The protocol + cannot intervene. Mitigation: design to survive long no-LP windows; let the + market discount on the synthetic signal demand to bring LPs back. +- **Spam attacks on makers.** A malicious user can post redemption intents that an + LP locks against, then walks. LP loses time and fees per cycle. Mitigation: + LP-0018 if/when it ships; until then, LPs must filter intents at their own + discretion (e.g. requiring sASSET proof-of-balance or rate-limiting per + identity). +- **Maker-side reliability.** An unreliable LP can grief takers by quote-and-walk. + Mitigation: LP-0019 if/when it ships; until then, takers must filter LPs by + reputation gathered out-of-band. +- **Locking-order constraint (per chain).** On some home chains the LEZ side must + lock first because the underlying provides no on-chain primitive supporting the + locks-first role — Monero is the canonical case (see + [primer §Locking order](../appendix/atomic-swaps-primer.md#locking-order)). For + the LEZ→asset direction (this RFP's direction), this is the *taker* (sASSET + holder) locking first, which is the desired draining-attack posture (taker bears + the lock-window cost). Sub-case A in LP-0018's framing. Chains with richer + scripting (Bitcoin, Ethereum) relax this; the constraint is asset-specific. +- **Atomic-swap protocol immaturity.** The deployed BTC-XMR atomic-swap ecosystem + (eigenwallet, Farcaster) is community-scale not volume-scale. Each LEZ↔asset + pair is new; the relevant LEZ↔asset module from RFP-003 must be built and + audited before that asset can be redeemed here. Mitigation: RFP-003 is a + prerequisite; RFP-026 depends on its per-asset atomic-swap SDK, and the set of + redeemable assets grows only as those legs land. + +## Relationship to other RFPs in this bundle + +- **RFP-024 (CDP-backed sASSET)** is a **hard prerequisite**. RFP-026 does not + implement the CDP mint mechanic; it only adds the atomic-swap redemption path. A + builder funded for RFP-026 must build against a deployed (or jointly-built) + RFP-024. +- **RFP-003 (Atomic Swaps with LEZ, open)** is a **hard prerequisite**. The + per-asset LEZ↔asset atomic-swap SDK is the redemption settlement layer, and it + defines which assets are redeemable. RFP-026 does not modify RFP-003; it + consumes it. +- **RFP-025 (real-asset multisig)** is the not-preferred custody-backed + alternative for real-asset delivery, scoped to XMR. RFP-025 promises a hard SLA + at the cost of custody; RFP-026 offers a soft SLA without custody. For the XMR + case the two are mutually exclusive product directions for the "deliver the real + asset to synthetic holders" goal. +- **RFP-021 (cross-chain privacy DEX)** is orthogonal — federated-custody + real-asset cross-chain swaps, not synthetic exposure with optional redemption. +- **LP-0018 (Spam protection for atomic-swap makers)** can be layered on the + redemption-leg atomic swap once the prize is awarded. Not a precondition; + RFP-026 ships with the free-option problem accepted as a known cost. +- **LP-0019 (Taker reliability for atomic swaps)** can be layered for LP-discovery + UX and maker-misbehaviour attribution. Not a precondition. +- **RFP-004 (Privacy-Preserving DEX, open)** is the natural single-chain trading + venue for sASSET pre-redemption (the alternative exit path that does not involve + atomic swaps at all). + +See [appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) for +atomic-swap mechanics and the locking-order protocol constraint, and +[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) +for the federated-signer-vs-atomic-swap trust contrast. + +## References + +- [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md) +- [RFP-024: CDP-Backed Synthetic Assets](./RFP-024-cdp-backed-synthetic.md) +- [appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) +- [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) +- [appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) +- [LP-0018: Spam Protection for Atomic-Swap Makers](../lambda-prizes/LP-0018-atomic-swap-anti-spam.md) +- [LP-0019: Taker Reliability for Atomic Swaps](../lambda-prizes/LP-0019-atomic-swap-maker-reputation.md) +- [Bitcoin to Monero atomic swaps (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html) + (accessed 2026-05-21) +- [eigenwallet/core (active fork of comit-network/xmr-btc-swap; v4.6.4, 2026-05-21)](https://github.com/eigenwallet/core) + (accessed 2026-05-22)