LP Vault dual-domain redemption deadlock permanently freezes user capital on resolved markets

[v1ktorrr0x]

LP Vault dual-domain redemption deadlock permanently freezes user capital on resolved markets

Impact

Direct loss of funds or permanent freezing of funds.

On market resolution, any LP whose position spans both backing domains of an asset cannot redeem their capital. Both redemption routes reject with counter underflow, rebalancing is permanently locked, and market teardown fails closed.

Description

The redemption handler enforces an asymmetric execution model where shares are priced across combined domain capacity but redeemed against a single domain:

let available_principal = lp_vault_combined_available_principal_atoms(&group, ..., registry.domain, &ledger_data, &sibling_ledger_data)?;
let nav = lp_vault_combined_nav_atoms(&group, ..., registry.domain, registry.fee_share_bps, &ledger_data, &sibling_ledger_data)?;
let atoms_out = percolator::lp_vault::lp_atoms_for_redemption(redemption.shares, registry.total_lp_shares_outstanding, nav)?;

When a user redeems, atoms_out reflects both Domain 0 and Domain 1 principal. However, execution requires selecting one source_domain:

if principal_portion > ledger.total_principal_atoms {
    return Err(PercolatorError::EngineCounterUnderflow.into());
}

If the redemption size exceeds either individual domain pot, execution fails on both domains.

Rebalancing between domains is restricted to Live markets:

let (cfg, mode, configured_slots, _) = state::read_market_config_mode_and_capacity(&market_ai.try_borrow_data()?)?;
if mode != MarketModeV16::Live {
    return Err(PercolatorError::EngineLockActive.into());
}

Once a market resolves, mode == Resolved. Rebalancing cannot consolidate the pots, redemption requests cannot be fulfilled, and CloseLpVault fails because shares remain outstanding.

Not the same as LP-VAULT-REDEEM-BUG

• That issue concerned valid_liened_backing_num zero-OI calculations.
• This failure is an arithmetic partition deadlock across dual-domain backing ledgers.
• The lock triggers on completely flat, resolved markets with zero active trader open interest.

On cancelling redemption requests

• Cancelling via CancelRedemption only returns the unburned shares to the user.
• Re-requesting redemption re-encounters the exact same single-domain liquidity exhaustion.

Proof of Concept

Target files:

• src/v16_program.rs: handle_execute_redemption and handle_rebalance_lp_vault_backing

Run command:
cargo test --test audit_poc_suite test_poc_vuln_01_lp_vault_dual_domain_redemption_deadlock -- --nocapture

#[test]
fn test_poc_vuln_01_lp_vault_dual_domain_redemption_deadlock() {
    install_clock_stub();

    let admin = TestAccount::new(Pubkey::new_unique(), Pubkey::new_unique(), 0).signer();
    let mut market = TestAccount::new(
        Pubkey::new_unique(),
        program_id(),
        state::market_account_len_for_capacity(1).unwrap(),
    ).writable();
    let mut mint = TestAccount::new_with_data(Pubkey::new_unique(), spl_token::ID, make_mint_data(1_000_000));
    let mint_key = mint.key;

    // 1. Initialize market
    run_ix(
        Instruction::InitMarket {
            max_portfolio_assets: 1,
            h_min: 0,
            h_max: 10,
            initial_price: 100,
            min_nonzero_mm_req: 1,
            min_nonzero_im_req: 2,
            maintenance_margin_bps: 10_000,
            initial_margin_bps: 10_000,
            max_trading_fee_bps: 10_000,
            trade_fee_base_bps: 0,
            liquidation_fee_bps: 0,
            liquidation_fee_cap: 0,
            min_liquidation_abs: 0,
            max_price_move_bps_per_slot: 10_000,
            max_accrual_dt_slots: 1,
            max_abs_funding_e9_per_slot: 0,
            min_funding_lifetime_slots: 1,
            max_account_b_settlement_chunks: 1,
            max_bankrupt_close_chunks: 1,
            max_bankrupt_close_lifetime_slots: 100,
            public_b_chunk_atoms: percolator::MAX_VAULT_TVL,
            maintenance_fee_per_slot: 0,
        },
        &mut [&mut admin.clone(), &mut market, &mut mint],
    ).unwrap();

    let (registry_pda, registry_bump) = state::derive_lp_vault_registry(&program_id(), &market.key);
    let (lp_mint_pda, _) = state::derive_lp_vault_mint(&program_id(), &market.key);
    let (escrow_pda, _) = state::derive_lp_escrow(&program_id(), &market.key);
    let (v_auth, _) = vault_authority(&market);
    let vault_ata = canonical_vault_ata(&v_auth, &mint_key);

    let redeemer = TestAccount::new(Pubkey::new_unique(), Pubkey::new_unique(), 0).signer();
    let (redemption_pda, redemption_bump) = state::derive_lp_redemption(&program_id(), &registry_pda, &redeemer.key);

    let (domain0_ledger_pda, _) = state::derive_lp_backing_ledger(&program_id(), &market.key, 0);
    let (domain1_ledger_pda, _) = state::derive_lp_backing_ledger(&program_id(), &market.key, 1);

    let mut ledger0 = TestAccount::new(domain0_ledger_pda, program_id(), state::backing_domain_ledger_account_len()).writable();
    let mut ledger1 = TestAccount::new(domain1_ledger_pda, program_id(), state::backing_domain_ledger_account_len()).writable();

    // Set Market to Resolved Mode (mode == 1, c_tot = 0, materialized_portfolio_count = 0)
    {
        let mut market_data = market.data.clone();
        let (mut cfg, group) = state::market_view_mut(&mut market_data).unwrap();
        cfg.collateral_mint = mint_key.to_bytes();
        group.header.mode = 1; // Resolved
        group.header.vault = percolator::V16PodU128::new(100_000);
        group.header.c_tot = percolator::V16PodU128::new(0);
        group.header.materialized_portfolio_count = percolator::V16PodU64::new(0);
        group.header.source_fresh_backing_total_num = percolator::V16PodU128::new(100_000 * BOUND_SCALE);

        let asset_market_id = group.markets[0].engine.asset.market_id.get();

        let mut b0 = group.markets[0].engine.backing_long.try_to_runtime().unwrap();
        b0.market_id = asset_market_id;
        b0.expiry_slot = constants::LP_VAULT_BACKING_EXPIRY_SLOT;
        b0.status = BackingBucketStatusV16::Fresh;
        b0.fresh_unliened_backing_num = 60_000 * BOUND_SCALE;
        group.markets[0].engine.backing_long = percolator::BackingBucketV16Account::from_runtime(&b0);

        let mut s0 = group.markets[0].engine.source_credit_long.try_to_runtime().unwrap();
        s0.fresh_reserved_backing_num = 60_000 * BOUND_SCALE;
        s0.credit_rate_num = CREDIT_RATE_SCALE;
        group.markets[0].engine.source_credit_long = percolator::SourceCreditStateV16Account::from_runtime(&s0);

        let mut b1 = group.markets[0].engine.backing_short.try_to_runtime().unwrap();
        b1.market_id = asset_market_id;
        b1.expiry_slot = constants::LP_VAULT_BACKING_EXPIRY_SLOT;
        b1.status = BackingBucketStatusV16::Fresh;
        b1.fresh_unliened_backing_num = 40_000 * BOUND_SCALE;
        group.markets[0].engine.backing_short = percolator::BackingBucketV16Account::from_runtime(&b1);

        let mut s1 = group.markets[0].engine.source_credit_short.try_to_runtime().unwrap();
        s1.fresh_reserved_backing_num = 40_000 * BOUND_SCALE;
        s1.credit_rate_num = CREDIT_RATE_SCALE;
        group.markets[0].engine.source_credit_short = percolator::SourceCreditStateV16Account::from_runtime(&s1);

        state::write_wrapper_config(&mut market_data, &cfg).unwrap();
        market.data = market_data;

        let mut prof = state::read_asset_oracle_profile(&market.data, 0).unwrap();
        prof.backing_bucket_authority = registry_pda.to_bytes();
        state::write_asset_oracle_profile(&mut market.data, 0, &prof).unwrap();
    }

    // Initialize Backing Ledgers (Domain 0: 60k, Domain 1: 40k)
    let ledger0_data = state::BackingDomainLedgerAccountV16 {
        market_group: market.key.to_bytes(),
        authority: registry_pda.to_bytes(),
        total_principal_atoms: 60_000,
        total_deposited_atoms: 60_000,
        total_principal_withdrawn_atoms: 0,
        total_earnings_atoms: 0,
        total_earnings_withdrawn_atoms: 0,
        last_observed_bucket_earnings_atoms: 0,
        cumulative_loss_atoms: 0,
        cumulative_recovery_atoms: 0,
        last_observed_unavailable_principal_atoms: 0,
        domain: 0,
        _padding: [0u8; 14],
    };
    state::init_backing_domain_ledger(&mut ledger0.data, &ledger0_data).unwrap();

    let ledger1_data = state::BackingDomainLedgerAccountV16 {
        market_group: market.key.to_bytes(),
        authority: registry_pda.to_bytes(),
        total_principal_atoms: 40_000,
        total_deposited_atoms: 40_000,
        total_principal_withdrawn_atoms: 0,
        total_earnings_atoms: 0,
        total_earnings_withdrawn_atoms: 0,
        last_observed_bucket_earnings_atoms: 0,
        cumulative_loss_atoms: 0,
        cumulative_recovery_atoms: 0,
        last_observed_unavailable_principal_atoms: 0,
        domain: 1,
        _padding: [0u8; 14],
    };
    state::init_backing_domain_ledger(&mut ledger1.data, &ledger1_data).unwrap();

    // Initialize LP Registry & Redemption Request
    let mut registry_acc = TestAccount::new(registry_pda, program_id(), state::lp_vault_registry_account_len()).writable();
    let reg_data = state::LpVaultRegistryV16 {
        market_group: market.key.to_bytes(),
        lp_mint: lp_mint_pda.to_bytes(),
        total_lp_shares_outstanding: 100_000,
        insurance_fee_snapshot_atoms: 0,
        fee_distribution_total_atoms: 0,
        epoch: 0,
        redemption_cooldown_slots: 0,
        fee_share_bps: 10_000,
        oi_reservation_threshold_bps: 0,
        domain: 0,
        paused: 0,
        version: constants::LP_VAULT_VERSION,
        bump: registry_bump,
        mint_bump: 255,
        _padding: [0u8; 6],
        _reserved: [0u8; 16],
    };
    state::init_lp_vault_registry(&mut registry_acc.data, &reg_data).unwrap();

    let mut redemption_acc = TestAccount::new(redemption_pda, program_id(), state::lp_redemption_account_len()).writable();
    let red_data = state::LpRedemptionV16 {
        registry: registry_pda.to_bytes(),
        redeemer: redeemer.key.to_bytes(),
        shares: 99_000,
        request_slot: 1,
        version: constants::LP_VAULT_VERSION,
        bump: redemption_bump,
        _padding: [0u8; 6],
    };
    state::init_lp_redemption(&mut redemption_acc.data, &red_data).unwrap();

    let mut lp_mint_acc = TestAccount::new_with_data(lp_mint_pda, spl_token::ID, make_mint_data(100_000)).writable();
    let mut escrow_acc = TestAccount::new_with_data(escrow_pda, spl_token::ID, make_token_data(lp_mint_pda, registry_pda, 99_000)).writable();
    let mut vault_token_acc = TestAccount::new_with_data(vault_ata, spl_token::ID, make_token_data(mint_key, v_auth, 100_000)).writable();
    let mut vault_auth_acc = TestAccount::new(v_auth, Pubkey::new_unique(), 0);
    let mut redeemer_dest_acc = TestAccount::new_with_data(Pubkey::new_unique(), spl_token::ID, make_token_data(mint_key, redeemer.key, 0)).writable();
    let mut token_prog = TestAccount::new(spl_token::ID, Pubkey::new_unique(), 0).executable();
    let mut cranker = TestAccount::new(Pubkey::new_unique(), Pubkey::new_unique(), 0).signer().writable();

    // ── STEP 1: Attempt ExecuteRedemption against Domain 0 ──────────────────────
    let res_domain0 = run_ix(
        Instruction::ExecuteRedemption { domain: 0 },
        &mut [
            &mut cranker,
            &mut market,
            &mut registry_acc,
            &mut redemption_acc,
            &mut lp_mint_acc,
            &mut escrow_acc,
            &mut vault_token_acc,
            &mut vault_auth_acc,
            &mut ledger0,
            &mut redeemer_dest_acc,
            &mut token_prog,
            &mut ledger1,
        ],
    );
    assert_eq!(
        res_domain0,
        Err(ProgramError::Custom(PercolatorError::EngineCounterUnderflow as u32)),
        "ExecuteRedemption against domain 0 must fail with EngineCounterUnderflow (Custom(25))"
    );

    // ── STEP 2: Attempt ExecuteRedemption against Domain 1 ──────────────────────
    let res_domain1 = run_ix(
        Instruction::ExecuteRedemption { domain: 1 },
        &mut [
            &mut cranker,
            &mut market,
            &mut registry_acc,
            &mut redemption_acc,
            &mut lp_mint_acc,
            &mut escrow_acc,
            &mut vault_token_acc,
            &mut vault_auth_acc,
            &mut ledger0,
            &mut redeemer_dest_acc,
            &mut token_prog,
            &mut ledger1,
        ],
    );
    assert_eq!(
        res_domain1,
        Err(ProgramError::Custom(PercolatorError::EngineCounterUnderflow as u32)),
        "ExecuteRedemption against domain 1 must fail with EngineCounterUnderflow (Custom(25))"
    );

    // ── STEP 3: Attempt RebalanceLpVaultBacking to consolidate pots ───────────────
    let mut sys_prog = TestAccount::new(solana_program::system_program::ID, Pubkey::new_unique(), 0);
    let res_rebalance = run_ix(
        Instruction::RebalanceLpVaultBacking {
            from_domain: 1,
            to_domain: 0,
            amount: 40_000,
        },
        &mut [
            &mut cranker,
            &mut market,
            &mut registry_acc,
            &mut ledger1,
            &mut ledger0,
            &mut sys_prog,
        ],
    );
    assert_eq!(
        res_rebalance,
        Err(ProgramError::Custom(PercolatorError::EngineLockActive as u32)),
        "RebalanceLpVaultBacking must fail on resolved market (mode != Live) with EngineLockActive (Custom(21))"
    );

    // ── STEP 4: Demonstrate Teardown Blocked ────────────────────────────────────
    let mut admin_signer = admin.clone().writable();
    let res_close_lp = run_ix(
        Instruction::CloseLpVault,
        &mut [&mut admin_signer, &mut market, &mut registry_acc, &mut lp_mint_acc],
    );
    assert_eq!(
        res_close_lp,
        Err(ProgramError::Custom(PercolatorError::LpVaultSharesOutstanding as u32)),
        "CloseLpVault must fail because shares are permanently stuck outstanding"
    );
}

[0x-SquidSol]

We reproduced the analysis against main at 19d5d93. The mechanism is real and worth fixing, but we do not think the impact is "permanent freezing of funds" — the capital is recoverable through the existing instruction set, which we think puts this well below Critical.

The mechanism holds up

All four legs verify:

• shares are priced across both pots — lp_vault_combined_available_principal_atoms and lp_vault_combined_nav_atoms (src/v16_program.rs:15395, :15403)
• the payout is drawn from one pot — principal_portion > ledger.total_principal_atoms → EngineCounterUnderflow (:15537-15538)
• RebalanceLpVaultBacking is Live-only — if mode != MarketModeV16::Live → EngineLockActive (:15077)
• CloseLpVault refuses while shares are outstanding (:16387)

The price-across-both / pay-from-one asymmetry is a genuine defect, and the split state is normal rather than contrived — the code says so directly at :10064-10071: "The vault's backing can sit in either pot (see RebalanceLpVaultBacking, tag 91), so pricing shares off registry.domain alone understates NAV."

Why we don't think it is a permanent freeze

RequestRedeemLpShares { shares: u128 } takes a caller-chosen amount (:4082-4084), and CancelRedemption returns exactly the escrowed shares to the redeemer (:15928-15939). Since

principal_out = floor(shares × combined_available / total_shares)      // :15421

the redeemer controls principal_out directly by choosing shares. Taking the PoC's own state — 100,000 shares outstanding, domain 0 = 60,000, domain 1 = 40,000, redeemer holding 99,000:

request	principal_out	drawn against	result
99,000	99,000	either pot	fails — matches the PoC
60,000	60,000	domain 0 (60,000)	succeeds
39,000	39,000	domain 1 (40,000)	succeeds

The 60,000 case is worth spelling out because it is the boundary: the guard is principal_portion > ledger.total_principal_atoms, a strict >, so a request that exactly equals the pot passes. We also checked the gates downstream of it for that request — bucket.status == Fresh, fresh_unliened_backing_num >= backing_num, source.fresh_reserved_backing_num >= backing_num, atoms <= header.vault (:15554-15559), and the earnings gate at :15562 — and none of them bind here. The OI-reservation guard at :15591 is skipped outright, since the PoC's registry sets oi_reservation_threshold_bps: 0.

Generalising: the larger pot always holds at least half the combined total, so a redeemer can always withdraw at least half their shares in one request, and the position drains in a handful of calls. Nothing is stranded and no value is lost.

The report does consider the cancel route, but only for re-requesting the same amount:

Re-requesting redemption re-encounters the exact same single-domain liquidity exhaustion.

That is correct for an identical request and not correct for a smaller one, and the "permanent freeze" conclusion rests on that step.

What we would still fix

The defect is real, just narrower than reported. Two things seem worth addressing:

1. The payout should be able to span both pots, or the handler should draw the shortfall from the sibling domain, since that is how the shares were priced in the first place.
2. The error is actively misleading. EngineCounterUnderflow reads as state corruption, when the actual meaning is "this pot cannot cover this request — ask for less." A distinct error (or one carrying the per-domain maximum) would turn a scary dead end into a retryable condition. As written, an LP hitting this on a resolved market has no signal that a smaller request would work, which we suspect is how the freeze reading arose.

The Live-only restriction on rebalancing is also a genuine gap for resolved markets — after resolution the pots can never be consolidated, so large LPs are permanently forced into chunked exits even though the funds remain retrievable.

We would suggest Low severity: a confusing failure and a poor exit UX on resolved markets, not loss or freezing of funds.

One note on methodology, offered constructively: the PoC hand-writes the market internals rather than driving the state through real instructions. That is fine for demonstrating the arithmetic, and the 60/40 split is genuinely reachable — but a hand-built fixture does not invite trying a different request size, which we think is why the recovery path went unexplored.

To be explicit about our own limits: we verified the above by reading the handler and its gates, and by working the arithmetic through the PoC's exact numbers. We did not execute a counter-PoC, so the two-request extraction above is an analytical result rather than a measured one.

[dcccrypto]

Fixed and deployed — wrapper 411d70fc, byte-identical, gate 201/201

Reproduced before fixing, exactly as reported: both draws Custom(25) EngineCounterUnderflow, rebalance Custom(21) EngineLockActive, LP paid 0.

The asymmetry you found

Redemption prices an LP's payout across the combined pots (:15627/:15635) but draws it from one (principal_portion > ledger.total_principal_atoms, :15767). Once a claim exceeds either pot, both choices of source_domain fail — and consolidating was the only remedy, gated Live-only while redemption itself explicitly allows Resolved.

The fix needed TWO gate changes, not one

Relaxing the header-mode gate alone changed nothing — the LP still saw Custom(21). There is a second, entirely uncommented group.header.mode != 0 twin further down, and that was the one actually firing. Worth knowing if you audit this area: a one-line fix that appears not to work here is worth suspecting a second gate before suspecting the diagnosis.

Rebalance now uses exactly the gate ExecuteRedemption uses, because it exists to make redemption feasible.

Why that is safe in Resolved

None of the reasons rebalance is permissionless in Live reference the mode: no tokens move (header.vault untouched, the aggregate nets to zero), both pots belong to the same vault so nothing can be extracted, only fresh unliened backing is movable, and the source-side watermark gate still refuses any move that would leave the source under-backed. Resolved is if anything safer — there is no live OI for the moved backing to be supporting. Terminal modes other than Resolved stay barred.

Verification

The test asserts the LP is paid — 999,000, the full pro-rata claim — not merely that the instruction stopped erroring. An open instruction is not an exit. Reverting the engine-side gate turns it red; restoring turns it green. A control pins that a single-domain LP could always exit a resolved market, so a red means the split rather than resolution. A separate test pins that widening the mode gate did not widen the amount gate — the existing dual-domain guards all run against Live markets and said nothing about the mode this newly admits.

Thanks — this was the most serious of the batch, and the report's three-legged framing is what made it quick to confirm.