Cases run: the five BTC cases from the Logos review map (gist) that have an entry point in the v0.2.5 release, each in both directions.

Candidate: Gateway v0.2.5, c99ff8ce86a7c5d2ad343d62232c843f627c9d0c.

Coverage review these results belong to: RFP-003 test-case coverage review of the Logos review map (2026-09-23); the previous run of the same cases is RFP-003 BTC test-case run on the v0.2.4 bundle (2026-09-23).

Run date: 2026-10-01

1. Setup

The five BTC cases that have an entry point in the release were executed on this machine against the v0.2.5 bundle (lez-swap-stack-v0.2.5-arm64, images pulled by tag, escrow ImageID c22d61fc…), Bitcoin Regtest and a local LEZ devnet on the fast timing profile, driven by the release’s scripts/node-e2e.py. Both directions were run for every case. Logs, scenario JSON and the results table are in available on request - ../../lez-swap-stack-v0.2.5-arm64/review-runs-20261001.

2. Results

3. Notes on the run

• The stack had been started on the default local profile; it was switched to fast with LEZ_TIMING_PROFILE=fast start.sh --quick, which recreates the two Nodes only. Right after that switch the local LEZ devnet stopped finalizing (the driver’s preflight reported the finalized height stuck at 36 for 300 s), the upstream freeze described in ../../deploy/README.md. Two preflights failed before any swap was opened; the chain was recreated with up.sh --fresh-lez, the market re-bootstrapped, and the batch restarted from the top. Every swap in the table above ran on that fresh chain and passed on its first attempt. The failed preflights are kept in review-runs-20261001/attempt0-frozen-chain.
• The forward BTC-REFUND-002 run was interrupted twice by the reviewer’s side, not the stack: once when the batch driver hit its two-hour session limit after the Maker leg had refunded and the Taker’s refund had just been admitted (…-a0-killed.log), and once when the batch was paused with down.sh while both legs were locked (…-a0-paused.log). The case was rerun from the start and passed. Both interrupted swaps resolved without the driver: 2e0890f9… finished its Bitcoin refund unattended and is refunded; 81db91bd… came back from the 34-minute stop with the Maker’s LEZ leg refunded by the Maker on its own and the Taker’s Bitcoin refund offered (refund_available), which in this scenario is an owner action the driver was no longer there to request. No swap failed.
• The batch was paused once between runs with down.sh and resumed with start.sh; the chain and the persisted swaps survived the stop, and no chain recreation was needed on resume.
• The recovery reused the two workarounds noted on the v0.2.4 run (sourcing release.env before up.sh --fresh-lez, chmod 0600 on the bundled lez-signer.key files) without checking whether v0.2.5 still needs them; up.sh in v0.2.5 still does not read release.env itself. Neither affects a first start.
• The runner’s freeze-recovery branch had never fired on the v0.2.4 run either: a shell bug read the wrong exit status, so a frozen chain was skipped past rather than recreated. It is fixed in review-runs-20261001/run-btc-cases.sh; the v0.2.4 recovery was done by hand, so that run’s results are unaffected.

4. Limits

These are driver-reported passes on a local API stack. They do not include the independent chain checks the gist attaches to its own records, they do not exercise the native Basecamp UI, and they are not public-network or security evidence. With these runs, every one of the five release-runnable BTC cases keeps its pass in both directions on the new candidate, so finding 1 in section 4 of the coverage review stays closed for those cases. BTC-CLAIM-001/002 and BTC-TIMING-001 were not run here: the first two need the reviewer’s patched driver from the gist, the third a funded public session.