[LOW] Nothing checks the maker's own claim address for a freeze before the maker locks RXD (was: MEDIUM, on a stale premise)

[Zyrtnin]

Round 5, fresh-eyes brief. MEDIUM.

assert_not_frozen_before_reveal has exactly one call site in the whole tree: Erc20HtlcLeg.claim (erc20_leg.py:206). It is never called from verify_funded or EthLeg.verify_counterparty_funded — the gate the coordinator runs before telling the maker to lock RXD.

A maker can therefore verify-and-lock RXD against an HTLC or claimant that is already frozen. The secret stays safe (claim raises PreRevealAbort), but the RXD is committed into the covenant for the full t_rxd CSV window before the maker learns the swap can never complete — for a condition that one already-implemented, already-tested read would have caught for free.

docs/solutions/design-decisions/usdc-corridor-is-issuer-trusted-not-trustless.md documents the reveal-time check-then-reveal race as an accepted residual, but says nothing about this earlier, cheaply avoidable case. It reads as an oversight rather than a deliberate trade.

Fix

Check contract + refundee before funding, and contract + claimant before claiming. (Round 5 narrowed the pre-claim gate to the claimant — the refundee cannot affect a claim — so the pre-fund gate is now the only place a frozen refundee would be caught at all.)

Note this is the reachability class again: the capability exists, is tested, and is not called where it would do the most good.

[Zyrtnin]

The premise here is inherited from a stale docstring, and the described fix would have been placed on the wrong side of the protocol. Posting the trace rather than just closing, because the cause is the interesting part.

What the issue read

verify_funded or EthLeg.verify_counterparty_funded — the gate the coordinator runs before telling the maker to lock RXD

That came from eth_leg.py:253, which said:

The taker deploys the ETH HTLC FIRST and the maker locks RXD SECOND

What the code does

HZ-1 (#392) inverted that. The maker locks the Radiant asset FIRST: taker_funds_btc runs pre_btc_lock_check, whose step 5 taker_verify_asset_funding reads the covenant off the Radiant chain and fails closed. post_asset_lock_revalidate requires state BTC_LOCKED and is where verify_counterparty_funded runs.

So by the time that gate executes, the RXD is already committed. It does not guard the lock; it guards the reveal. The coordinator says as much at swap_coordinator.py:1888 — refusing there "leaves the maker at BTC_LOCKED with its CSV asset refund still open, so the fail-closed direction costs a swap, never an asset."

That is also the outcome assert_not_frozen_before_reveal already produces in claim, via PreRevealAbort. Adding a second freeze read at verify_counterparty_funded would fail marginally earlier for the same result — while adding an RPC read on the path into BOTH_LOCKED, where a transient failure would cost an honest swap. That is precisely the failure #479 just fixed, so I am not adding it.

The class, not the instance

The stale claim was in nine places in src/, including the module-level protocol summary and maker_verify_counter_funding, whose docstring contradicted itself two paragraphs apart — opening with "BEFORE the maker locks the asset" and then stating "The runbook is MAKER-locks-asset-FIRST". All nine are corrected, and tests/test_protocol_lock_ordering_docs_are_current.py now scans shipped source for the pre-HZ-1 phrasings (verified by planting the sentence and watching it fail).

Same shape as #505: a stale in-repo sentence read as evidence about current behaviour. Prose describing a protocol is load-bearing when reviewers reason from it, so it now gets a scanner.

What survives

One narrow residual, much smaller than filed: before the maker broadcasts the covenant, nothing checks whether the maker's own claim address is frozen. The contract cannot be checked then — it does not exist yet — but that address can. It would need a new maker-side pre-lock entry point and runner wiring, so it is a design change rather than a call-site fix. Retitling and leaving open at LOW for that piece alone.