diff --git a/README.md b/README.md index 39f9913..9b41edc 100644 --- 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 new file mode 100644 index 0000000..5f17f6f --- /dev/null +++ b/prizes/LP-0018.md @@ -0,0 +1,261 @@ + + +--- +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. diff --git a/prizes/LP-0019.md b/prizes/LP-0019.md new file mode 100644 index 0000000..fd18cdf --- /dev/null +++ b/prizes/LP-0019.md @@ -0,0 +1,263 @@ + + +--- +dependencies: + - id: RFP-003 + reason: improves taker reliability in the RFP-003 LEZ atomic-swap protocol and builds on its SDK as the underlying primitive +--- + +# 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.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](https://github.com/logos-co/rfp/blob/master/appendix/atomic-swaps-primer.md#locking-order)). +This creates two sub-cases the prize covers: + +- **Sub-case A: LEZ-side party is the *taker*** (LEZ→XMR; taker holds Logos, + wants XMR). The taker locks LEZ first, then waits for the maker to lock XMR + off-chain. The maker can quote-and-walk by never locking XMR. From LEZ alone + the protocol cannot tell whether the maker walked or the taker's claim of a + quote-and-walk is fabricated. **Mechanisms that improve taker reliability in + this sub-case must produce maker-misbehaviour evidence that other parties can + verify** (so the taker is not left with a he-said-she-said dispute). +- **Sub-case B: LEZ-side party is the *maker*** (XMR→LEZ; taker holds XMR, wants + Logos). The maker locks LEZ first, then waits for the taker to advance with + the reveal. From LEZ the protocol can detect the maker's lock directly; + taker-reliability concerns here focus on **maker selective serving** (refusing + to quote, refusing to honour a quote, quoting deceptively) and on **liveness** + (maker disappearing mid-swap after their LEZ lock has confirmed). + +**Scope of this prize: XMR↔LEZ only.** Follow-up prizes may cover other pairs. + +**Single prize, two acceptable solution shapes.** Applicants may address +sub-case A only, sub-case B only, or both. A submission addressing both ranks +above one addressing only one, but a credible single-sub-case mechanism is +sufficient to win. + +## Motivation + +In an atomic-swap protocol with no reputation or attribution layer, every taker +swap is a first-time interaction. A maker who misbehaves once can disappear and +reappear under a new identity at zero cost; a maker who misbehaves +systematically against some takers but not others has no protocol-level +deterrent. Vanilla RFP-003 atomic swaps cannot offer the taker the kind of "I +know this counterparty has reliably served thousands of swaps" guarantee that +middle-chain DEXes get for free (their counterparty is the protocol). + +A competitive prize is the right mechanism because the design space is large and +the right answer is not obvious. Reputation systems (on-chain or off-chain), +slashable bonds, watchtower designs, hybrid approaches, or solutions we have not +anticipated may all qualify. The Logos team does not want to pre-judge. + +## Success Criteria + +- [ ] **Proven taker-reliability improvement.** The submission must include hard + stats (e.g. measured taker-side swap-success rate before and after the + mechanism, or measured incidence of maker misbehaviour detected/deterred by + the mechanism over a stated observation window) and/or testimony from at least + two independent active takers running against makers integrated with the + mechanism in production. Toy numbers from a testnet alone are not sufficient — + the prize requires the solution be polished, used, and adopted. +- [ ] **No reduction in reliability for honest makers.** An honest maker serving + legitimate takers should not experience materially worse liveness, capital + efficiency, or quote-distribution reach than under the vanilla RFP-003 + protocol. Quantify against a baseline. +- [ ] **No reduction in reliability for honest takers.** The mechanism's own + cost to honest takers (latency, gas, complexity) must not exceed the + unreliability it removes. Quantify against a baseline. + +## Design constraints + +These are framing, not pass/fail criteria. + +- **Compatible with the RFP-003 LEZ atomic-swap SDK as the underlying + primitive.** Do not require changes to the cryptographic core. +- **Preserves non-custody.** No third party (signer set, validator, oracle, + attestor) holds user funds at any stage. Reintroducing federated trust defeats + the purpose; the bundle deliberately rejected the federated-custody design + space (see + [appendix/cross-chain-trust-model-contrast.md](https://github.com/logos-co/rfp/blob/master/appendix/cross-chain-trust-model-contrast.md)). +- **Adversarially robust.** The mechanism must distinguish a *fabricated* taker + complaint about an honest maker from a *valid* taker complaint about a + malicious maker. Either the protocol detects the difference from observable + state, or the mechanism produces evidence a third party can verify, or the + mechanism penalises false complaints. Any approach is acceptable; the + submission must justify it. +- **Privacy of the taker.** A taker reporting a misbehaving maker should not be + forced to reveal which other swaps the taker has done (beyond the disputed + one), unless the taker chooses to. +- **Spam resistance.** A malicious taker should not be able to mass-publish + fabricated misbehaviour reports to deny-of-service the mechanism. Either the + cost of publishing is bounded below or the verifier filters cheaply. +- **Survives the LEZ↔XMR Monero-unobservability constraint.** For sub-case A + specifically, the Monero side is not directly observable from LEZ. The + mechanism must work under this constraint; it may use any approach (view-key + disclosure, FCMP++-grade zk proofs, watchtower nodes, multi-party attestation, + on-chain attestation by the maker, slashable maker bonds, off-chain proof + bundles, etc.). + +## Scope + +### In Scope + +- The taker-reliability mechanism: data model, evidence/attribution scheme, + verification approach, aggregation if relevant, anti-spam and anti-fabrication + mechanisms. +- Storage and distribution of any data the mechanism produces (Logos Delivery is + the expected substrate for off-chain data; on-chain mechanisms use LEZ). +- Client-side: SDK for takers to query maker reliability and report + misbehaviour; SDK for makers to dispute false reports if applicable. +- A reference integration with RFP-003 LEZ atomic-swap maker daemon and taker + client. +- A reference deployment with active takers and makers running the mechanism in + production long enough to gather the proven-reliability stats / testimony. + +### Out of Scope + +- Modifying the underlying RFP-003 atomic-swap cryptography. +- Building a protocol-level slashing mechanism on top of the reliability + evidence (LP-0018 covers the maker-side equivalent; if the mechanisms produce + evidence usable for slashing, integration with LP-0018 is welcomed but not + required). +- LEZ↔BTC, LEZ↔ETH, or other non-XMR pairs. + +## Prize Structure + +- **Total Prize:** $X +- **Effort:** L + +> Leave prize pool blank — this will be determined by the Logos team. Single +> winner by default. + +## Eligibility + +Open to any individual or team. Submissions must be original work. Teams must +hold the rights to all submitted code and agree to license it under MIT or +Apache-2.0. + +## Submission Requirements + +A submission must include: + +- A public repository containing the LEZ program(s) if any, client SDK, + integration tests, and any external-chain components. +- A written design document covering the mechanism, the adversarial model + (sybil, spam, fabrication, false-rebuttal), the privacy analysis (what the + mechanism reveals about whom), and the LEZ↔XMR-specific handling of Monero + unobservability. +- Proven-reliability evidence: hard stats from a real deployment, and/or signed + testimony from at least two independent active takers running against makers + integrated with the mechanism. +- A narrated video walkthrough demo showing (a) honest swap completion with no + extra cost, (b) a maker-misbehaviour scenario where the mechanism detects and + surfaces the misbehaviour, and (c) a fabricated-complaint scenario where the + mechanism rejects or penalises the fabrication. + +## Evaluation Process + +By default, submissions are evaluated first-come-first-served against the +success criteria. The first submission that meets all criteria wins. + +Evaluators will independently clone the repository, run the demo, exercise the +maker-misbehaviour and fabricated-complaint scenarios, and verify the +proven-reliability evidence. + +Tied submissions may be ranked on: + +1. Coverage across sub-cases (a mechanism addressing both A and B ranks above + one addressing only one). +2. Magnitude of demonstrated reliability improvement and quality of the adoption + evidence. +3. Privacy cost (lower disclosure to third parties is preferred where the + mechanism uses disclosure). +4. Adversarial robustness across more distinct attack vectors (sybil, spam, + fabrication, false-rebuttal). +5. Integration cleanliness with RFP-003's existing maker daemon and taker + client. + +The following policies apply to all prizes (see +[evaluation policies](https://github.com/logos-co/lambda-prize/blob/main/README.md#evaluation-policies)): + +- **Submissions:** each builder (or team) is allowed a maximum of **3 + submissions** per prize, with at most **one submission/review per week**. +- **Feedback:** initial evaluation feedback is limited to a pass/fail indication + against the success criteria. + +## Resources + +- [RFP-003: Atomic Swaps with LEZ](https://github.com/logos-co/rfp/blob/master/RFPs/RFP-003-atomic-swaps.md) + — the underlying atomic-swap protocol whose makers this mechanism evaluates. +- [LP-0018: Spam Protection for Atomic-Swap Makers](./LP-0018.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.