Milestones M1, M3 and M6 are submitted. This report lists only the RFP hard requirements those milestones are expected to satisfy where the evidence on the v0.2.4 candidate is still short, and what would close each gap. Requirements that are adequately covered, or that belong to M2, M4, M5 or M7, are left out.
Candidate: Gateway v0.2.4, 98f492adff67bf62c22e04609f0810c196d6a0dc
Sources: RFP-003, Logos review map
| Milestone | Gaps | Of which critical |
|---|---|---|
| M1 · design packet | 2 | 0, both document-level |
| M3 · BTC leg | 8 | 2 |
| M6 · Maker and Taker apps | 4 | 1 |
Closed on 23 September: three BTC cases that the review map recorded as reverse-only now pass in both directions.
Severity:
Covers the write-up half of S7, the timelock rationale R6 and the refund-construction justification R7. All three design documents exist; the gaps are wording and one unproven parameter set.
| ID | Requirement | What exists | What is missing | Severity |
|---|---|---|---|---|
| S7 | Write-up: protocol design per chain, escrow design, atomicity argument, timelocks, assumptions, limitations (M1-1, M1-3) | Protocol design, escrow design, threat model and ADR 0050 at the candidate commit. | Old DLC-vector wording contradicts Gateway’s erratum; the promised ZEC ECDSA-adaptor note is absent; the accepted-signature-byte path is not named in the threat model. | gap |
| R6 | Timelocks account for block variance, congestion and drift; rationale documented (M1, validated in M3) | Parameter ADR and the three profile rules the Node enforces at start. Local fast profile exercised in all four refund runs. |
The corrected public profile has never run. BTC-TIMING-001 is prepared but NOT RUN; earlier public swaps predate the corrected profile. | gap |
Not flagged: R7 (script-path CSV chosen and justified in ADR 0009; every refund run relies on it), U7 sketch (IDL shape present; executable IDL is M2), M1-6 SDK surface (a publication-process decision, not an RFP requirement).
Covers F2, F5, F6, R1, R2, R4, R5 for the BTC pair, the BTC SDK (U1, S8), the Bitcoin node guide (U8), the BTC reference integration (S5) and the BTC demo set (D1). The 23 September run gave every release-runnable case a pass in both directions, so the remaining gaps are about what the cases do not assert, not about failures.
| ID | Requirement | What exists | What is missing | Severity |
|---|---|---|---|---|
| F2 | Cooperative claim is a key-path Taproot spend in standard form; BIP-340 adaptor signatures (M3-1, M3-3) | Happy, refund, restart and concurrent runs pass both directions. CSV refund maturity enforced. | No case decodes the claim witness, so “ordinary Taproot payment, no script footprint” is asserted nowhere. The cited DLC file lacks the required Schnorr vector; Gateway’s replacement suite awaits a Logos decision. | critical |
| R2 | After the first on-chain action the swap completes or refunds from local state and chain nodes only (shared, claimed by the BTC leg) | Design and chain-driven actors support it; restart cases resume from persisted state. | No case cuts Delivery and Chat after the lock. The review map asks for one named after-lock outage check with both terminal results and says not to infer it from a successful swap. | critical |
| R1 | Taker locks first; Maker must not lock until the Taker’s transaction is confirmed (M3-1) | Taker locks first in every run; BTC-REFUND-001 shows no Maker lock after cutoff; core rejects early lock in unit tests. | No case at the Bitcoin adapter boundary attempts an early Maker lock or asserts the confirmation wait. | gap |
| S1 | Escrow deployed and tested on LEZ testnet 0.2 (M3-4) | Earlier Testnet4 and official-LEZ runs; 12 of 19 claims exactly chain-verifiable. | All v0.2.4 evidence is Regtest and local devnet. Public runs predate the corrected timing profile; direction and wallet duties for the public route are unstated. | gap |
| U1 · S8 | BTC SDK exposes the full lifecycle with API docs and examples (M3-2) | SDK exercised indirectly by the Node runner in every case. | No case calls the SDK API; public API docs and lifecycle examples are not linked from the submission. | gap |
| D1 | Happy, refund and concurrent demo videos for BTC (M3-5) | All three behaviours recorded as JSON logs; ui-e2e.sh --record can produce videos. |
The three videos and their hashes are not linked on issue #123. Logs are not videos. | gap |
| U8 | Bitcoin Core testnet guide, self-hosted and public routes (M3-4) | Guide with both routes and public run records. | No fresh-machine documentation test; supported direction and wallet duties to be stated. | gap |
| F7 | Swaps support the native LEZ token and custom tokens via ATAs (owner unassigned, M2–M4) | Every BTC run uses the native token. | No custom-token run exists and no milestone owns it. Gateway is to name the test and its milestone. | decision |
Not flagged: F5 and F6 (both-complete and both-refund proven both
directions, plus the late-observed and never-included claim cases), R4 and
R5 (restart and overlap pass both directions; hard-kill and state-loss
variants remain shared M5 work), S5 (BTC reference integration complete),
P1 (compute units measured against the deployed v0.2.4 escrow in
docs/lez-compute-units.md, which the review map does not yet cite).
Covers U5, U6, S11 and the loadable-package half of S6. The BTC packages install, load and connect; the functional journeys and the ZEC flow are where evidence is short.