After liquidation the opposite side portfolio cannot be closed when whole market is resolved

[julian-osec]

When closing account in a resolved market, its calculations don't account for A-factor, so several last closing accounts of such market would fail to be closed due to insufficient asset.oi_eff_..._q

Example scenario for two accounts:

1. Deposit long and short accounts
2. Long and short open a trade for 100k
3. Long account accrues some maintenance fee and gets liquidated by close_q = 25k. asset.a_short becomes 75%
4. Market gets into resolved state by admin invoking resolve_market_not_atomic
5. Short account attempts to call close_resolved_account_not_atomic and ends up failing with CounterUnderflow due to the fact that asset.oi_eff_short_q=75k, while the actual leg.basis_pos_q=100k and it is never scaled by a_basis

In more realistic scenario most users on that side would quickly drain available stored OI until the last ones are left with insufficient OI to fulfil their closing legs basis_pos_q.

Test for `v16_spec_tests.rs`

#[test]
fn v16_fuzz_regression_drain_only_residual_leg_underflows_resolved_close() {
    let (mut header, mut markets) = market_fixture(1, 1);
    header.config.initial_margin_bps = V16PodU64::new(500);
    header.config.maintenance_margin_bps = V16PodU64::new(250);
    header.config.max_price_move_bps_per_slot = V16PodU64::new(100);

    let mut long_header = account_fixture(1, 213);
    let mut short_header = account_fixture(1, 214);
    let stranded_q = 10_751 * POS_SCALE;
    let residual_q = POS_SCALE;

    {
        let mut market = MarketGroupV16ViewMut::new(&mut header, &mut markets);
        let mut long = PortfolioV16ViewMut::new(&mut long_header);
        let mut short = PortfolioV16ViewMut::new(&mut short_header);
        market.deposit_not_atomic(&mut long, 1_000).unwrap();
        market.deposit_not_atomic(&mut short, 1_000).unwrap();
        market
            .execute_trade_with_fee_loss_stale_scoped_not_atomic(
                &mut long,
                &mut short,
                TradeRequestV16 {
                    asset_index: 0,
                    size_q: signed_q(stranded_q),
                    exec_price: 1,
                    fee_bps: 0,
                },
            )
            .unwrap();
    }

    {
        let mut market = MarketGroupV16ViewMut::new(&mut header, &mut markets);
        let mut long = PortfolioV16ViewMut::new(&mut long_header);
        market
            .rebalance_reduce_position_not_atomic(
                &mut long,
                RebalanceRequestV16 {
                    asset_index: 0,
                    reduce_q: stranded_q - residual_q,
                },
            )
            .unwrap();
    }

    let asset = markets[0].engine.asset.try_to_runtime().unwrap();
    let short_leg = short_header.legs[0].try_to_runtime().unwrap();
    assert_eq!(asset.oi_eff_long_q, residual_q);
    assert_eq!(asset.oi_eff_short_q, residual_q);
    assert_eq!(asset.mode_short, SideModeV16::DrainOnly);
    assert_eq!(short_leg.basis_pos_q, -signed_q(stranded_q));

    {
        let mut market = MarketGroupV16ViewMut::new(&mut header, &mut markets);
        market
            .resolve_market_not_atomic(market.header.current_slot.get())
            .unwrap();
    }

    let mut market = MarketGroupV16ViewMut::new(&mut header, &mut markets);
    let mut short = PortfolioV16ViewMut::new(&mut short_header);
    market.validate_shape().unwrap();
    short.validate_with_market(&market.as_view()).unwrap();

    assert_eq!(
        market
            .close_resolved_account_not_atomic(&mut short, 0)
            .map(|_| ()),
        Err(V16Error::CounterUnderflow),
        "fuzz regression: resolved close tries to subtract the full stranded \
         DrainOnly leg from the one-lot residual short OI"
    );
}

[aeyakovenko]

Clean-room confirmed against the real SBF for percolator-prog da64be639168b496833dd4c701607a94fcb06b6c (engine 143e68c4917ed0400a27b952f036a5677047cd84) through a Meta controller-owned market in LiteSVM.

Public sequence: two users deposit 1,000,000 each and open a balanced POS_SCALE / 10 trade; the long owner invokes RebalanceReduce for half its own leg. Both oi_eff_long_q and oi_eff_short_q become opened_q / 2, while the untouched short still has raw basis_pos_q = -opened_q (and remains Normal at this reduction ratio). Futarchy then invokes the normal controller ResolveMarket. The untouched short's fully formed resolved close, with valid clean destination/vault accounts, fails with custom error 25.

This is persistent and ordering-independent: each failed short close rolls back atomically; the reducer can close its exact residual leg and receive its payout; afterward both the short owner and an external permissionless cranker still hit the same failure, while the victim collateral remains in the canonical vault.

PR #100 does not cover this state. Its legacy resolved migration triggers only when the leg's side effective OI is already zero. Here effective OI is nonzero but smaller than raw basis, so clear_resolved_close_leg -> kernel_clear_leg still subtracts the full basis_pos_q.abs() and underflows. The resolved clear needs to consume the leg's effective/A-scaled OI contribution, with aggregate OI/loss-weight and payout invariants preserved. This is a real public lifecycle DoS, not a duplicate of the zero-OI residue case.

[aeyakovenko]

Additional clean-room confirmation found a distinct public route to the same raw-basis/effective-OI terminal underflow.

Meta reproduction: aeyakovenko/percolator-meta@9c75c9d, branch agent/real-dos-bilateral-zero-oi-terminal, test e2e_social_loss_then_bilateral_close_has_a_bounded_terminal_exit.

This variant does not use RebalanceReduce to create the mismatch:

1. a solvent long opens 20 against a solvent short, then 1 against a small funded short;
2. an honest mark bankrupts the small short and B settlement reduces effective long OI from 21 to 20 while the winner retains raw basis 21;
3. the solvent pair closes the remaining matched 20 bilaterally;
4. OI becomes (0,0), but the winner retains normal-epoch basis 1 and stored_pos_count_long == 1.

Auto-crank makes no rank progress; FinalizeResetSide is a byte-no-op because the side is Normal; trade, RebalanceReduce, recovery forfeit, force-close, and resolved close cannot clear it. The winner retains all 100,000 deposited atoms and is the sole resolved payout blocker.

This is the same underlying issue reported here: teardown subtracts raw basis_pos_q after aggregate effective OI has already been reduced. It is not fixed by the unilateral zero-OI reset in engine #118/program #219; their real SBF fails this probe identically. Treat this as added public coverage for #132, not a separate finding.

[aeyakovenko]

Reconfirmed against the current Meta pins, not only the older clean-room pair.

• Meta draft: [REAL DoS] Reproduce resolved raw-basis OI terminal lock percolator-meta#402
• Exact Meta parent: c139a15
• RED commit: 6ae424775e478f9044f63099f1130bdee0aea765
• Wrapper: 557f15b63c7a5f9e058a2c384ca8728829dc2b63
• Engine: e3ea7251ed75f0111ba3cf5a4b87961f6c7cca63
• Real SBF SHA-256: 74ce6b85576bcbcb7596fdc7a774ff92661853d50ca9eb9475fcba7b1b7f40a4

The public LiteSVM path still reaches zero bilateral effective OI with one normal-epoch raw-basis survivor. Every live/Recovery continuation fails or makes no rank progress; resolved close then fails with one payout blocker and 100,000 atoms of independent principal trapped in the canonical vault. No upstream GREEN was found, so Meta #402 remains a RED blocker pending an engine fix for this issue.