M2 R2 (Garden HTLC, C4 2025-11): the R1 rules work; the remaining gap is severity calibration

Source: M2 Round 2. Blind-audited Garden Finance cross-chain HTLC (EVM scope, 6 files), self-graded vs the C4 awarded set (1 Medium, 0 High) plus the in-repo Zellic V12 finding and the known-issues list.

Result: the two R1 detection rules converted would-be misses on the very next rep

• RULE 2 (an asymmetry is a finding until proven otherwise - LOCK it, never write "Fine") directly produced the ONE awarded Medium: UDA.sol imports SafeERC20 but initialize() calls raw token().approve() and ignores the return -> for USDT/BNB-class tokens this silently no-ops and funds get stuck. In R1 (Kinetiq) I dismissed exactly this class of asymmetry and lost 3 findings. Locking it paid off immediately.
• RULE 1 (draw the cross-domain fund-flow, then re-check every transfer/receive/fallback) produced the Zellic V12 headline: .transfer() 2300-gas DoS for contract recipients (the protocol supports EIP-1271 contract signers, so redeemer/initiator CAN be smart wallets). It also let me CONFIRM a correct design choice (Arb variants use ArbSys.arbBlockNumber()).
• RULE 3 (queue griefing/gas/ordering) correctly returned an honest negative - no unbounded queues in scope; I logged the negative instead of forcing a finding.

"Saw-but-dismissed" miss count went R1=3 -> R2=0. That was R1's biggest self-identified failure (discipline, not knowledge), and it closed.

NEW gap surfaced: severity calibration (both directions)

I caught the right sinks but mis-rated them: - UNDER-rated the awarded Medium as Low ("approve just reverts -> minor DoS") - missed that a false-returning token makes init silently succeed with zero allowance -> downstream transfer stuck -> PERMANENT fund loss = Medium. - OVER-rated the .transfer DoS as High when judges placed it below H/M (it is conditional on the recipient being an incompatible contract).

Rule (new): severity = worst REALISTIC end-state of the specific token/recipient, not the first failure mode imagined

For an ignored/!checked return value or a push transfer, branch on the concrete counterparty before assigning severity: - Does the failing call SILENTLY no-op? -> downstream state proceeds on a false premise -> stuck/lost funds -> Medium/High. - Does it HARD-REVERT? -> the tx just fails -> availability/DoS -> often Low, unless it strands already-committed funds. - Token/recipient behavior decides which branch: enumerate (reverts-on-failure vs returns-false; reverts-on-zero-approval like USDT; contract-recipient gas needs) BEFORE picking a severity. Do not assign severity from the first imagined failure mode.

Cross-refs

[[2026-06-29-cycle-m2-dual-domain-fundflow-and-asymmetry-discipline]] (R1 rules this rep validated). Anti-pattern [[saw-it-rated-minor-didnt-flag]] - this rep is the positive counter-example: locking the asymmetry caught the awarded finding.