Confirmed and fixed in e9209f29. Thanks — this was a real gap, and I reproduced your case before fixing it:

thread '...' panicked at sv2/channels-sv2/src/target.rs:119:45:
attempt to add with overflow

Exactly as you described: both operands are finite so they pass the guard, f32::MAX × 60 ≈ 2.04e40 sits ~60× above u128::MAX, the as u128 cast saturates, and h_times_s + 1 overflows before max() can absorb it. The max(h_times_s, h_times_s + 1) was clearly meant as the saturation guard, but it only works in release.

The fix validates the derived product before the cast, with headroom for the + 1:

if !h_times_s.is_finite() || h_times_s >= u128::MAX as f64 {
    return Err(HashRateToTargetError::WorkOutOfRange);
}

I added a dedicated WorkOutOfRange variant rather than reusing NonFiniteInput — the headline case is representable-but-too-large, not non-finite, and reusing the existing name would misdescribe it. The enum is new in this PR, so no breaking change.

Three regression tests:

• work_exceeding_u128_is_rejected_not_saturated — your f32::MAX case
• non_finite_derived_work_is_rejected — a second route into the same gap: finite operands whose product overflows to +inf (f64::MAX at 1e-300 spm). Worth covering separately since it reaches the bad cast via +inf → u128::MAX rather than via saturation.
• work_just_below_the_limit_still_converts — guards against over-rejection and pins the boundary, so a future tightening is a visible change

I verified the first two are genuine regression guards rather than assuming it: with the new guard replaced by if false, both fail with the overflow panic; with it restored, all pass.

Gates (on 1.89, matching ci.yaml): 86 lib tests pass (83 + 3 new), clippy -p channels_sv2 --lib -- -D warnings clean, --no-default-features --features no_std clean, cargo fmt --check clean.

One note on severity, not to argue the fix but to calibrate it: overflow needs hashrate > ~5.67e36 H/s at 1 spm, roughly 22 orders of magnitude above a real S21 (~2e14 H/s). No honest miner reaches it — it takes a malformed or hostile OpenMiningChannel. So this is hostile-input hardening rather than a live bug. That said, I think the release-build behavior is the more concerning half: a silently garbage target is worse than a panic, and it's in the over-difficulty direction. Glad you caught it.

The derived-work validation in 58f6baf fixes the correctness issue I reported. I rechecked the exact f64 boundary, protocol-facing f32 edge cases, and both debug and release paths, and found no remaining numerical issue.

There is one separate blocking API-compatibility issue: HashRateToTargetError already exists as a public exhaustive enum in channels_sv2 7.0.0. Adding NonFiniteInput and WorkOutOfRange is therefore a SemVer-major change for downstream exhaustive matches, even if no current workspace caller matches it. This is the enum_variant_added failure reported by semver-check, so the claim that the enum is new/non-breaking is incorrect.

Please resolve this according to the project's release policy—either bump the major version or preserve the existing public enum surface—and update the PR's compatibility claim. Once that is resolved and CI is green, the numerical fix looks good to me.

You're right, and my compatibility claim was wrong — thanks for catching it. HashRateToTargetError is already public in the released 7.0.0 with DivisionByZero/NegativeInput, so both variants I added (NonFiniteInput in the first commit, WorkOutOfRange in the second) are enum_variant_added breaks for downstream exhaustive matches. I conflated "these variants are new in this PR" with "the enum is new," which isn't the same thing. semver-check is correctly failing; the other 14 jobs pass.

Also noting the SHA drifted: the fix is 58f6bafc after rebasing onto c1a79913, not the e9209f29 I cited earlier.

@plebhash @GitGab19 — this needs a release-policy call I don't want to make unilaterally. Three ways to resolve, and I'd rather implement your preference than guess:

1. Major-bump channels_sv2 to 8.0.0 in this PR. There's clear precedent (ae3741dd bump to 5.0.0, 89e5841d to 4.0.0, fd67587a major-bump mining_sv2), so this looks like the normal path — but a major bump for a hostile-input hardening fix seems like your call, not mine.
2. Add #[non_exhaustive] to the enum as well as the bump. Still breaking once, but it makes every future variant addition non-breaking. Worth doing now if you'd otherwise hit this again, though I'd note the enum is small and stable so the payoff is speculative.
3. Keep the existing public surface — drop both variants and route these rejections through DivisionByZero/NegativeInput. No bump, but a NaN hashrate reported as DivisionByZero is actively misleading, and the diagnostic clarity was most of the point of the PR. I'd rather not, but it's a legitimate choice if you want to avoid a major release right now.

My preference is 1, or 1+2 if you want the future-proofing. Happy to push whichever you pick.

On severity, for whatever it's worth to the decision: the overflow needs a declared hashrate above ~5.67e36 H/s (roughly 22 orders of magnitude past a real S21), so it's only reachable via a malformed or hostile OpenMiningChannel — not a live bug. The release-build behavior is the more interesting half, since it silently yields a garbage target in the over-difficulty direction rather than panicking.