Of the eleven findings we confirmed against v0.2.4, v0.2.5 closes one, closes most of a second, partly addresses two, and leaves seven open. Our v0.2.5 audit also filed four high-severity findings where the v0.2.4 audit had none. None of those is a regression: the code each one cites is the same in both releases, and the later audit read it more deeply.
Two of our own verdicts in the v0.2.5 report are wrong and are corrected in section 6: it passes F4 although the two F4 findings from v0.2.4 are not fixed, and it says no refund or concurrency recordings exist although the v0.2.5 release carries them for Bitcoin.
Reports compared:
98f492ad (tag
v0.2.4). Findings are written /1 to /15 below.refs/tags/v0.2.5 , commit c99ff8ce (tag v0.2.5).
Findings are written #1 to #16 below.Comparison date: 2026-10-02
Each v0.2.4 finding was matched to the v0.2.5 finding or trace row covering
the same requirement, and each claimed change was then checked against
git diff 98f492ad v0.2.5 (44 files, ten commits, #90 to #101). A finding is
called fixed only where the diff changes the code it cites; it is called open
where that code is unchanged, whether or not the v0.2.5 report raises it
again. The four failing tests of the v0.2.4 report were then re-run on the
v0.2.5 tree (section 7).
| v0.2.4 report | v0.2.5 report | |
|---|---|---|
| Findings | 15 | 16 |
| Confirmed / disputed / unconfirmed | 11 / 3 / 1 | 11 / 4 / 1 |
| High / medium / low / info | 0 / 6 / 8 / 1 | 4 / 10 / 2 / 0 |
| Findings backed by a failing test | 4 (/1, /2, /3, /15) |
3 (#4, #15, #16) |
The two rows of counts are not comparable as a measure of progress. Ten requirements changed verdict between the reports with no change to the code behind them (section 6), so the difference in the totals mostly reflects how the two audits read the same tree.
What happened to the eleven confirmed v0.2.4 findings:
| Outcome | Findings |
|---|---|
| Fixed | /3 |
| Mostly fixed, one case left | /15 |
| Partly addressed | /4, /9 |
| Open | /1, /2, /6, /7, /10, /13, /14 |
/3, R3: one missing route-health probe binary stopped the Maker for every
chain. Fixed by #96 (e6556916). ProcessRouteHealthProbe::from_json_bytes
now keeps a command whose executable is missing or changed and records its
route as unverified; the daemon names those routes at startup and the route
reads unavailable until the executable is installed. The initial route-health
reconciliation is best-effort, and a failed periodic reconciliation is logged
and retried on the next tick; it used to stop the daemon. The commit adds 117
lines to crates/maker-node/tests/route_health.rs. Our v0.2.5 audit treats
this path as working (trace row R3 and the text of #5), and the v0.2.4
failing test now passes (section 7).
/15, F6: the coordinator lost funding regressions and accepted claims
with a leg absent or underconfirmed. Mostly fixed by #97 (8f24413a). The
coordinator now keeps a confirmed flag per leg, updates the taker flag on
every observation and removal, and both claim entry points refuse unless both
legs are funded and confirmed (both_legs_funded,
crates/swap-core/src/lib.rs). The four v0.2.4 tests now pass (section 7).
One ordering is left and is filed as #15: a maker depth
regression observed while the phase is TakerLockReorged returns through the
same-transaction fallback without clearing the maker flag, so reconfirming
the taker alone restores claim authority.
/4, R3: the packaged Maker never reports an unavailable chain. Partly
addressed by #96. The installer now ships
packaging/systemd/route-health.json.example and
packaging/systemd/README.md, which explains how to configure probes. The
packaged lez-maker-node.json.example still does not pass
--route-health-config, so a Maker installed from the defaults still reports
every route as disabled and detects no outage. Our v0.2.5 audit did not
re-examine this.
/9, D1: only Bitcoin happy-path footage existed. Partly addressed. The
v0.2.5 release carries TakerSellsForeign-happy.mp4,
TakerSellsForeign-maker-refund.mp4 and TakerSellsForeign-concurrent.mp4
(listed by gh release view v0.2.5 on 2026-10-02), and media/README.md at
the tag describes them. By name that is three of the nine required
recordings, all Bitcoin and all in one direction. There are none for Monero
or Zcash.
Also new in v0.2.5, and not tied to a v0.2.4 finding: the e2e driver now asserts that the cooperative claim is a key-path spend and that the Maker does not lock early (#98), completes a swap with Chat and Delivery cut after the lock (#99), and runs both late-lock scenarios in both directions (#101). The v0.2.5 trace cites the first two as evidence for F2 and R2.