diff --git a/README.md b/README.md index f00778c..0e0f9c4 100644 --- a/README.md +++ b/README.md @@ -74,21 +74,25 @@ Click an RFP to view details. Use the Submit Proposal button to apply. -| ID | Title | Tier | Status | Category | Submit Proposal | -| ------- | ------------------------------------------------------------------------------------ | ---- | ------ | ---------------------------------- | ----------------------------------------------------------------------------------- | -| RFP-001 | [Admin Authority Library](RFPs/RFP-001-admin-authority-lib.md) | XS | closed | Developer Tooling & Infrastructure | Closed | -| RFP-002 | [Freeze Authority Library](RFPs/RFP-002-freeze-authority-lib.md) | XS | closed | Developer Tooling & Infrastructure | Closed | -| RFP-003 | [Atomic Swaps with LEZ](RFPs/RFP-003-atomic-swaps.md) | XL | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | -| RFP-004 | [Privacy-Preserving DEX](RFPs/RFP-004-privacy-preserving-dex.md) | XL | closed | Applications & Integrations | Closed | -| RFP-008 | [Lending & Borrowing Protocol](RFPs/RFP-008-lending-borrowing-protocol.md) | XL | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | -| RFP-012 | [Curated Lending Vaults](RFPs/RFP-012-curated-lending-vaults.md) | L | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | -| RFP-013 | [Reflexive Stablecoin Protocol](RFPs/RFP-013-reflexive-stablecoin-protocol.md) | XL | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | -| RFP-014 | [Liquidation & Auction Engine](RFPs/RFP-014-liquidation-auction-engine.md) | L | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | -| RFP-015 | [Token Launchpad: Bonding Curve](RFPs/RFP-015-bonding-curve-launchpad.md) | L | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | -| RFP-016 | [Token Launchpad: LBP](RFPs/RFP-016-lbp-launchpad.md) | XL | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | -| RFP-017 | [Privacy-Preserving Token Vesting](RFPs/RFP-017-token-vesting.md) | L | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | -| RFP-019 | [On-Chain TWAP Oracle](RFPs/RFP-019-twap-oracle.md) | L | open | Developer Tooling & Infrastructure | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | -| RFP-020 | [RedStone Off-Chain Oracle Adaptor for LEZ](RFPs/RFP-020-redstone-oracle-adaptor.md) | M | open | Developer Tooling & Infrastructure | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| ID | Title | Tier | Status | Category | Submit Proposal | +| ------- | ------------------------------------------------------------------------------------------- | ---- | ------- | ---------------------------------- | ----------------------------------------------------------------------------------- | +| RFP-001 | [Admin Authority Library](RFPs/RFP-001-admin-authority-lib.md) | XS | closed | Developer Tooling & Infrastructure | Closed | +| RFP-002 | [Freeze Authority Library](RFPs/RFP-002-freeze-authority-lib.md) | XS | closed | Developer Tooling & Infrastructure | Closed | +| RFP-003 | [Atomic Swaps with LEZ](RFPs/RFP-003-atomic-swaps.md) | XL | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-004 | [Privacy-Preserving DEX](RFPs/RFP-004-privacy-preserving-dex.md) | XL | closed | Applications & Integrations | Closed | +| RFP-008 | [Lending & Borrowing Protocol](RFPs/RFP-008-lending-borrowing-protocol.md) | XL | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-012 | [Curated Lending Vaults](RFPs/RFP-012-curated-lending-vaults.md) | L | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-013 | [Reflexive Stablecoin Protocol](RFPs/RFP-013-reflexive-stablecoin-protocol.md) | XL | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-014 | [Liquidation & Auction Engine](RFPs/RFP-014-liquidation-auction-engine.md) | L | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-015 | [Token Launchpad: Bonding Curve](RFPs/RFP-015-bonding-curve-launchpad.md) | L | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-016 | [Token Launchpad: LBP](RFPs/RFP-016-lbp-launchpad.md) | XL | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-017 | [Privacy-Preserving Token Vesting](RFPs/RFP-017-token-vesting.md) | L | open | Applications & Integrations | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-019 | [On-Chain TWAP Oracle](RFPs/RFP-019-twap-oracle.md) | L | open | Developer Tooling & Infrastructure | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-020 | [RedStone Off-Chain Oracle Adaptor for LEZ](RFPs/RFP-020-redstone-oracle-adaptor.md) | M | open | Developer Tooling & Infrastructure | [Submit Proposal](https://github.com/logos-co/rfp/issues/new?template=proposal.yml) | +| RFP-021 | [Cross-Chain Privacy DEX (Federated Middle Layer)](RFPs/RFP-021-cross-chain-privacy-dex.md) | XL | dropped | Applications & Integrations | Dropped | +| RFP-024 | [CDP-Backed Synthetic Assets (sASSET)](RFPs/RFP-024-cdp-backed-synthetic.md) | L | draft | Applications & Integrations | — | +| RFP-025 | [Synthetic XMR in Threshold-Signer Multisig](RFPs/RFP-025-synthetic-xmr-sla.md) | XL | dropped | Applications & Integrations | Dropped | +| RFP-026 | [Atomic-Swap Redemption of Synthetics](RFPs/RFP-026-synthetic-atomic-swap-redemption.md) | M | draft | Applications & Integrations | — | 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..0254b7d --- /dev/null +++ b/RFPs/RFP-021-cross-chain-privacy-dex.md @@ -0,0 +1,35 @@ +--- +id: RFP-021 +title: Cross-Chain Privacy DEX (Federated Middle Layer) +tier: XL +funding: $TBD +status: dropped +category: Applications & Integrations +--- + +# RFP-021 — Cross-Chain Privacy DEX (Federated Middle Layer) [DROPPED] + +> **This RFP has been dropped.** It is retained as a tombstone for the +> historical record; the full original design is in git history. + +## Why it was dropped + +RFP-021 proposed a federated-signer middle chain that custodies external assets +(BTC, ETH, XMR) in a threshold-signature vault held by the LEZ validator set, +following the Thorchain/Serai pattern. That model reintroduces exactly the trust +assumption the cross-chain bundle is designed to avoid: a federated signer set +that holds user funds, can be coerced or captured, carries a non-zero historical +loss rate, and (for XMR) leaks deposit history to signers via view-key sharing. + +The bundle's direction is the most trustless path available. The preferred stack +is non-custodial: + +- **RFP-024** — CDP-backed synthetics (no custody of the tracked asset at all). +- **RFP-026** — atomic-swap redemption of synthetics to the real asset, built on + RFP-003, with the protocol holding none of the real asset. + +The neutral survey of the federated-middle-chain model and its adoption and +failure record is preserved in +[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md). +The full original RFP-021 text (overview, flow, pros/cons, risks, references) is +available in this repository's git history. diff --git a/RFPs/RFP-024-cdp-backed-synthetic.md b/RFPs/RFP-024-cdp-backed-synthetic.md new file mode 100644 index 0000000..80007e1 --- /dev/null +++ b/RFPs/RFP-024-cdp-backed-synthetic.md @@ -0,0 +1,316 @@ +--- +id: RFP-024 +title: CDP-Backed Synthetic Assets (sASSET) for Any Oracle-Priced Asset +tier: L +funding: $TBD +status: draft +category: Applications & Integrations +--- + +# RFP-024 — CDP-Backed Synthetic Assets (sASSET) + +> **Note:** This RFP is a *decision-stage draft*. The cross-chain bundle has +> converged on the trustless path: the federated-custody designs (RFP-021, +> RFP-025) have been dropped, and this RFP plus RFP-026 (atomic-swap redemption +> on RFP-003) are the kept stack. 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. 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). + +## Why not a federated middle chain or a custodial bridge + +The cross-chain bundle deliberately converges on the most trustless mechanism +available, and this RFP is the centre of that choice. Two well-deployed +alternatives were considered and rejected for the synthetic-asset product: + +- **Federated-signer middle chain (Thorchain/Serai-style).** A purpose-built + chain whose validator set custodies external assets in a threshold-signature + vault. This buys AMM liquidity and one-step UX, but it reintroduces a signer + set that holds user funds, can be captured or coerced, carries a non-zero + historical loss rate (Thorchain's 2026-05-15 TSS vault drain; Wormhole's 2022 + bridge loss), and — for privacy-coin underlyings — leaks deposit history to + signers via view-key sharing. This was the dropped RFP-021. +- **Custodial bridge / real-asset multisig (sBTC / + Secret-Monero-Bridge-style).** A token backed 1:1 by the real asset held in a + federated multisig. Same custody trust class: signer-set capture risk, a + liveness-bound redemption SLA, and the same XMR view-key disclosure. The + Secret Monero Bridge is the cautionary deployed precedent — a trusted-operator + multisig with no economic security and privacy-hostile onboarding that the + Monero community refused to adopt. This was the dropped RFP-025. + +The CDP design in this RFP avoids both: the protocol holds only LEZ-side stable +collateral and never custodies the tracked asset, so there is no signer set, no +multisig, no bridge, and no deposit-history leak. Users who specifically want +the real asset on its home chain reach it through RFP-026's non-custodial +atomic-swap redemption, not through a federation. The neutral survey of both +rejected models and their adoption records is in +[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md) +(federated middle chain) and the Secret Monero Bridge negative example in +[appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md). + +## 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. + +## Liquidation mechanism (required) + +This RFP must specify its liquidation mechanism explicitly rather than punting +to "standard CDP liquidation". A synthetic that tracks a volatile asset with a +thin secondary market has a liquidator-shortage failure mode that generic CDP +designs do not address: + +- A borrower mints sASSET against stable collateral. The tracked asset's price + rises and the vault's c-ratio breaches the liquidation threshold. +- A keeper-style liquidator must source sASSET on-market to repay the debt and + claim the seized collateral at a discount. If the underlying keeps moving + while the liquidator sources sASSET, the sASSET they need can cost more than + the discount they capture. +- The liquidator does not show up; the position goes further underwater; the + protocol takes bad debt. + +This is a structural ceiling on safe issuance: in a thin sASSET market the band +where liquidation is profitable narrows as the underlying moves faster. It also +means the liquidation layer **cannot ride on a generic lending-market +substrate** (Aave/Compound/Morpho-style designs assume the borrowed asset has a +deep secondary market the liquidator can hit in one transaction). Position +accounting (isolated CDPs, c-ratios, oracle pricing) can be reused; the +liquidation absorption mechanism cannot. + +**Required baseline: a Liquity-style stability pool.** Depositors pre-fund a +pool with sASSET. When a CDP breaches the threshold, the protocol atomically +burns sASSET from the pool against the debt and distributes the seized +collateral pro-rata to pool depositors. This removes the liquidator's dependence +on secondary-market sASSET depth (the burn-against-pool is atomic with the +liquidation, so execution slippage is irrelevant), collapses the liquidator role +into "anyone who calls the trigger function", and gives sASSET holders a +defensible reason to lock supply into the pool (yield denominated in seized +collateral). Crucially, the protocol can safely issue sASSET up to roughly the +stability pool's coverage capacity, which is observable on-chain rather than +dependent on opaque off-chain market depth. + +Applicants may propose alternative liquidation absorption mechanisms, but the +RFP calls out the thin-secondary-market problem explicitly and the submission +must justify why its mechanism survives it. "Standard CDP liquidation" against +an assumed deep market is not acceptable for this product. + +## 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-008 (Lending & Borrowing Protocol)** is an **optional soft dependency**. + An applicant may implement the CDP position accounting (isolated vaults, + c-ratios, oracle pricing) as a module on top of RFP-008's lending market + rather than building standalone CDP infrastructure, in the spirit of + MakerDAO's Direct Deposit modules. This can save development effort and let + applicants quote lower. It is soft, not hard: the synthetic must still + function if RFP-008 is unavailable, and regardless of substrate the + stability-pool liquidation mechanism above is always required (a generic + lending market does not provide it). +- **RFP-021 (cross-chain privacy DEX) — dropped.** It was the federated-custody + alternative for real-asset exposure; it has been dropped in favour of this + non-custodial CDP design. See the + [RFP-021 tombstone](./RFP-021-cross-chain-privacy-dex.md) and the "Why not a + federated middle chain or a custodial bridge" section above. +- **RFP-025 (real-asset locked in trusted multisig) — dropped.** It was the + custody-backed alternative scoped to XMR; it has been dropped for the same + trustless-maximalist reason. See the + [RFP-025 tombstone](./RFP-025-synthetic-xmr-sla.md). +- **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-025-synthetic-xmr-sla.md b/RFPs/RFP-025-synthetic-xmr-sla.md new file mode 100644 index 0000000..bb53189 --- /dev/null +++ b/RFPs/RFP-025-synthetic-xmr-sla.md @@ -0,0 +1,37 @@ +--- +id: RFP-025 +title: Synthetic XMR (sXMR) — Real XMR in Threshold-Signer Multisig +tier: XL +funding: $TBD +status: dropped +category: Applications & Integrations +--- + +# RFP-025 — Synthetic XMR Backed by Real XMR in Trusted Multisig [DROPPED] + +> **This RFP has been dropped.** It is retained as a tombstone for the +> historical record; the full original design is in git history. + +## Why it was dropped + +RFP-025 proposed an sXMR token backed 1:1 by real XMR held in a threshold-signer +multisig on Monero. That is the same federated-custody trust class as the +dropped RFP-021: a bonded signer set custodies real assets, carries custody and +liveness risk, is a censorship and coercion chokepoint, and leaks Monero deposit +history to signers via view-key sharing. It reintroduces precisely the trust +assumptions the bundle's preferred CDP path deliberately avoids. + +The bundle's direction is the most trustless path available. For synthetic XMR +(and any other asset) the preferred design is non-custodial: + +- **RFP-024** — CDP-backed `sASSET`, a debt instrument against stable + collateral. The protocol never touches the tracked asset. +- **RFP-026** — optional atomic-swap redemption to the real asset on its home + chain, again with no protocol-side custody. + +The deployed prior art for the custody-backed approach (sBTC, Secret Monero +Bridge) and the federated-signer trust analysis are preserved in +[appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md) +and +[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md). +The full original RFP-025 text is available in this repository's git history. 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..ee0f965 --- /dev/null +++ b/RFPs/RFP-026-synthetic-atomic-swap-redemption.md @@ -0,0 +1,269 @@ +--- +id: RFP-026 +title: Synthetic Atomic-Swap Redemption (extends RFP-024) +tier: M +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*. The cross-chain bundle has +> converged on the trustless path: the federated-custody designs (RFP-021, +> RFP-025) have been dropped, and this RFP plus RFP-024 (CDP-backed sASSET) are +> the kept stack. 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. + +This RFP exists precisely so that real-asset delivery does not require a +federation. The federated alternatives — a Thorchain/Serai-style middle chain +that custodies the asset (the dropped RFP-021) and a real-asset multisig wrap +(the dropped RFP-025) — were rejected for the bundle because both reintroduce a +signer set that holds user funds, can be captured or coerced, and (for XMR) +leaks deposit history. RFP-026 accepts a soft, market-cleared SLA as the cost of +keeping the exit path fully non-custodial. A builder who genuinely needs a hard, +federation-backed redemption SLA is choosing a trust model the bundle has +deliberately moved away from; see the +[appendix trust-model contrast](../appendix/cross-chain-trust-model-contrast.md) +for why. + +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. The custody-backed + alternative (the dropped RFP-025) carried that 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.** The federated alternatives that + were considered (RFP-021 federated DEX, RFP-025 multisig wrap) required + custody and were dropped for that reason. 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 hard, + federation-backed redemption SLA would require custody (the trade-off the + dropped RFP-025 made); the bundle has deliberately chosen the non-custodial + soft-SLA path instead. Users who want a hard exit settle on the secondary + market via RFP-024 (sell sASSET for stables) rather than through a federation. +- **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) — dropped.** It was the custody-backed + alternative for real-asset delivery (a hard SLA at the cost of custody), + scoped to XMR. It has been dropped; RFP-026's soft-SLA non-custodial path is + the kept design for delivering the real asset to synthetic holders. See the + [RFP-025 tombstone](./RFP-025-synthetic-xmr-sla.md). +- **RFP-021 (cross-chain privacy DEX) — dropped.** It was the federated-custody + real-asset cross-chain swap design; dropped for the same trustless-maximalist + reason. See the [RFP-021 tombstone](./RFP-021-cross-chain-privacy-dex.md). +- **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) diff --git a/appendix/atomic-swaps-primer.md b/appendix/atomic-swaps-primer.md new file mode 100644 index 0000000..c08f0e6 --- /dev/null +++ b/appendix/atomic-swaps-primer.md @@ -0,0 +1,381 @@ +# 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 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-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 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-22); + [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332](https://arxiv.org/abs/2101.12332) + (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-22). + +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`, +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 (deployed COMIT/eigenwallet direction) + +- **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 (XMR holder) + participant BTC as Bitcoin + participant XMR as Monero + participant B as Bob (BTC holder) + + 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 (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 (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 + 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 +``` + +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). 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, 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/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) +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 + +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. + +- `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. + +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 + (~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. + +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-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. 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 + 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 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. + +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 deployed BTC-first XMR-BTC flow: + +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. 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 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). + +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: + +`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. + +## 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 **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 + +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 + +- **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 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. + +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-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 (2021-01-29)](https://arxiv.org/abs/2101.12332) + (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-22) +- [Han et al., On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896) + (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/cross-chain-trust-model-contrast.md b/appendix/cross-chain-trust-model-contrast.md new file mode 100644 index 0000000..0208223 --- /dev/null +++ b/appendix/cross-chain-trust-model-contrast.md @@ -0,0 +1,349 @@ +# 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. + +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. + +### Federated-signer middle chain + +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. + 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. +- 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). + +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. + +### 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. + +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). +- **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. + 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. + +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. + +## Adoption record + +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). + +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, 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 + +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) +- [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/synthetics-design-space.md b/appendix/synthetics-design-space.md new file mode 100644 index 0000000..d5dbf14 --- /dev/null +++ b/appendix/synthetics-design-space.md @@ -0,0 +1,264 @@ +# 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 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). +- **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: + +- 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).** 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). 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 + 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). +- 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). + +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. + +## 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/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) 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..4e4594a --- /dev/null +++ b/lambda-prizes/LP-0018-atomic-swap-anti-spam.md @@ -0,0 +1,257 @@ + + + + +# LP-0018: Spam Protection for Atomic-Swap Makers [Draft] + +**`Status`**: + +- Draft: Not yet ready +- Open: Ready for application +- Completed: Submission accepted, prize completed + +**`Logos Circle: N/A`** + +## Overview + +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. + +### 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 a known structural +weakness on the free-option / spam-the-maker problem. The Logos cross-chain DEX +bundle (RFP-024 and RFP-026, on the vanilla RFP-003 atomic swap) uses that 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, 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 + +- [ ] **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; the bundle deliberately rejected the federated-custody + design space (see + [appendix/cross-chain-trust-model-contrast.md](https://github.com/logos-co/rfp/blob/master/appendix/cross-chain-trust-model-contrast.md)). +- **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 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). +- Reintroducing federated trust (TSS custody, signer sets, oracle attestors). + The bundle deliberately rejected that design space (see + [appendix/cross-chain-trust-model-contrast.md](https://github.com/logos-co/rfp/blob/master/appendix/cross-chain-trust-model-contrast.md)). +- LEZ↔BTC, LEZ↔ETH, or other non-XMR pairs. Follow-up prizes if needed. + +## 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, 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, 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 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 +[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 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, 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) + — 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 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 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 new file mode 100644 index 0000000..12742db --- /dev/null +++ b/lambda-prizes/LP-0019-atomic-swap-maker-reputation.md @@ -0,0 +1,259 @@ + + + + +# LP-0019: Taker Reliability for Atomic Swaps [Draft] + +**`Status`**: + +- Draft: Not yet ready +- Open: Ready for application +- Completed: Submission accepted, prize completed + +**`Logos Circle: N/A`** + +## Overview + +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 + +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 +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 + +- [ ] **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; the bundle deliberately rejected the federated-custody design + space (see + [appendix/cross-chain-trust-model-contrast.md](https://github.com/logos-co/rfp/blob/master/appendix/cross-chain-trust-model-contrast.md)). +- **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 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 + +- 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 + +- **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, + 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, run the demo, exercise the +maker-misbehaviour and fabricated-complaint scenarios, and verify the +proven-reliability evidence. + +Tied submissions may be ranked on: + +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)): + +- **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 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, 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, 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 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. + +## Potential for Subsequent λPrizes + +If this prize is awarded for an XMR↔LEZ mechanism, follow-up prizes may cover +other pairs once XMR↔LEZ has a winning mechanism.