Cross-chain sizing gaps a stable-value counter-leg makes sharper (timelock ordering, value-scaled burial, NFT value-at-risk)

[Zyrtnin]

Four protocol-level findings from the fourth security round on feat/erc20-usdc-leg. None is introduced by the ERC-20 work — but a stable-value counter-leg sharpens each one, because for the first time the swap states its own market value in a unit anyone can read.

Grouped because they share a root: sizing decisions that were made against a volatile-vs-volatile corridor.

1. The timelock ordering is inverted, and the option is now one-sided in a new way

The gate enforces rxd_refund_open + margin <= eth_timeout — so the leg claimed second carries the shorter deadline, the inverse of the canonical rule. In the window [rxd_open, eth_timeout] the maker can CSV-refund the Radiant covenant, wait for confirmation while p is still secret, and then claim the USDC. Both legs, deterministically.

This is a documented, accepted residual (ONE_SIDED_LOSS_TAKER), and the taker has no exit from BOTH_LOCKED. What the token leg changes is the economics: the maker now holds a costless put on the volatile asset struck in a stable unit, running the full window, with the option value unpriced. The BTC corridor's version of this option was two volatiles against each other.

Worth re-deciding rather than inheriting: invert to t_rxd_abs > eth_timeout + Δ, or price the option.

2. Value-scaled burial is enforced at claim time but not at setup

assess_claim_finality requires max(flat, value_scaled) burial, but the construct-time N-floor uses only the flat burial, and t_rxd is sized from a rxd_claim_burial_s that is likewise uncoupled.

So a value-bearing swap can construct cleanly and then, at reveal, find blocks_left < rxd_burial — a permanent SQUEEZED state where the maker's CSV refund can beat the taker's claim. Fix: use the same max(flat, value_scaled) in the N-floor and derive rxd_claim_burial_s from it.

3. NFT value-at-risk is declared, never cross-checked — and USDC makes it checkable

The under-statement guard is rxd-variant only. For nft, radiant_amount is carrier dust, so a 50,000-USDC NFT sale can declare value_at_risk_photons = 1000; value-scaled burial then collapses to flat, and a cheap Radiant reorg can reverse the taker's claim.

A stable counter-leg is precisely the case where the swap states its own value (terms.value_amount, 6-decimal USDC). Fix: for a token counter-leg require an explicit photons-per-base-unit rate and assert value_at_risk_photons >= value_amount * rate.

4. expected_locator does not bind the deadline to the negotiated term

EthLeg.fund asserts terms.eth_timeout_unix_s == self._eth_timeout_unix_s; expected_locator / verify_counterparty_funded do not. verify_funded then binds the on-chain immutable to that locator — so the cross-clock ordering gate can validate deadline A while the accepted contract carries deadline B.

The loss is liveness (a dead swap with the asset locked for a full t_rxd), not theft, but the invariant the whole ordering argument rests on is being checked against a number that is not the one on chain. Fix: replicate the fund() assertion inside expected_locator.

Also, minor: the Solidity constructor has no sanity floor

Erc20Htlc accepts timeout == 0 or in the past (claim reverts forever, refund() immediately callable) and hashlock == 0 (unclaimable). Off-chain this is caught only because each side compares against its own expected values — there is no absolute check anywhere. Two lines in the constructor would make the degenerate cases unrepresentable.

[Zyrtnin]

Finding 1 resolved: the direction IS inverted, and the "verified correct" note that contradicted this is itself self-contradictory

This sat unresolved because an internal note recorded the timelock direction as "VERIFIED CORRECT (no bug)" against Herlihy (arXiv 1801.09515). Three independent lines now agree with this issue, not with that note.

1. The standard construction

Alice holds the secret. Alice locks with the LONGER timeout; Bob locks with the SHORTER. Alice claims Bob's leg — the shorter one — revealing the secret, and Bob then claims Alice's longer-dated leg with time to spare.

The invariant underneath: the leg the secret-holder CLAIMS must expire before the leg the secret-holder LOCKED refunds. Otherwise the secret-holder waits out their own refund, takes their asset back, and still claims the counter leg.

Mapping here: maker holds p, locks RXD, claims the counter leg. Safety therefore needs counter_deadline < rxd_refund_opens.

2. What the code enforces

assert_timelock_margin: t_btc > t_rxd + margin. And eth_absolute_to_rxd_relative_blocks states it outright:

The RXD refund … must open strictly BEFORE the ETH deadline minus the full margin (the RXD/asset leg holds the SHORTER deadline; the ETH/counter leg the longer).

That is the inverse. And the margin is the attack window: in [rxd_refund_opens, eth_timeout] — at least margin wide by construction, ~7068 s on the measured policy — the maker refunds the covenant while p is still secret, then claims the counter leg. Both legs, deterministically, with no race and no counterparty recourse: the taker cannot claim the covenant without p, and cannot refund the counter leg until eth_timeout, which is later.

3. The cited rule, read carefully, says the same

The note states the Herlihy rule as:

the preimage-revealer/first-claimer's timelock must force the secret open before dependent refunds

The first-claimer is the maker, claiming the counter leg. "Force the secret open before dependent refunds" means the counter-leg deadline must precede the RXD refund — eth_timeout < rxd_refund_opens. The note then concludes "ETH/counter leg = LONGER refund", which is the opposite of the rule it just quoted. The principle was recorded correctly and applied backwards.

Not a consequence of HZ-1

Worth stating, since HZ-1 (#392) inverted the lock order: this is independent. Under the pre-HZ-1 order the maker still locked the leg with the shorter refund and claimed the leg with the longer one, so the same escape existed. The defect is in the timelock relation, not the lock sequence.

Status

Filed here as a documented, accepted residual (ONE_SIDED_LOSS_TAKER). That acceptance should be revisited, because it was made alongside a note asserting the direction was verified sound. An accepted residual is a decision; this one rested on a false premise, so the decision has not really been taken yet.

The suggested fix in the original finding — invert to t_rxd_abs > eth_timeout + Δ, or price the option — still looks right. Inverting is a protocol change touching sizing, the punctuality gate, the runners and the covenant's CSV, so it wants its own design pass rather than a patch.

I am not proposing a code change in this comment. Given how much rests on it, someone should check the derivation in §1 against the paper directly before anyone acts — including the possibility that I have it wrong too.

[Zyrtnin]

Design for the inversion is up as #535 — docs/plans/2026-08-30-invert-htlc-timelock-direction-design.md.

Tracked deliberately so the derivation can be checked; it is no use as a design if it sits in a working directory.

Headline from it: this is cheaper than it looks. CrossClockMargin's five components are already the correct budget — every one is time the taker needs after the reveal. The module's own docstring states the right rule ("the RXD refund must NOT open until the taker has had a stall-tolerant window") and the sizing note calls a fast RXD chain the safety-critical direction for exactly the right reason. So parts of this code reason correctly about the taker's post-reveal window while the top-level relation enforces the opposite, and the fix is predominantly a sign change rather than a new safety model.

Cost: t_rxd grows by ~2x margin (~3.9 h, ~47 Radiant blocks on the measured policy). The maker's asset is locked longer, which is the right allocation — the maker holds the free option today.

Two things called out as NOT settled: the Herlihy derivation itself (I have not read the paper; §1 is from the standard construction), and the punctuality gate, which inverts from "did the covenant confirm late" to "did it confirm early" and deserves its own derivation rather than a mechanical sign flip.

[Zyrtnin]

Finding 1 is now VERIFIED against the paper, not derived

The open question on this issue was whether my derivation matched Herlihy (arXiv:1801.09515). I fetched and read it. It does, and the paper's own motivating example settles it with concrete numbers.

Verbatim, §1 MOTIVATION:

• Alice creates a secret s, h = H(s), and publishes a contract on the alt-coin blockchain with hashlock h and timelock 6∆ in the future, to transfer her alt-coins to Bob.
• When Bob confirms that Alice's contract has been published … he publishes a contract on the Bitcoin blockchain with the same hashlock h but with timelock 5∆ in the future, to transfer his bitcoins to Carol.
• When Carol confirms that Bob's contract has been published … she publishes a contract on the automobile title blockchain with the same hashlock h, but with timeout 4∆ in the future, to transfer her Cadillac's title to Alice.
• When Alice confirms that Carol's contract has been published, she sends s to Carol's contract, acquiring the title and revealing s to Carol.

Alice is the secret generator. The leg Alice LOCKED carries 6∆ — the longest. The leg Alice CLAIMS carries 4∆ — the shortest. Timeouts DECREASE along the propagation path, and Lemma 4.13 states the gap:

the timeout on each arc (u, v) is later by at least ∆ than the timeout on each arc (v, w).

Mapping to this corridor

The maker generates p, locks the RXD covenant, and claims the counter leg. By the rule above:

required:  t_rxd  >  counter_deadline + Δ     (the locked leg is the LONGEST)
enforced:  t_btc  >  t_rxd + margin           (assert_timelock_margin, swap_coordinator.py:679)
           rxd_refund_opens < eth_timeout − margin   (eth_rxd_timelock.py:185)

Inverted, and off by 2 × margin. The one caveat I flagged is now closed: this is no longer three derivations that could share a misreading — it is the paper's own worked example.

Worth recording how the wrong version survived. An internal note quoted the rule correctly — "the first-claimer's timelock must force the secret open before dependent refunds" — and then concluded the opposite. Every later reader, including me two days ago, took the confident "VERIFIED CORRECT (no bug)" at face value and stopped. A correct principle with a backwards conclusion attached is harder to catch than a plainly wrong one.

Proceeding with the inversion per the design in docs/plans/2026-08-30-invert-htlc-timelock-direction-design.md. The "accepted residual" label should be considered void: it was chosen against a premise now shown false.

One thing the paper does NOT settle, and I am not treating as verified: the punctuality gate's inversion (§5 of the design). Herlihy assumes contracts are published in sequence with observed confirmation; it says nothing about a relative CSV whose clock starts at covenant mining. That still wants its own derivation.

[Zyrtnin]

§5 of the design is now derived, and it changes more than the gate

The design doc flagged the punctuality gate as the part I was least confident in. Working through the migration reached it, and the answer is bigger than a sign flip: the SIZING ANCHOR inverts too, and the two runners already disagree about it.

scripts/eth_swap_run.py:593       expected_rxd_lock_time_unix_s = now + max_covenant_confirm_wait_s
scripts/eth_swap_two_host.py:437  expected_rxd_lock_time_unix_s = now

The derivation

t_rxd is committed in the covenant script BEFORE broadcast, and the refund opens at
actual_confirm_time + t_rxd. The invariant now requires:

actual_confirm + t_rxd  >=  eth_timeout + margin

Sizing computes t_rxd from an ASSUMED confirm time. So:

• confirm LATER than assumed → the refund opens later → more margin → safe, at a liveness cost to the maker;
• confirm EARLIER than assumed → the refund opens sooner → the invariant breaks.

Under the OLD relation (rxd_refund_opens < eth_timeout − margin) the conservative anchor was the latest plausible confirm, which is what eth_swap_run.py uses. Under the inverted relation the conservative anchor is the earliest — now.

So eth_swap_run.py's anchor becomes unsafe under the inversion, and eth_swap_two_host.py's is already correct. That divergence exists today and nothing reconciles it.

The gate follows: it inverts from "did the covenant confirm LATER than assumed" to "did it confirm EARLIER" — and once sized from now, an earlier confirm is only reachable through clock skew, so it largely collapses into asserting the actual confirm is at or after the sizing anchor.

A second consequence, also not in the design

A small t_rxd is no longer expressible at all. The invariant needs t_rxd > t_btc + margin with t_btc >= 1, so any t_rxd <= margin cannot be constructed. The burial-band tests used values down to 6.

That is not a fixture problem: the margin check now subsumes part of what gate 3b caught, and 3b becomes unreachable for those values. Worth deciding deliberately whether 3b keeps a distinct job.

Migration status

Draft #559. Source inversion complete and verified; test_swap_coordinator is 58 → 25 failures, with _terms/_eth_terms now DERIVING t_btc from t_rxd so no call site hand-maintains the relation. tests/test_timelock_ordering_invariant.py states the rule once, with Herlihy's own 6∆/5∆/4∆ example parametrised across scales.

~400 failures remain across 13 files. I am flagging these two findings before going further, because both change what the migration should assert — the anchor one in particular means a runner needs fixing, not just tests.