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..5126196
--- /dev/null
+++ b/RFPs/RFP-021-cross-chain-privacy-dex.md
@@ -0,0 +1,233 @@
+---
+id: RFP-021
+title: Cross-Chain Privacy DEX (Federated Middle Layer)
+tier: XL
+funding: $TBD
+status: draft
+category: Applications & Integrations
+---
+
+# RFP-021 — Cross-Chain Privacy DEX (Federated Middle Layer)
+
+> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos
+> team and the community compare cross-chain DEX designs across RFP-021,
+> RFP-024, RFP-025, and RFP-026. Hard requirements, FURPS detail, team profile,
+> timeline, and contracting details are deliberately omitted; they will be
+> filled in if the design is selected for funding.
+>
+> **RFP-021 is not the preferred standalone design** (the team's preference is
+> the non-custodial atomic-swap path: RFP-024 + RFP-026 on RFP-003). However, it
+> is **complementary to atomic swaps**: the federated middle chain handles
+> high-liquidity bulk trading at AMM UX where users accept federated custody as
+> the trade-off, while atomic swaps handle the privacy-maximalist niche where
+> cryptographic non-custody beats UX convenience. The two can coexist.
+
+## 🧭 Overview
+
+Build a cross-chain privacy DEX on LEZ that custodies external assets (BTC, ETH,
+XMR, and others) via a threshold signature scheme held by the LEZ validator set,
+executes swaps natively against an AMM, and adds LEZ-specific privacy primitives
+(shielded swap intents, sealed-bid batch matching, stealth outbound addresses)
+that the existing comparators (Thorchain, Serai, Maya, Chainflip) do not offer.
+
+The design follows the **federated-signer middle chain** pattern that Thorchain
+(over $120B cumulative volume since 2021 per DefiLlama, accessed 2026-05-21) and
+Serai (pre-mainnet, post-cryptographic-audit by Cypher Stack in May 2025) have
+converged on. RFP-021 inherits that pattern's well-understood AMM-style
+liquidity and one-step user experience, then layers LEZ's privacy execution
+primitives on top to close the privacy gap that every comparator leaves open:
+even Serai's middle-chain state is publicly readable, and Thorchain's
+source-chain memos link source and destination addresses on transparent ledgers
+before the middle chain even sees them.
+
+This is the most ambitious option in the cross-chain bundle. It is also the one
+with the strongest empirical case (volume, user experience, asset coverage) and
+the strongest custody risk.
+
+**RFP-021 is not the preferred design on its own.** The federated-signer custody
+model trades non-custody for AMM liquidity and one-step UX; the Logos team's
+working preference is the non-custodial atomic-swap path (RFP-003 plus the
+CDP-backed synthetic designs in RFP-024 and RFP-026) where users do not have to trust a validator
+set. However, RFP-021 can be **complementary to atomic swaps**: the AMM-style
+middle chain handles high-liquidity bulk trading where users are willing to
+accept federated custody for better UX, while atomic swaps handle the
+privacy-maximalist niche where users prefer cryptographic non-custody to UX
+convenience. The two designs serve different audiences and can coexist in the
+same LEZ ecosystem, with the user choosing the trust trade-off they want for
+each swap.
+
+## High-level functionality and flow
+
+```mermaid
+flowchart TB
+    subgraph Validators["LEZ validator set (100-600 nodes, bonded)"]
+        direction LR
+        V1["Validator 1"]
+        V2["Validator 2"]
+        Vn["Validator N"]
+        V1 --- V2 --- Vn
+    end
+
+    subgraph Vaults["TSS vaults (FROST threshold signatures, per curve)"]
+        direction LR
+        ETHVault["ETH vault<br/>(secp256k1)"]
+        BTCVault["BTC vault<br/>(secp256k1)"]
+        XMRVault["XMR vault<br/>(Ed25519, FROSTLASS over CLSAG)"]
+    end
+
+    subgraph Execution["LEZ execution"]
+        direction TB
+        AMM["AMM pools<br/>(xy=k, native-asset settlement)"]
+        Privacy["Privacy layer:<br/>- shielded swap intents<br/>- sealed-bid batch matching<br/>- stealth outbound addresses<br/>- Waku transport for orderflow"]
+        AMM --- Privacy
+    end
+
+    Validators -->|"co-sign deposits/outbounds"| Vaults
+    Vaults -->|"observed deposits feed swap engine"| Execution
+    Execution -->|"queued outbounds signed via TSS"| Vaults
+```
+
+**Happy path.** User sends BTC to a vault address on Bitcoin, carrying a memo
+(or, with LEZ privacy primitives, a commitment) that specifies the destination
+asset and address. LEZ validators observe the deposit, reach consensus via their
+consensus protocol, route the swap through the appropriate AMM pool, queue the
+outbound, and the threshold signature group co-signs an outbound transaction on
+the destination chain. Outbound is broadcast to a stealth address derived from
+the destination address. Total wall-clock time: source-chain finality plus LEZ
+consensus plus destination-chain finality, typically minutes.
+
+**Validator-set churn.** On a fixed cadence, the protocol runs a distributed key
+generation for the next validator set and migrates vault balances from old keys
+to new keys. New validators bond their stake; departing validators recover their
+bond after a vesting period.
+
+**Misbehaviour path.** Failed keygen, failed keysign, observed double-spend
+attempts, or chain-attributable malfeasance trigger slashing of the responsible
+validator's bond. Slashing amounts and trigger conditions are protocol-defined.
+
+**Emergency path.** A `halt` mechanism (Thorchain's `make halt` precedent; Serai
+uses session-level rollback during DKG failure) freezes outbounds on suspected
+solvency or signing failure.
+
+## Pros
+
+- **Highest deployed-volume model.** Thorchain has cleared over $120B cumulative
+  cross-chain volume since 2021
+  ([DefiLlama Thorchain DEX](https://defillama.com/protocol/thorchain-dex),
+  accessed 2026-05-21). The AMM-style middle-chain pattern wins on liquidity
+  gravity and user experience over every atomic-swap competitor.
+- **Sub-block-time settlement on the middle chain.** Only destination-chain
+  finality and the TSS keysign delay the outbound. No multi-hour timelock
+  windows.
+- **Arbitrary asset pairs.** Pair coverage is reduced to "does the validator set
+  run an observer for chain X". BTC, ETH, XMR all in scope at launch.
+- **Cryptoeconomic recourse.** Misbehaviour is slashable. The economic security
+  argument is explicit and bounded.
+- **LEZ privacy execution is a real differentiator.** No comparator offers
+  shielded swap intents, sealed-bid batch matching, or stealth outbound
+  addresses. This is the precise gap LEZ can fill.
+- **Composable with the rest of LEZ.** The protocol-owned vault assets can back
+  lending markets, structured products, and so on, on the same LEZ.
+
+## Cons
+
+- **Custody risk is real and realised.** Thorchain's GG20 TSS vault was drained
+  on 2026-05-15 ($10.8M) via a TSSHOCK-class implementation weakness. Wormhole's
+  Solana bridge was drained on 2022-02-02 ($326M) via a per-chain contract bug
+  (`load_instruction_at`); Jump Crypto re-deposited the loss out of pocket. The
+  federated middle-chain pattern has a non-zero historical loss rate.
+- **Signer federation is a chokepoint.** Validators are identifiable; the
+  validator set is a target for out-of-protocol pressure (legal, regulatory,
+  kinetic). The federation cannot be made "fully decentralised" in the sense
+  that an atomic-swap design can.
+- **Pre-economic-security bootstrap.** Serai's mint-on-bootstrap design
+  illustrates that the slashable-bond argument does not bind until the
+  validator-stake pool catches up with custody. The launch window is a real
+  risk.
+- **XMR privacy compromise.** Any TSS custody of Monero is necessarily
+  view-key-shared: the validator set learns the LEZ-side Monero deposit history.
+  This is the same compromise Serai accepts (FROSTLASS over CLSAG); it must be
+  called out plainly to users, not papered over.
+- **Engineering surface is large.** Building a new chain, a per-external-chain
+  observer fleet, a TSS scheme with serious audit posture, churn/migration
+  logic, and an emergency halt is a multi-year programme. Serai took roughly
+  five years from inception (around 2021) to post-cryptographic-audit
+  pre-mainnet status (Cypher Stack audits completed May 2025; mainnet not yet
+  launched as of 2026-05-21).
+
+## Risks
+
+- **TSS implementation failure.** The 2026-05-15 Thorchain incident is the
+  canonical example. Mitigation: choose FROST over GG20 (Serai's choice, and the
+  lesson Thorchain's incident reinforces); budget for at least one Cypher
+  Stack-equivalent audit of the chosen scheme; design with FROSTLASS-grade
+  Monero support from the start rather than retrofitting.
+- **Per-external-chain contract risk.** Wormhole's 2022 incident bypassed rather
+  than broke the trust model: a Solana-side `load_instruction_at` bug let an
+  attacker forge VAAs. Every integrated chain adds an attack surface independent
+  of the LEZ consensus. Mitigation: minimise per-chain on-chain components; lean
+  on TSS-signed outputs to chains with no LEZ-deployed contract.
+- **Validator-set capture.** A small or homogeneous validator set is a
+  censorship and coercion target. Mitigation: stake-weighted permissionless
+  entry; geographic and jurisdictional diversity as a soft target.
+- **Pre-mainnet economic-security gap.** Slashable-bond security depends on
+  stake value catching up with custody value. Mitigation: explicit caps on
+  custody until the bond-to-custodied ratio binds; transparent on-protocol ratio
+  enforcement (Thorchain's Incentive Pendulum is one mechanism).
+- **Regulatory exposure on XMR custody.** Holding XMR in a protocol-owned vault
+  attracts more scrutiny than holding BTC. Mitigation: validator geographic
+  diversity; documented privacy posture; clear separation between protocol
+  governance and individual validator entities.
+- **Privacy claim overreach.** The LEZ privacy primitives close the
+  public-ledger linkability gap but do not protect against an honest-but-curious
+  validator set. The threat model must be documented honestly so users do not
+  assume "private" means "the validators learn nothing".
+
+## Relationship to other RFPs in this bundle
+
+- **RFP-003 (Atomic Swaps with LEZ, open)** is the structural alternative:
+  bilateral atomic swap instead of federated middle layer. The two coexist:
+  RFP-021 handles the high-liquidity bulk path with AMM-style liquidity; RFP-003
+  covers the non-custodial niche with multi-hour settlement and counterparty
+  interactivity. RFP-003's known economic gaps (taker spam, free-option
+  exploitation, off-chain maker reputation) are addressed by lambda prizes
+  LP-0018 and LP-0019; RFP-021 sidesteps those problems by design.
+- **RFP-004 (Privacy-Preserving DEX, open)** is a *single-chain* shielded DEX on
+  LEZ. RFP-021 is *cross-chain* with vault custody. Distinct scopes; the two
+  could ship in parallel and serve different user journeys (intra-LEZ shielded
+  trading vs cross-chain settlement).
+- **RFP-024 (CDP-backed synthetics)**, **RFP-025 (real-XMR multisig)**, and
+  **RFP-026 (synthetic atomic-swap redemption)** target a different product:
+  synthetic-asset exposure inside LEZ DeFi (with XMR as the motivating case).
+  They are orthogonal to RFP-021 and could ship alongside it, sharing the same
+  LEZ privacy primitives. RFP-025 shares the federated-signer custody pattern
+  with RFP-021 and could share signer-set infrastructure.
+
+See
+[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md)
+for the full federated-signers vs atomic-swaps trust analysis that motivates
+this RFP's place in the bundle.
+
+## References
+
+- [DefiLlama Thorchain DEX (volume figures)](https://defillama.com/protocol/thorchain-dex)
+  (accessed 2026-05-21)
+- [Serai AMM docs](https://docs.serai.exchange/amm/) (accessed 2026-05-21)
+- [Serai blog: Announcing monero-oxide (2025-09-09)](https://serai.exchange/2025/09/09/monero-serai-oxide.html)
+  (accessed 2026-05-21)
+- [Serai Validator Sets spec](https://github.com/serai-dex/serai/blob/develop/spec/protocol/Validator%20Sets.md)
+  (accessed 2026-05-21)
+- [Serai blog: How Far We've Come (2023-10-06)](https://serai.exchange/2023/10/06/how-far-weve-come.html)
+  (accessed 2026-05-21)
+- [Thorchain Medium: Why Cross-Chain bridges are superior to Atomic Swaps (2019)](https://medium.com/thorchain/why-cross-chain-bridges-are-superior-to-atomic-swaps-aebde263103c)
+  (accessed 2026-05-21)
+- [Thorchain docs: Continuous Liquidity Pools](https://docs.thorchain.org/technical-documentation/thorchain-finance/continuous-liquidity-pools)
+  (accessed 2026-05-21)
+- [Thorchain docs: RUNE (bond-to-pooled ratio)](https://docs.thorchain.org/understanding-thorchain/rune)
+  (accessed 2026-05-21)
+- [Crypto Times: $10.8M drained from Thorchain on 2026-05-15](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/)
+  (accessed 2026-05-21)
+- [Halborn: Wormhole Hack February 2022](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022)
+  (accessed 2026-05-21)
+- [FROST: Flexible Round-Optimized Schnorr Threshold Signatures (Komlo and Goldberg, SAC 2020 / IACR 2020/852)](https://eprint.iacr.org/2020/852)
+  (accessed 2026-05-21)
diff --git a/RFPs/RFP-024-cdp-backed-synthetic.md b/RFPs/RFP-024-cdp-backed-synthetic.md
new file mode 100644
index 0000000..5791c67
--- /dev/null
+++ b/RFPs/RFP-024-cdp-backed-synthetic.md
@@ -0,0 +1,232 @@
+---
+id: RFP-024
+title: CDP-Backed Synthetic Assets (sASSET) for Any Oracle-Priced Asset
+tier: XL
+funding: $TBD
+status: draft
+category: Applications & Integrations
+---
+
+# RFP-024 — CDP-Backed Synthetic Assets (sASSET)
+
+> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos
+> team and the community compare cross-chain DEX designs across RFP-021,
+> RFP-024, RFP-025, and RFP-026. Hard requirements, FURPS detail, team profile,
+> timeline, and contracting details are deliberately omitted; they will be
+> filled in if the design is selected for funding.
+
+## 🧭 Overview
+
+Build a CDP-backed synthetic-asset facility on LEZ that can mint a synthetic
+token (sASSET) tracking the price of *any oracle-priced asset* — `sXMR`, `sZEC`,
+`sBTC`, `sETH`, and so on. Users mint sASSET by locking stable collateral (or
+other governance-approved LEZ assets) into a CDP-style vault, similar to the
+Synthetix V3 Pools mechanic (SIP-302). Users burn sASSET to recover their
+collateral. The protocol holds none of the tracked asset at any point and does
+not deposit it on the asset's home chain — sASSET is a *debt instrument against
+stable collateral*, not a wrapped asset.
+
+The mint/burn/liquidate machinery is identical regardless of which asset is
+tracked; the only per-asset input is the oracle price feed. Adding a new
+synthetic (e.g. going from `sXMR` to `sZEC`) is a matter of wiring up a
+documented oracle for the new asset and setting that synthetic's risk
+parameters, not re-engineering the vault. This is exactly the property Synthetix
+exploited to list `sUSD`, `sETH`, `sBTC`, `sXMR`, `sBCH`, `sADA`, and others off
+a single CDP-minting engine.
+
+Inspired by **Synthetix CDP minting** (SIP-302 Pools V3). A directly relevant
+deployed analogue is Synthetix's own historical sXMR ERC-20 (Hadar release,
+2020-03-30), which was SNX-collateralised and oracle-priced via Chainlink, never
+redeemable for real XMR — one of a whole family of oracle-priced synths off the
+same engine. See
+[appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md)
+§Oracle-priced over-collateralised synthetics.
+
+This is the preferred synthetic design in the bundle. For privacy-coin
+underlyings such as XMR, RFP-025 (real-asset multisig) carries custody risk and
+a deposit-history leak; RFP-026 layers atomic-swap redemption on top of this RFP
+for users who want to exit to the real asset on its home chain (but does not
+change the CDP mint mechanic).
+
+## Which assets fit this design
+
+Any asset for which a usable price oracle exists can be minted as a CDP-backed
+synthetic here. The asset's own chain capabilities are irrelevant to *minting* —
+the vault only ever holds LEZ-side collateral. Lead examples:
+
+- **`sXMR` (Monero).** The bundle's primary motivating case: privacy-coin
+  exposure inside LEZ DeFi with no XMR custody. Monero has no smart contracts and
+  no SPV proof, but none of that matters to a CDP synthetic because the protocol
+  never touches XMR.
+- **`sZEC` (Zcash).** Same privacy-coin story as XMR; oracle-priced shielded-asset
+  exposure without custodying ZEC.
+- **`sBTC` (Bitcoin).** Synthetic BTC exposure inside LEZ without a federation
+  custodying BTC (contrast Stacks sBTC, which is custody-backed — see the
+  appendix).
+- **`sETH` (Ethereum).** Synthetic ETH exposure; a liquid, well-oracled asset
+  that is a natural low-risk first listing to validate the engine before adding
+  thinner-oracle assets.
+
+What *does* vary per asset is risk configuration, not mechanism: oracle quality
+and redundancy, price volatility (which drives the c-ratio and liquidation
+parameters), and whether a robust enough price feed exists at all. Thinly-traded
+or poorly-oracled assets are out of scope until a defensible oracle exists for
+them. Applicants should treat "is there a manipulation-resistant oracle for this
+asset?" as the gating question for each listing.
+
+## High-level functionality and flow
+
+```mermaid
+flowchart LR
+    User[User] -- deposit stable collateral --> Vault[sASSET CDP vault on LEZ]
+    Vault -- mint sASSET at oracle price --> User
+    Oracle[ASSET/USD oracle] -- price feed --> Vault
+    User -- burn sASSET + interest --> Vault
+    Vault -- release collateral --> User
+    Liq[Liquidation keeper] -- liquidate undercollateralised vault --> Vault
+```
+
+- **Mint.** A user deposits stable collateral (or other governance-approved LEZ
+  assets) into the sASSET vault on LEZ. The protocol mints sASSET at the current
+  oracle price for the tracked asset, up to a configurable issuance ratio
+  (minimum c-ratio). The user holds sASSET; the vault holds the collateral.
+- **Burn / unwind.** The user repays sASSET (plus any interest/fees) and the
+  vault releases the collateral.
+- **Liquidation.** If the vault's c-ratio breaches the threshold (oracle price
+  moves against the user), a liquidation keeper closes the position and returns
+  surplus collateral to the user, less penalty.
+- **Trading.** sASSET is a vanilla LEZ token; users trade it against stables on
+  RFP-004 or any other LEZ DEX. The price tracks oracle within whatever spread
+  the market clears.
+
+There is **no atomic swap and no custody of the tracked asset in this RFP**. A
+user who wants the real asset on its home chain (real XMR on Monero L1, real BTC
+on Bitcoin, etc.) either sells sASSET on a DEX (and takes the spread), or uses
+RFP-026 (atomic-swap redemption built on top of this RFP) once that ships and
+the relevant chain's atomic-swap support exists.
+
+## Pros
+
+- **Strongest non-custody story.** The protocol never touches the tracked asset;
+  the vault holds only LEZ-side stable collateral. No signer set, no multisig, no
+  bridge, no deposit-history leak — true for `sXMR`, `sBTC`, `sZEC`, and any
+  other listing alike.
+- **One engine, many assets.** A single audited CDP facility supports an open set
+  of synthetics. New listings cost an oracle integration and a risk-parameter
+  review, not a new protocol. This is the principal reason to prefer the CDP
+  design over per-asset custody bridges.
+- **Composable from day one.** sASSET is a vanilla LEZ token; lending markets,
+  DEXes, governance, structured products can integrate without coordinating with
+  the synthetics team.
+- **Regulatory defensibility highest in the bundle.** The protocol is, in
+  defensible terms, a price feed plus a collateral vault. Operators of price
+  feeds have meaningfully different exposure from operators of asset-custodying
+  bridges.
+- **Independent of atomic-swap UX issues.** Mint and burn are LEZ-native
+  operations; there is no atomic-swap latency, no maker discovery, no
+  counterparty interactivity required for the core product.
+- **Lowest engineering cost in the bundle's synthetics line.** Existing CDP
+  designs (Synthetix, MakerDAO, Liquity) provide a well-mapped implementation
+  template; the work is adapting those patterns to LEZ.
+- **Builders are not blocked on LP-0018 or LP-0019.** Atomic-swap-specific
+  concerns (taker spam, maker reliability) do not apply to the CDP mint path;
+  those issues affect RFP-026 only.
+
+## Cons
+
+- **No path to the real asset within this RFP.** A user who wants the underlying
+  on its home chain must either accept the secondary-market discount (sell
+  sASSET for stables, buy the asset off-platform) or wait for RFP-026 to ship for
+  that asset and use it. The "synthetic" is genuinely synthetic: no
+  underlying-asset redemption.
+- **Soft peg only.** sASSET tracks oracle within whatever spread the secondary
+  market clears. Under stress (oracle staleness, collateral crunch, panicked
+  unwinds) the peg can widen meaningfully.
+- **Debt pool socialisation considerations.** In a V2-style debt pool, all
+  synth holders share aggregate Synth debt; in V3-style per-pool debt, the same
+  accounting model applies within a pool. Applicants must pick a model and
+  document its failure modes. With multiple synthetics off one engine, the debt
+  pool spans all of them — a sharp move in one asset's oracle is felt by holders
+  of the shared pool.
+- **Per-asset oracle quality varies.** The engine is asset-agnostic but its
+  safety is not: a liquid asset like ETH has deep, redundant oracles, while a
+  thinner privacy coin may have fewer independent feeds and worse manipulation
+  resistance. Each listing inherits the strength (or weakness) of its oracle.
+- **Privacy is partial.** sASSET is *not* a private asset on LEZ on its own; the
+  token program is public state. Privacy must come from LEZ-native shielding
+  (RFP-004's shielded swap intents, deshield-swap-reshield patterns). The CDP
+  vault and the mint/burn flow are public. (For non-privacy underlyings like ETH
+  or BTC this is a non-issue; it matters for the `sXMR`/`sZEC` privacy-coin case.)
+- **Open question: does Logos want a synthetic that does not redeem to the
+  underlying?** Synthetix-style synths have proven they can sustain liquidity for
+  major asset classes (sUSD, sETH) but Synthetix's privacy-coin listing (sXMR)
+  itself never achieved meaningful volume. An audience that specifically wants the
+  real asset may not be satisfied by a debt instrument that merely tracks it.
+
+## Risks
+
+- **Oracle manipulation.** A manipulated ASSET/USD oracle lets an attacker mint
+  sASSET cheaply or under-collateralise existing positions. Mitigation: redundant
+  oracle stack with median-of-N pricing; configurable price-deviation guards;
+  oracle-staleness checks. This risk scales inversely with the asset's oracle
+  depth, so per-listing oracle review is mandatory.
+- **Collateral solvency.** If the collateral asset (stables) depegs or is
+  compromised, sASSET backing degrades. Mitigation: accept only collateral with
+  documented threat models; cap protocol-wide collateral concentration by asset;
+  require liquidation parameters that hold under collateral-asset volatility.
+- **Liquidation infrastructure under-built.** A CDP design that does not have
+  working keeper bots and a profitable liquidation incentive will hit insolvency
+  on the first market shock. Mitigation: design liquidation incentives carefully;
+  budget engineering for keeper operations; document MEV considerations.
+- **Demand asymmetry.** Mint demand may be easy (LEZ-DeFi users want exposure to
+  the tracked asset inside LEZ) but secondary-market liquidity for that synthetic
+  may not materialise. The CDP design absorbs this — there is no LP bottleneck —
+  but the token's tradability is bottlenecked by LEZ DEX adoption.
+- **Privacy-claim overreach (privacy-coin listings).** sASSET is not a private
+  asset; for `sXMR`/`sZEC` the privacy property is only that *the underlying
+  asset is private*. Mint/burn on LEZ is public. Documentation must be honest.
+- **Synthetix-sXMR precedent.** Synthetix listed sXMR in 2020 and it did not
+  achieve meaningful adoption, even though its sUSD/sETH synths did. Mitigation:
+  LEZ-native privacy positioning and tight LEZ-DeFi integration may differentiate
+  privacy-coin listings, but applicants should validate demand per asset before
+  building.
+
+## Relationship to other RFPs in this bundle
+
+- **RFP-003 (Atomic Swaps with LEZ, open)** is not a dependency of this RFP.
+  RFP-024 is a CDP design that does not interact with atomic swaps. RFP-026
+  layers atomic-swap redemption on top of this RFP for assets that have
+  atomic-swap support.
+- **RFP-021 (cross-chain privacy DEX)** is the federated-custody alternative for
+  real-asset exposure. Orthogonal product: RFP-024 gives synthetic exposure
+  inside LEZ DeFi without custody; RFP-021 gives the real asset via a federated
+  middle layer.
+- **RFP-025 (real-asset locked in trusted multisig)** is the not-preferred
+  custody-backed alternative, scoped specifically to XMR. The two RFPs target the
+  same audience differently *for the XMR case*: RFP-024 says "we don't custody the
+  asset"; RFP-025 says "we do, via a federated multisig". RFP-024 is preferred.
+- **RFP-026 (atomic-swap redemption to the real asset)** strictly extends this
+  RFP. RFP-024 ships first; RFP-026 adds an atomic-swap exit path for users who
+  want to redeem to the asset's home chain (for any asset where atomic-swap
+  support exists). RFP-026 does not re-spec the CDP mint mechanic.
+- **RFP-004 (Privacy-Preserving DEX)** is the natural single-chain trading venue
+  for sASSET. Trade sASSET against stables on RFP-004's AMM pools under the
+  shield/deshield pattern.
+- **LP-0018 and LP-0019** are atomic-swap-specific prizes; they affect RFP-026
+  only.
+
+See
+[appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md)
+for the deployed-synthetics taxonomy and the Synthetix CDP minting reference.
+
+## References
+
+- [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md)
+- [appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md)
+- [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md)
+- [Synthetix SIP-302 (Pools V3)](https://sips.synthetix.io/sips/sip-302)
+  (accessed 2026-05-22) — canonical CDP-minting reference, with direct relevance
+  to the sASSET design.
+- [Synthetix blog: Hadar release (sXMR ERC-20 and sibling oracle-priced synths, 2020-03-30)](https://blog.synthetix.io/new-synths-update-for-the-upcoming-hadar-release/)
+  (accessed 2026-05-22) — historical example of many oracle-priced synths off one
+  CDP engine.
diff --git a/RFPs/RFP-025-synthetic-xmr-sla.md b/RFPs/RFP-025-synthetic-xmr-sla.md
new file mode 100644
index 0000000..4e20088
--- /dev/null
+++ b/RFPs/RFP-025-synthetic-xmr-sla.md
@@ -0,0 +1,201 @@
+---
+id: RFP-025
+title: Synthetic XMR (sXMR) — Real XMR in Threshold-Signer Multisig
+tier: XL
+funding: $TBD
+status: draft
+category: Applications & Integrations
+---
+
+# RFP-025 — Synthetic XMR (sXMR) Backed by Real XMR in Trusted Multisig
+
+> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos
+> team and the community compare cross-chain DEX designs across RFP-021,
+> RFP-024, RFP-025, and RFP-026. Hard requirements, FURPS detail, team profile,
+> timeline, and contracting details are deliberately omitted; they will be
+> filled in if the design is selected for funding.
+>
+> **The Logos team's current preference is RFP-024 (CDP-backed synthetic) over
+> this design.** RFP-025 is documented here so the design space is comparable,
+> but the custody and privacy trade-offs (below) make it the less attractive
+> option. Read this RFP as "what would it take to do sXMR the sBTC way?" — not
+> as "the Logos plan".
+
+## 🧭 Overview
+
+Build a synthetic XMR token (sXMR) on LEZ backed 1:1 by real XMR held in a
+threshold-signer multisig on Monero. Users mint sXMR by depositing XMR into the
+protocol's Monero-side multisig; users redeem sXMR by burning the LEZ-side token
+to trigger a multisig-signed Monero spend back to the user. The token is a
+*wrapped representation* of custodied XMR, not a debt instrument against stable
+collateral.
+
+Inspired by **sBTC (Stacks)** and **Secret Network's Secret Monero Bridge**. See
+[appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md)
+§Redeem-to-underlying with custody for both reference projects. The TSS custody
+for the Monero side follows Serai's FROST-over-CLSAG approach to avoid the
+GG20/TSSHOCK class of failures (see
+[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md)
+§Federated-signer middle chain). The custody trust model is the same trust class
+as RFP-021.
+
+This design is **not the Logos team's preferred sXMR design** (RFP-024 is). The
+custody risk and Monero deposit-history leak (both documented below) are real
+and material. RFP-025 exists in the bundle as the deployed-prior-art comparison
+point and as the design choice if real-XMR backing turns out to be a hard
+product requirement.
+
+## High-level functionality and flow
+
+```mermaid
+flowchart LR
+    User[User] -- deposit XMR on Monero --> MS[Threshold-signer multisig on Monero]
+    MS -- mint signal --> LEZ[sXMR LEZ program]
+    LEZ -- mint sXMR --> User
+    User -- burn sXMR + redemption request --> LEZ
+    LEZ -- spend signal --> MS
+    MS -- sign Monero spend --> Out[XMR back to user on Monero]
+```
+
+- **Mint.** A user sends XMR to the protocol's Monero-side multisig with a memo
+  identifying the user's LEZ destination address. The signer set observes the
+  deposit, reaches consensus, and the LEZ sXMR program mints 1:1 sXMR to the
+  destination.
+- **Burn / redeem.** A user burns sXMR on LEZ with a Monero destination address.
+  The signer set observes the burn, reaches threshold, and signs a Monero spend
+  from the multisig to the user's address.
+- **Custody.** The protocol holds real XMR in a threshold-signer multisig
+  (FROST-over-CLSAG; per-coin threshold suitable for Monero). The signer set is
+  bonded and slashable; signer bond size scales with custody value.
+- **Governance.** Signer set composition, threshold, bond requirements, and
+  slashing rules are protocol-governed.
+
+The atomic-swap protocol is *not* used in this RFP. Mint and redemption are
+direct interactions with the multisig.
+
+## Pros
+
+- **Real XMR redemption with a documented SLA shape.** Unlike RFP-024 (no
+  redemption to the real asset) and unlike RFP-026 (best-effort matching, no
+  guarantees), this
+  design lets a user mint and redeem on demand, bounded by the signer-set
+  responsiveness.
+- **Hard peg within reserve capacity.** sXMR is 1:1 backed by real XMR; oracle
+  is not load-bearing (no oracle needed for the peg itself, only for any
+  auxiliary pricing).
+- **Composable from day one.** sXMR is a vanilla LEZ token; lending, DEXes,
+  governance, structured products can integrate.
+- **Audience overlap with sBTC and Secret Monero Bridge.** Users who already
+  accept federated-custody designs on Stacks/Secret will find the trust model
+  familiar.
+
+## Cons
+
+- **Custody risk is real and historically realised.** A signer set holding real
+  XMR is a target. Thorchain's 2026-05-15 GG20/TSSHOCK exploit drained $10.8M
+  from a similar architecture. Wormhole's 2022 Solana-side bug drained $326M.
+  sBTC's signer set is 15 entities and has not been exploited at time of
+  writing, but the failure-mode category is well-documented.
+- **View-key-shared custody leaks Monero deposit history to signers.** Threshold
+  custody of XMR requires view-key sharing among signers. Honest-but-curious
+  signers learn the protocol-side mint and burn flow. This is the same
+  compromise RFP-021 accepts; it is the structural cost of TSS custody of XMR
+  under current Monero cryptography.
+- **Signer-set bootstrap problem.** Bonded-security guarantees do not bind until
+  the signer-set stake catches up with custody value. Early in the protocol's
+  life the bond-to-custody ratio is unfavourable; the protocol is at its weakest
+  precisely when its custody is smallest.
+- **Signer-set censorship and coercion vector.** Identifiable signers are a
+  chokepoint for legal, regulatory, and out-of-protocol pressure. The federation
+  cannot be made "fully decentralised" the way an atomic-swap design (RFP-026)
+  can be.
+- **Redemption SLA depends on signer liveness.** If the signer set cannot reach
+  threshold to sign (network partition, mass offline event), redemption breaks
+  even with no malice.
+- **Reinvents sBTC for a privacy-coin underlying.** The novelty relative to sBTC
+  is the LEZ privacy execution on the sXMR token side, not the custody model.
+  The custody side carries familiar risks; the LEZ side cannot compensate for
+  them.
+- **Privacy-claim overreach.** sXMR on LEZ is private only insofar as LEZ-native
+  shielding makes it so. The protocol-side Monero deposit/redemption flow is
+  visible to signers and leaks the underlying-asset graph; users may misread
+  "sXMR is private" as "the protocol does not see my XMR activity".
+- **Why this RFP is not preferred.** The custody and view-key disclosure issues
+  above mean RFP-025 reintroduces exactly the trust assumptions that RFP-024
+  deliberately avoids. The Logos team's working assumption is that LEZ users
+  prefer the synthetic-with-no-custody trade-off (RFP-024) over the
+  wrapped-with-custody trade-off (this RFP).
+
+## Risks
+
+- **Signer-set compromise.** A captured signer set can drain the entire reserve.
+  Mitigation: large signer set (Serai uses up to 600; Thorchain ~100);
+  permissionless entry once bootstrapped; high bond-to-custodied ratio;
+  emergency-halt mechanism; geographic and jurisdictional diversity.
+- **TSS implementation bug.** Thorchain's GG20 TSS exploit on 2026-05-15
+  ($10.8M) is the canonical example. Mitigation: choose FROST over GG20 for the
+  Monero side; budget for Cypher-Stack-equivalent audit; isolate signer-software
+  dependencies; track Serai's monero-oxide work as the production-grade
+  FROSTLASS instantiation.
+- **Signer-set offline event.** If the signer set cannot reach threshold
+  (network partition, mass node failure), redemption SLA breaks even with no
+  malice. Mitigation: redundant signer geographic placement; documented signer
+  SLOs; emergency-halt mechanism that pauses redemption gracefully.
+- **Bond denomination volatility.** If signer bonds are denominated in
+  LEZ-native assets that depeg or are volatile, bond-to-custodied ratio drifts.
+  Mitigation: cap bond-asset concentration; require signers to top up on
+  bond-asset depeg.
+- **Regulatory exposure on XMR custody.** A protocol that custodies real XMR
+  draws more scrutiny than RFP-024's CDP design or RFP-026's
+  peer-to-peer-atomic-swap design. Mitigation: signer-set jurisdictional
+  diversity; documented compliance posture; willingness to operate as a
+  permissionless smart contract regardless of any single jurisdiction's stance.
+- **Reserve undercollateralisation.** If the reserve is drawn down faster than
+  it can be replenished from fees or governance top-ups, redemption capacity
+  goes to zero; sXMR loses its peg.
+
+## Relationship to other RFPs in this bundle
+
+- **RFP-024 (CDP-backed synthetics)** is the preferred alternative. Applied to
+  XMR, RFP-024 says "we don't custody XMR, sXMR is a debt instrument against
+  stable collateral"; this RFP says "we do custody XMR via a federated multisig".
+  The two are mutually exclusive product directions, not layered.
+- **RFP-026 (synthetic atomic-swap redemption to the real asset)** is the
+  non-custodial alternative for delivering real XMR to users. RFP-026 builds on
+  RFP-024 and uses atomic swaps; RFP-025 holds real XMR in a multisig. RFP-026
+  has best-effort SLA; RFP-025 has hard-peg-within-reserve.
+- **RFP-021 (cross-chain privacy DEX)** shares the federated-signer trust model.
+  The two RFPs could share signer-set infrastructure if both are funded (same
+  FROST-over-CLSAG primitives, possibly same validator set), trading some
+  signer-set economies of scale.
+- **RFP-003 (Atomic Swaps with LEZ, open)** is not used by this RFP. Mint and
+  redemption are direct multisig interactions, not atomic swaps.
+- **LP-0018 and LP-0019** do not apply to this RFP. They address
+  atomic-swap-specific concerns; this RFP has no atomic-swap leg.
+
+See
+[appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md)
+§Redeem-to-underlying with custody for the deployed prior art (sBTC, Secret
+Monero Bridge) and
+[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md)
+for the federated-signer trust analysis.
+
+## References
+
+- [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md)
+- [appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md)
+- [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md)
+- [docs.stacks.co/concepts/sbtc](https://docs.stacks.co/concepts/sbtc) (accessed
+  2026-05-22) — sBTC is a 1:1 BTC-backed asset on Stacks; custody is a 15-signer
+  federation with 70% threshold (current operating set 14 signers, 10-of-14 to
+  sign); withdrawal latency ~6 Bitcoin blocks.
+- [Hiro: Who are the sBTC signers, breaking down SIP-028](https://www.hiro.so/blog/who-are-the-sbtc-signers-breaking-down-sip-028)
+  (accessed 2026-05-22)
+- [Crypto Times: $10.8M drained from Thorchain on 2026-05-15](https://www.cryptotimes.io/2026/05/17/10-8-million-drained-inside-the-thorchain-exploit-that-froze-cross-chain-defi-for-13-hours/)
+  (accessed 2026-05-19)
+- [Halborn: Wormhole Hack on 2022-02-02 (technical analysis)](https://www.halborn.com/blog/post/explained-the-wormhole-hack-february-2022)
+  (accessed 2026-05-19)
+- [FROST: Flexible Round-Optimized Schnorr Threshold Signatures (Komlo and Goldberg, SAC 2020 / IACR 2020/852)](https://eprint.iacr.org/2020/852)
+  (accessed 2026-05-21)
+- [Announcing monero-oxide / FROSTLASS over CLSAG (Serai, 2025-09-09)](https://serai.exchange/2025/09/09/monero-serai-oxide.html)
+  (accessed 2026-05-19) — production-grade reference for Monero TSS custody.
diff --git a/RFPs/RFP-026-synthetic-atomic-swap-redemption.md b/RFPs/RFP-026-synthetic-atomic-swap-redemption.md
new file mode 100644
index 0000000..f63db5b
--- /dev/null
+++ b/RFPs/RFP-026-synthetic-atomic-swap-redemption.md
@@ -0,0 +1,246 @@
+---
+id: RFP-026
+title: Synthetic Atomic-Swap Redemption (extends RFP-024)
+tier: L
+funding: $TBD
+status: draft
+category: Applications & Integrations
+---
+
+# RFP-026 — Atomic-Swap Redemption of Synthetics to the Real Asset
+
+> **Note:** This RFP is a *decision-stage draft*. It exists to help the Logos
+> team and the community compare cross-chain DEX designs across RFP-021,
+> RFP-024, RFP-025, and RFP-026. Hard requirements, FURPS detail, team profile,
+> timeline, and contracting details are deliberately omitted; they will be
+> filled in if the design is selected for funding.
+>
+> **This RFP strictly extends RFP-024.** RFP-024 (CDP-backed sASSET) is a hard
+> prerequisite. RFP-026 adds an atomic-swap-based redemption path so that sASSET
+> holders can exit to the real underlying asset on its home chain, without the
+> protocol ever holding that asset. It does not re-specify the CDP mint mechanic.
+
+## 🧭 Overview
+
+Add a peer-to-peer atomic-swap redemption module on top of RFP-024's CDP-backed
+synthetics. A holder of any sASSET (`sXMR`, `sZEC`, `sBTC`, `sETH`, …) who wants
+to receive the real underlying asset on its home chain can post a redemption
+intent over Logos Delivery; any holder of that real asset (an "LP") can quote and
+counterparty the redemption via an atomic swap using the RFP-003 LEZ↔asset SDK.
+On success, the user's sASSET is burned on LEZ, the LP receives the unlocked
+stable collateral, and the user receives the real asset on its home chain.
+
+The protocol holds none of the real asset at any step. There is no LP registry,
+no bond, no SLA. Anyone holding the asset can quote. Spreads widen under stress
+without bound; redemption availability is whatever the LP market clears. This is
+the *non-custodial real-asset exit path* for RFP-024's CDP synthetics. Builders
+who want a guaranteed redemption SLA backed by federated custody should look at
+RFP-025 instead.
+
+Inspired by **eigenwallet/COMIT BTC-XMR atomic swap** for the redemption-leg
+cryptography. See
+[appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) for the
+underlying protocol mechanics and the locking-order protocol constraint.
+
+## Which assets fit this design
+
+Redemption works for an asset only when **both** conditions hold:
+
+1. **A CDP synthetic for it exists** (RFP-024 lists `sASSET` for that asset —
+   gated by the existence of a usable oracle), **and**
+2. **Atomic-swap support for that asset's home chain exists** in the RFP-003
+   LEZ↔asset SDK.
+
+The redeemable set is the *intersection* of those two. Oracle availability (the
+RFP-024 gate) is the looser constraint; atomic-swap support is the tighter one,
+because it depends on the asset's chain providing the cryptographic primitives
+the swap protocol needs (adaptor signatures / scriptless-script locking, or
+equivalent), and on the RFP-003 SDK having been built and audited for that pair.
+Lead examples, in rough order of atomic-swap readiness:
+
+- **`sBTC` → BTC.** Bitcoin has the most mature atomic-swap tooling (the original
+  BTC-XMR swap was built around Bitcoin's scripting). The least exotic redemption
+  leg.
+- **`sXMR` → XMR.** The bundle's motivating case. The eigenwallet/COMIT BTC-XMR
+  protocol is the reference; the LEZ↔XMR leg must be built in RFP-003. The Monero
+  side carries the locking-order constraint described below.
+- **`sZEC` → ZEC.** Shielded-asset redemption; viable in principle, dependent on
+  the LEZ↔ZEC swap leg existing in RFP-003. Shielded-pool interaction adds
+  protocol work on the swap side.
+- **`sETH` → ETH.** Mechanically the simplest swap counterparty (rich scripting),
+  though the demand case is weakest — ETH holders rarely need a non-custodial exit
+  from a synthetic. Listed mainly to show the design is not privacy-coin-specific.
+
+An asset that has a CDP synthetic (RFP-024) but **no** atomic-swap support is
+*not* redeemable via this RFP; its holders are limited to RFP-024's
+sell-on-a-DEX exit until the swap leg is built. Applicants should treat "is there
+an audited LEZ↔asset atomic-swap leg?" as the gating question per asset, the same
+way RFP-024 treats the oracle question.
+
+## High-level functionality and flow
+
+```mermaid
+flowchart LR
+    User[sASSET holder] -- redemption intent --> LD[Logos Delivery]
+    LP[Open asset LP] -- quote --> LD
+    User -- accept quote --> LP
+    User -- lock sASSET vault on LEZ + atomic-swap setup --> LEZ[LEZ atomic-swap escrow]
+    LP -- lock asset on home chain --> Home[Asset home chain]
+    User -- reveal secret --> LEZ
+    LP -- claim sASSET collateral, burn sASSET --> LEZ
+    Home -- real asset to user's address --> UserExit[User on asset home chain]
+```
+
+Step-by-step (worked with XMR as the example; substitute the asset and its home
+chain for other listings):
+
+1. The sASSET holder publishes a redemption intent (notional, oracle price,
+   deadline) over Logos Delivery.
+2. Any open-set LP holding the real asset sees the intent, computes their quote
+   (oracle ± spread), and replies bilaterally over Logos Delivery / Logos Chat.
+3. The holder accepts a quote and the two parties run the RFP-003 LEZ↔asset
+   atomic-swap protocol. The LEZ side (the sASSET + collateral release) locks
+   first where the asset's chain forces that ordering; the LP locks the real
+   asset on its home chain second. See
+   [primer §Locking order](../appendix/atomic-swaps-primer.md#locking-order) for
+   when and why this ordering is forced (it is a per-chain property of the
+   underlying, not a global rule).
+4. The holder reveals the secret on LEZ; the LP uses it to claim the sASSET-backed
+   stable collateral as their payout (less any protocol fee). The LP also has a
+   claim path on the home-chain side to deliver the real asset to the holder.
+5. On success, sASSET is burned on LEZ (collateral leaves the RFP-024 vault to
+   the LP); the holder receives the real asset on its home chain.
+
+Failure modes:
+
+- **No LP shows up.** The holder's redemption intent expires; their sASSET
+  position is unchanged. They can retry, lower the price, or sell sASSET on a DEX
+  instead.
+- **LP walks mid-swap.** The atomic-swap refund path unwinds; the holder retains
+  sASSET; the LP loses time and transaction fees. See
+  [primer §Timelocks and refunds](../appendix/atomic-swaps-primer.md#timelocks-and-refunds).
+- **Holder walks mid-swap.** Symmetric; both parties refund.
+- **The free-option problem applies.** Either party can walk and the other waits
+  out the refund window. This is intrinsic to atomic swaps; RFP-026 accepts it as
+  the cost of non-custody. LP-0018 (spam protection for makers) and LP-0019
+  (taker reliability) may be layered on later but are not preconditions.
+
+## Pros
+
+- **Real asset delivery without custody.** Successful redemption ends with the
+  real asset on its home chain (real XMR on Monero L1, real BTC on Bitcoin, …),
+  with no protocol-side multisig holding the underlying. RFP-025 carries custody
+  risk; RFP-026 does not.
+- **Composes cleanly with RFP-024.** The CDP mint mechanic from RFP-024 is
+  unchanged. RFP-026 adds a peer-to-peer exit path that LEZ DeFi users can use
+  alongside the standard burn-to-stables option, for any asset whose swap leg
+  exists.
+- **Open LP set is censorship-resistant.** No permissioned set; no KYC; no
+  operator that can be coerced into refusing service.
+- **Regulatory minimalism preserved from RFP-024.** The protocol does not handle
+  the real asset; the atomic swap is a bilateral interaction between user and LP.
+  The protocol provides the LEZ-side escrow program, the matching board over
+  Logos Delivery, and the cryptographic primitives — nothing more.
+- **Lowest-risk path to a real-asset exit.** Other paths (RFP-021 federated DEX,
+  RFP-025 multisig wrap) require custody. RFP-026 keeps non-custody intact.
+
+## Cons
+
+- **Redemption set narrower than the synthetic set.** Some assets will have a CDP
+  synthetic (RFP-024) but no atomic-swap leg, so they cannot be redeemed here.
+  The redeemable set lags the mintable set by however long the LEZ↔asset swap legs
+  take to build and audit in RFP-003.
+- **Soft SLA only.** Redemption availability is whatever the LP market clears.
+  There is no protocol-side commitment to a delivery window. A user who wants a
+  hard SLA on the real asset must use RFP-025 (and accept its custody trade-off).
+- **LP-side bottleneck likely.** Mint demand may be easy; LP supply (holders of
+  the real asset willing to atomic-swap it for stables) is harder to source. For
+  privacy-coin underlyings, privacy-maximalist holders may not want a public LP
+  role.
+- **Atomic-swap UX inherited.** Settlement time is dominated by the home chain's
+  block confirmations (for XMR typically under an hour but with variance; varies
+  per asset); both parties online for the lock+reveal duration. Intent gossip over
+  Logos Delivery softens but cannot eliminate this.
+- **Free-option problem applies.** Either party can walk mid-swap, costing the
+  other party time. This is intrinsic to atomic swaps. LP-0018 and LP-0019 address
+  it but are not preconditions; this RFP ships without those mitigations.
+- **Adverse-selection of LPs.** LPs likely show up when oracle is below the true
+  asset price (free money on the redemption leg) and vanish when oracle is above.
+  Redemption availability is expected to be asymmetric across price regimes.
+- **No fee revenue capture for the protocol on the LP side.** Open LP set means
+  LPs capture the spread; the protocol's only revenue is mint/burn fees from
+  RFP-024 plus any explicit redemption-protocol fee.
+
+## Risks
+
+- **LP exodus.** All LPs for an asset stop quoting. Redemption of that synthetic
+  becomes unavailable; users fall back to RFP-024's sell-on-DEX exit. The protocol
+  cannot intervene. Mitigation: design to survive long no-LP windows; let the
+  market discount on the synthetic signal demand to bring LPs back.
+- **Spam attacks on makers.** A malicious user can post redemption intents that an
+  LP locks against, then walks. LP loses time and fees per cycle. Mitigation:
+  LP-0018 if/when it ships; until then, LPs must filter intents at their own
+  discretion (e.g. requiring sASSET proof-of-balance or rate-limiting per
+  identity).
+- **Maker-side reliability.** An unreliable LP can grief takers by quote-and-walk.
+  Mitigation: LP-0019 if/when it ships; until then, takers must filter LPs by
+  reputation gathered out-of-band.
+- **Locking-order constraint (per chain).** On some home chains the LEZ side must
+  lock first because the underlying provides no on-chain primitive supporting the
+  locks-first role — Monero is the canonical case (see
+  [primer §Locking order](../appendix/atomic-swaps-primer.md#locking-order)). For
+  the LEZ→asset direction (this RFP's direction), this is the *taker* (sASSET
+  holder) locking first, which is the desired draining-attack posture (taker bears
+  the lock-window cost). Sub-case A in LP-0018's framing. Chains with richer
+  scripting (Bitcoin, Ethereum) relax this; the constraint is asset-specific.
+- **Atomic-swap protocol immaturity.** The deployed BTC-XMR atomic-swap ecosystem
+  (eigenwallet, Farcaster) is community-scale not volume-scale. Each LEZ↔asset
+  pair is new; the relevant LEZ↔asset module from RFP-003 must be built and
+  audited before that asset can be redeemed here. Mitigation: RFP-003 is a
+  prerequisite; RFP-026 depends on its per-asset atomic-swap SDK, and the set of
+  redeemable assets grows only as those legs land.
+
+## Relationship to other RFPs in this bundle
+
+- **RFP-024 (CDP-backed sASSET)** is a **hard prerequisite**. RFP-026 does not
+  implement the CDP mint mechanic; it only adds the atomic-swap redemption path. A
+  builder funded for RFP-026 must build against a deployed (or jointly-built)
+  RFP-024.
+- **RFP-003 (Atomic Swaps with LEZ, open)** is a **hard prerequisite**. The
+  per-asset LEZ↔asset atomic-swap SDK is the redemption settlement layer, and it
+  defines which assets are redeemable. RFP-026 does not modify RFP-003; it
+  consumes it.
+- **RFP-025 (real-asset multisig)** is the not-preferred custody-backed
+  alternative for real-asset delivery, scoped to XMR. RFP-025 promises a hard SLA
+  at the cost of custody; RFP-026 offers a soft SLA without custody. For the XMR
+  case the two are mutually exclusive product directions for the "deliver the real
+  asset to synthetic holders" goal.
+- **RFP-021 (cross-chain privacy DEX)** is orthogonal — federated-custody
+  real-asset cross-chain swaps, not synthetic exposure with optional redemption.
+- **LP-0018 (Spam protection for atomic-swap makers)** can be layered on the
+  redemption-leg atomic swap once the prize is awarded. Not a precondition;
+  RFP-026 ships with the free-option problem accepted as a known cost.
+- **LP-0019 (Taker reliability for atomic swaps)** can be layered for LP-discovery
+  UX and maker-misbehaviour attribution. Not a precondition.
+- **RFP-004 (Privacy-Preserving DEX, open)** is the natural single-chain trading
+  venue for sASSET pre-redemption (the alternative exit path that does not involve
+  atomic swaps at all).
+
+See [appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md) for
+atomic-swap mechanics and the locking-order protocol constraint, and
+[appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md)
+for the federated-signer-vs-atomic-swap trust contrast.
+
+## References
+
+- [RFP-003: Atomic Swaps with LEZ](./RFP-003-atomic-swaps.md)
+- [RFP-024: CDP-Backed Synthetic Assets](./RFP-024-cdp-backed-synthetic.md)
+- [appendix/atomic-swaps-primer.md](../appendix/atomic-swaps-primer.md)
+- [appendix/cross-chain-trust-model-contrast.md](../appendix/cross-chain-trust-model-contrast.md)
+- [appendix/synthetics-design-space.md](../appendix/synthetics-design-space.md)
+- [LP-0018: Spam Protection for Atomic-Swap Makers](../lambda-prizes/LP-0018-atomic-swap-anti-spam.md)
+- [LP-0019: Taker Reliability for Atomic Swaps](../lambda-prizes/LP-0019-atomic-swap-maker-reputation.md)
+- [Bitcoin to Monero atomic swaps (getmonero.org, 2021-08-20)](https://www.getmonero.org/2021/08/20/atomic-swaps.html)
+  (accessed 2026-05-21)
+- [eigenwallet/core (active fork of comit-network/xmr-btc-swap; v4.6.4, 2026-05-21)](https://github.com/eigenwallet/core)
+  (accessed 2026-05-22)
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..9bf0551
--- /dev/null
+++ b/lambda-prizes/LP-0018-atomic-swap-anti-spam.md
@@ -0,0 +1,254 @@
+<!-- Draft staged in logos-co/rfp; will move to logos-co/lambda-prize once accepted. -->
+
+<!-- Don't forget to add/update this prize in the table in README.md when moved. -->
+
+# 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 (RFPs 021, 024, 025, 026) uses the vanilla RFP-003 atomic swap as the
+privacy-non-custodial primitive, but vanilla atomic swaps remain economically
+unattractive for makers at scale because of the spam exposure. Without a
+credible spam-protection mechanism, the maker side of the LEZ atomic-swap market
+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; RFP-021 already covers that design space.
+- **Survives the LEZ-locks-first protocol constraint.** For XMR↔LEZ the LEZ side
+  locks first in both sub-cases (A and B). The mechanism must work under this
+  constraint, not assume it can be reversed.
+- **Burnt or escrowed principal in adverse paths is not payable to the
+  counterparty in a way that creates new griefing incentives.** If a defaulting
+  taker's deposit is paid to the maker, the maker has an incentive to provoke
+  refunds; this defeats the purpose. Burn destinations (unspendable outputs) or
+  rebated-to-protocol designs are acceptable; counterparty-paid designs are not.
+- **Honest-refund / connectivity-loss paths.** An honest party who refunds due
+  to connectivity issues should not lose disproportionately. The mechanism's
+  cost in adverse paths should be bounded.
+- **Discoverable parameters.** The cost the taker faces under the mechanism
+  (deposit fraction, bond size, fee fraction, etc.) should be known to the taker
+  before they initiate the swap. Quote-level discovery is acceptable.
+
+## Scope
+
+### In Scope
+
+- The 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).
+  RFP-021 covers that design space.
+- 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..30b7491
--- /dev/null
+++ b/lambda-prizes/LP-0019-atomic-swap-maker-reputation.md
@@ -0,0 +1,257 @@
+<!-- Draft staged in logos-co/rfp; will move to logos-co/lambda-prize once accepted. -->
+
+<!-- Don't forget to add/update this prize in the table in README.md when moved. -->
+
+# 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; RFP-021 already covers that design space.
+- **Adversarially robust.** The mechanism must distinguish a *fabricated* taker
+  complaint about an honest maker from a *valid* taker complaint about a
+  malicious maker. Either the protocol detects the difference from observable
+  state, or the mechanism produces evidence a third party can verify, or the
+  mechanism penalises false complaints. Any approach is acceptable; the
+  submission must justify it.
+- **Privacy of the taker.** A taker reporting a misbehaving maker should not be
+  forced to reveal which other swaps the taker has done (beyond the disputed
+  one), unless the taker chooses to.
+- **Spam resistance.** A malicious taker should not be able to mass-publish
+  fabricated misbehaviour reports to deny-of-service the mechanism. Either the
+  cost of publishing is bounded below or the verifier filters cheaply.
+- **Survives the LEZ↔XMR Monero-unobservability constraint.** For sub-case A
+  specifically, the Monero side is not directly observable from LEZ. The
+  mechanism must work under this constraint; it may use any approach (view-key
+  disclosure, FCMP++-grade zk proofs, watchtower nodes, multi-party attestation,
+  on-chain attestation by the maker, slashable maker bonds, off-chain proof
+  bundles, etc.).
+
+## Scope
+
+### In Scope
+
+- The 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.