logos-co · fryorcraken · Jun 12, 2026
diff --git a/README.md b/README.md
@@ -41,6 +41,8 @@ All prizes live in the `[prizes/](prizes/)` directory. Each prize is a markdown
 | [LP-0015](prizes/LP-0015.md) | General cross-program calls via tail calls               | Large  | Closed |
 | [LP-0016](prizes/LP-0016.md) | Anonymous Forum with Threshold Moderation                | Large  | Open   |
 | [LP-0017](prizes/LP-0017.md) | Whistleblower: document upload and indexing Basecamp app     | Medium | Open   |
+| [LP-0018](prizes/LP-0018.md) | Spam Protection for Atomic-Swap Makers                   | Large  | Draft  |
+| [LP-0019](prizes/LP-0019.md) | Taker Reliability for Atomic Swaps                        | Large  | Draft  |
 
 ### Proposing a New Prize
 

diff --git a/prizes/LP-0018.md b/prizes/LP-0018.md
@@ -0,0 +1,261 @@
+<!-- Don't forget to add/update this prize in the table in README.md -->
+
+---
+dependencies:
+  - id: RFP-003
+    reason: protects makers in the RFP-003 LEZ atomic-swap protocol and builds on its SDK as the underlying primitive
+---
+
+# 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](https://github.com/logos-co/rfp/blob/master/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](https://github.com/logos-co/rfp/blob/master/appendix/atomic-swaps-primer.md#locking-order);
+the constraint is protocol-level, not economic. This creates two distinct
+sub-cases for XMR↔LEZ:
+
+- **Sub-case A: LEZ-side party is the *taker*** (trade direction LEZ→XMR; user
+  holds Logos, wants XMR). The taker locks LEZ first. The maker holds the
+  post-lock free option — he sees the taker's LEZ lock and decides whether to
+  lock XMR off-chain. The mechanism must price or close the maker's free option
+  without harming the taker's experience. Candidate examples include a fee-burn
+  or non-refundable deposit on the LEZ refund branch (cf. eigenwallet PR #675
+  for BTC). Not prescribed.
+- **Sub-case B: LEZ-side party is the *maker*** (trade direction XMR→LEZ; user
+  holds XMR, wants Logos). The maker locks LEZ first. The taker can spam the
+  maker by repeatedly initiating-and-abandoning swaps — exactly the
+  draining-attack condition the BTC-first ordering is meant to eliminate for
+  BTC-XMR, but which we cannot eliminate for XMR-LEZ in this direction because
+  LEZ must lock first regardless. The mechanism must protect the maker from this
+  spam. Candidate approaches include reputation, taker-side bonds, taker
+  fee-burns, or other.
+
+**Scope of this prize: XMR↔LEZ only.** Follow-up prizes can cover LEZ↔BTC,
+LEZ↔ETH, or other pairs once the XMR↔LEZ case has a winning mechanism.
+
+**Single prize, two acceptable solution shapes.** Applicants may address
+sub-case A only, sub-case B only, or both. A submission that addresses both
+sub-cases coherently ranks above one that addresses only one, but a credible
+single-sub-case mechanism is sufficient to win.
+
+## Motivation
+
+The atomic-swap branch of the cross-chain DEX design tree has a known structural
+weakness on the free-option / spam-the-maker problem. The Logos cross-chain DEX
+bundle (RFP-024 and RFP-026, on the vanilla RFP-003 atomic swap) uses that swap
+as the privacy-non-custodial primitive, but vanilla atomic swaps remain economically
+unattractive for makers at scale because of the spam exposure. Without a
+credible spam-protection mechanism, the maker side of the LEZ atomic-swap market
+is likely to remain at hobbyist scale (see
+[eigenwallet](https://github.com/eigenwallet/core/): community-scale,
+single-digit active makers, BTC→XMR direction only).
+
+A competitive prize is the right mechanism because the design space is large and
+the right answer is not obvious. On-LEZ bonds, external-chain fee-burns,
+reputation gating, hybrid designs, or approaches we have not anticipated may all
+qualify. The Logos team does not want to pre-judge.
+
+## Success Criteria
+
+- [ ] **Proven spam reduction.** The submission must include hard stats (e.g.
+  measured per-maker spam-attempt rate before and after the mechanism over a
+  stated observation window) and/or testimony from at least two independent
+  active makers running the mechanism in production. Toy numbers from a testnet
+  alone are not sufficient — the prize requires the solution be polished, used,
+  and adopted.
+- [ ] **No reduction in reliability for honest takers.** An honest taker
+  initiating a legitimate swap should not experience materially worse liveness,
+  settlement time, or failure rate than under the vanilla RFP-003 protocol.
+  Quantify against a baseline.
+- [ ] **No reduction in reliability for honest makers.** An honest maker serving
+  legitimate takers should not experience materially worse liveness or capital
+  efficiency than under the vanilla RFP-003 protocol. Quantify against a
+  baseline.
+
+## Design constraints
+
+These are framing, not pass/fail criteria. Submissions that violate them are
+unlikely to deliver the success criteria above, but the criteria above are what
+evaluators measure.
+
+- **Compatible with the RFP-003 LEZ atomic-swap SDK as the underlying
+  primitive.** The mechanism should not require changes to the cryptographic
+  core (joint-key setup, adaptor signature, lock, reveal). Solvers may add
+  escrow logic around the swap.
+- **Preserves non-custody.** No third party (signer set, validator, oracle,
+  attestor) should hold user funds at any stage. Reintroducing federated trust
+  defeats the purpose; the bundle deliberately rejected the federated-custody
+  design space (see
+  [appendix/cross-chain-trust-model-contrast.md](https://github.com/logos-co/rfp/blob/master/appendix/cross-chain-trust-model-contrast.md)).
+- **Survives the LEZ-locks-first protocol constraint.** For XMR↔LEZ the LEZ side
+  locks first in both sub-cases (A and B). The mechanism must work under this
+  constraint, not assume it can be reversed.
+- **Burnt or escrowed principal in adverse paths is not payable to the
+  counterparty in a way that creates new griefing incentives.** If a defaulting
+  taker's deposit is paid to the maker, the maker has an incentive to provoke
+  refunds; this defeats the purpose. Burn destinations (unspendable outputs) or
+  rebated-to-protocol designs are acceptable; counterparty-paid designs are not.
+- **Honest-refund / connectivity-loss paths.** An honest party who refunds due
+  to connectivity issues should not lose disproportionately. The mechanism's
+  cost in adverse paths should be bounded.
+- **Discoverable parameters.** The cost the taker faces under the mechanism
+  (deposit fraction, bond size, fee fraction, etc.) should be known to the taker
+  before they initiate the swap. Quote-level discovery is acceptable.
+
+## Scope
+
+### In Scope
+
+- The spam-protection mechanism itself: design, on-chain components (LEZ
+  program, external-chain script changes if any), client-side SDK, integration
+  with RFP-003's per-pair atomic-swap modules.
+- One or both XMR↔LEZ sub-cases (A and/or B), with an incentive-compatibility
+  argument that explains why the mechanism makes the abort branch EV-negative
+  for the attacker.
+- A reference deployment with active makers and takers running the mechanism in
+  production long enough to gather the proven-reduction stats / testimony.
+
+### Out of Scope
+
+- Modifying the underlying RFP-003 atomic-swap cryptography (joint-key setup,
+  adaptor signature, lock/reveal).
+- Reintroducing federated trust (TSS custody, signer sets, oracle attestors).
+  The bundle deliberately rejected that design space (see
+  [appendix/cross-chain-trust-model-contrast.md](https://github.com/logos-co/rfp/blob/master/appendix/cross-chain-trust-model-contrast.md)).
+- LEZ↔BTC, LEZ↔ETH, or other non-XMR pairs. Follow-up prizes if needed.
+
+## Prize Structure
+
+- **Total Prize:** $X
+- **Effort:** L
+
+> Leave prize pool blank — this will be determined by the Logos team. Single
+> winner by default.
+
+## Eligibility
+
+Open to any individual or team. Submissions must be original work. Teams must
+hold the rights to all submitted code and agree to license it under MIT or
+Apache-2.0.
+
+## Submission Requirements
+
+A submission must include:
+
+- A public repository containing the LEZ program(s), client SDK, integration
+  tests, and any external-chain script changes.
+- A written design document covering the mechanism, the adversarial model, the
+  incentive-compatibility argument, and the honest-refund / connectivity-loss
+  handling.
+- Proven-reduction evidence: hard stats from a real deployment, and/or signed
+  testimony from at least two independent active makers running the mechanism.
+- A narrated video walkthrough demo showing (a) honest completion at no extra
+  cost to honest parties, and (b) at least one adversarial-taker scenario where
+  the mechanism deters the attack.
+- A short comparison against reference prior art (minimum: eigenwallet PR #675),
+  stating what the submission borrows, where it diverges, and why.
+
+## Evaluation Process
+
+By default, submissions are evaluated first-come-first-served against the
+success criteria. The first submission that meets all criteria wins.
+
+Evaluators will independently clone the repository, run the demo script,
+exercise at least one adversarial-taker scenario, and verify the
+proven-reduction evidence (cross-checking testimony with the named makers).
+
+Because the design space is large and multiple valid approaches exist,
+evaluators may rank tied submissions on:
+
+1. Coverage across sub-cases (a mechanism addressing both A and B ranks above
+   one addressing only one).
+2. Magnitude of demonstrated spam reduction and quality of the adoption
+   evidence.
+3. Capital efficiency: mechanisms that impose less cost on honest users rank
+   above mechanisms that always impose cost.
+4. Integration cleanliness with RFP-003's existing per-pair modules.
+
+The following policies apply to all prizes (see
+[evaluation policies](https://github.com/logos-co/lambda-prize/blob/main/README.md#evaluation-policies)):
+
+- **Submissions:** each builder (or team) is allowed a maximum of **3
+  submissions** per prize, with at most **one submission/review per week**.
+- **Feedback:** initial evaluation feedback is limited to a pass/fail indication
+  against the success criteria.
+
+## Resources
+
+- [RFP-003: Atomic Swaps with LEZ](https://github.com/logos-co/rfp/blob/master/RFPs/RFP-003-atomic-swaps.md)
+  — the vanilla atomic-swap protocol this mechanism builds on.
+- [eigenwallet PR #675: fee-burn on refunds](https://github.com/eigenwallet/core/pull/675)
+  — reference prior art; an open proposal introducing a non-refundable burn on
+  the refund branch via maker-set deposit fraction, withhold path, and mercy
+  release. Solvers may adopt, adapt, or reject.
+- [eigenwallet/core release 4.0.0 anti-spam deposit](https://github.com/eigenwallet/core/releases/tag/4.0.0)
+  — shipped narrower mechanism (cancel-timelock reduction plus 30-minute
+  withhold/mercy) that PR #675 generalises.
+- [appendix/atomic-swaps-primer.md](https://github.com/logos-co/rfp/blob/master/appendix/atomic-swaps-primer.md)
+  — atomic-swap mechanics, free-option framing, locking-order protocol
+  constraint, `σ × √T × notional` notation.
+- [appendix/cross-chain-trust-model-contrast.md](https://github.com/logos-co/rfp/blob/master/appendix/cross-chain-trust-model-contrast.md)
+  — the federated-signers-vs-atomic-swaps trust contrast that motivates keeping
+  atomic swaps non-custodial.
+- [Han, Lin, Yu, On the optionality and fairness of Atomic Swaps, IACR 2019/896](https://eprint.iacr.org/2019/896)
+  — formal proof that an atomic swap is equivalent to a premium-free American
+  Call Option; quantifies the implicit premium at 2-3% of asset value for
+  cryptocurrency pairs.
+- [Hoenisch and del Pino, Atomic Swaps between Bitcoin and Monero, arXiv:2101.12332](https://arxiv.org/abs/2101.12332)
+  — §4 covers the draining-attack analysis that determines which side locks
+  first under economic considerations, useful for solvers reasoning about
+  sub-cases A and B.
+- [LP-0019: Taker Reliability for Atomic Swaps](./LP-0019.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.