diff --git a/.github/ISSUE_TEMPLATE/milestone.yml b/.github/ISSUE_TEMPLATE/milestone.yml new file mode 100644 index 0000000..cf91142 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/milestone.yml @@ -0,0 +1,88 @@ +name: 📍 Milestone +description: Track a single milestone from an accepted RFP proposal — create one per milestone as a sub-issue of the proposal. +title: "[MILESTONE] RFP-XXX Mx — Milestone Name" +labels: ["milestone"] +assignees: ["hackyguru"] + +body: + - type: markdown + attributes: + value: | + Use this template to break an **accepted** proposal into one issue per milestone so the + engineering team can review deliverables independently. Create each milestone as a + **sub-issue** of the parent proposal issue. + + - type: input + id: parent-proposal + attributes: + label: Parent Proposal + description: The accepted proposal issue this milestone belongs to. + placeholder: "#112" + validations: + required: true + + - type: input + id: rfp-id + attributes: + label: RFP ID + placeholder: RFP-003 + validations: + required: true + + - type: input + id: team + attributes: + label: Team / Grantee + placeholder: Gateway + validations: + required: true + + - type: input + id: milestone + attributes: + label: Milestone + description: Milestone number and short name. + placeholder: "M1 — Design, threat model, SDK trait surface" + validations: + required: true + + - type: textarea + id: deliverables + attributes: + label: Deliverables + description: Checklist of everything that must be delivered for this milestone. Copied from the proposal. + value: | + - [ ] + validations: + required: true + + - type: input + id: payout + attributes: + label: Payout (USD) + description: Payout released on approval of this milestone. + placeholder: "$24,500" + + - type: input + id: duration + attributes: + label: Duration / Timeline + placeholder: "3 weeks" + + - type: textarea + id: acceptance + attributes: + label: Acceptance / Completion Criteria + description: What the reviewer verifies before this milestone is approved for payout. + + - type: checkboxes + id: review + attributes: + label: Engineering Review + description: Checked off by the reviewing engineer before the milestone is approved. + options: + - label: Deliverables received and match the proposal scope + - label: Code open-sourced under MIT / Apache 2.0 + - label: CI green on the default branch + - label: Docs / README delivered + - label: Milestone approved for payout diff --git a/RFPs/RFP-003-atomic-swaps.md b/RFPs/RFP-003-atomic-swaps.md index d0fa52b..ec6b602 100644 --- a/RFPs/RFP-003-atomic-swaps.md +++ b/RFPs/RFP-003-atomic-swaps.md @@ -13,6 +13,35 @@ dependencies: > **Status:** Closed. This RFP is no longer accepting proposal submissions. +> **Note.** This specification describes an outcome that may benefit the Logos +> ecosystem. It is a proposal rather than an instruction. Its requirements +> reflect the technical compatibility with the Logos technology stack and are +> the criteria against which proposals and milestones are evaluated. Logos makes +> no representation as to the legal or regulatory treatment of this +> specification or any implementation of it in any jurisdiction. +> +> Teams implementing it are solely responsible for (i) assessing the risks and +> implications of what they build; (ii) obtaining their own professional advice; +> and (iii) for complying with any legal and regulatory requirements that apply +> to them. Software developed under the Program is published and maintained by +> its developers, not by Logos. +> +> Anyone who chooses to deploy, host, operate or use software developed under +> the Program, whether or not they were awarded a grant under the Program, does +> so at their own risk and is solely responsible for complying with any legal or +> regulatory requirements that apply to them. See the +> [Terms & Conditions](../TERMS_AND_CONDITIONS.md). +> +> Deploying the software described in this RFP, operating any service based on +> it, or carrying on business through it may amount to regulated activity in +> some jurisdictions, including where it involves holding or managing users' +> assets or providing services to others. Whoever conducts any such activity +> does so as principal, in their own name, and is solely responsible for +> assessing its regulatory treatment, including any licensing, registration, +> sanctions or anti-money laundering obligations that may apply to them. Logos +> does not make any representation, provides any advice or assumes any +> responsibility in respect of any such determination or compliance. + ## 🧭 Overview Build a unified atomic swap application that enables trustless, non-custodial @@ -46,14 +75,16 @@ out of LEZ without trusting an intermediary, which directly conflicts with the ecosystem's trust-minimisation principles. Each target chain presents distinct cryptographic challenges that make this -non-trivial. Bitcoin HTLCs are identifiable on-chain and link the two swap legs; -adaptor signatures with Taproot key-path spends solve this, making swaps -indistinguishable from normal payments. Monero has no scripting system at all, -requiring cross-curve DLEQ proofs to achieve atomicity. Zcash transparent -inherits Bitcoin script unchanged and supports HTLC-based swaps via +non-trivial. Bitcoin HTLCs use a distinctive script pattern and place the same +hash value on both swap legs; adaptor signatures with Taproot key-path spends +avoid both, so cooperative swap transactions take the standard form of ordinary +Taproot spends. Monero has no scripting system at all, requiring cross-curve +DLEQ proofs to achieve atomicity. Zcash transparent inherits Bitcoin script +unchanged and supports HTLC-based swaps via [BIP-199](https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki); -adaptor-signature variants are a stretch goal for cross-chain unlinkability. The -Bitcoin and Monero constructions are surveyed with sources in +adaptor-signature variants are a stretch goal for removing the shared hash +identifier that HTLCs place on both chains. The Bitcoin and Monero constructions +are surveyed with sources in [Appendix: Bitcoin and Monero Adaptor-Signature Swap Primitives](../appendix/btc-xmr-adaptor-swap-primitives.md); the Zcash analysis is in [Appendix: Zcash Atomic Swap Primitives](../appendix/zcash-atomic-swap-primitives.md). @@ -75,12 +106,13 @@ application to build on. Logos Chat respectively. 2. Trustless swaps between LEZ and **Bitcoin** are supported using Schnorr adaptor signatures (BIP-340) and Taproot (BIP-341). The cooperative claim - path must be a key-path spend, indistinguishable from a normal Taproot - payment. The **refund branch** may be implemented either as a pre-signed - timelocked transaction (key-path, refund also indistinguishable) or as a - Taproot script-path tapleaf (`OP_CHECKSEQUENCEVERIFY`, refund spend - identifiable but enforced by consensus); both are acceptable. The two - constructions and their trade-offs are described in + path must be a key-path spend, in the standard form of an ordinary Taproot + payment, with no protocol-specific script footprint on-chain. The **refund + branch** may be implemented either as a pre-signed timelocked transaction + (key-path, refund in the same standard form) or as a Taproot script-path + tapleaf (`OP_CHECKSEQUENCEVERIFY`, refund spend identifiable but enforced by + consensus); both are acceptable. The two constructions and their trade-offs + are described in [Appendix: Bitcoin and Monero Adaptor-Signature Swap Primitives](../appendix/btc-xmr-adaptor-swap-primitives.md). Absent a measured reason to prefer otherwise (see Reliability), the simpler script-path refund is the recommended default. @@ -94,9 +126,11 @@ application to build on. the LEZ side). The Zcash refund deadline must strictly succeed the LEZ refund deadline by a margin documented to cover worst-case Zcash confirmation latency. ECDSA adaptor signatures (Lloyd Fournier construction) are an - acceptable alternative to HTLCs and are encouraged for cross-chain - unlinkability. Zcash shielded-pool (Sapling / Orchard) swaps are **out of - scope** for this RFP; see + acceptable alternative to HTLCs; unlike an HTLC an adaptor-signature + construction does not place the same hash value on both chains so the two + legs of a swap do not share a common on-chain identifier and are encouraged + for cross-chain unlinkability. Zcash shielded-pool (Sapling / Orchard) swaps + are **out of scope** for this RFP; see [Appendix: Zcash Atomic Swap Primitives](../appendix/zcash-atomic-swap-primitives.md) for the rationale. 5. The LEZ escrow program (Rust, Risc0) locks funds contingent on the @@ -262,8 +296,9 @@ application to build on. ### Soft Requirements -- An **adaptor-signature variant of the LEZ–ZEC pair** (replacing BIP-199 HTLCs) - for cross-chain unlinkability, as described in +- An **adaptor-signature variant of the LEZ–ZEC pair** (replacing BIP-199 + HTLCs), so that the two legs of a swap do not share a common on-chain + identifier for cross-chain unlinkability, as described in [Appendix: Zcash Atomic Swap Primitives](../appendix/zcash-atomic-swap-primitives.md). ## 👤 Recommended Team Profile