rfp003 spec update

.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

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