Creator fee accumulator overflow permanently halts trading on burned admin markets

[v1ktorrr0x]

Creator fee accumulator overflow permanently halts trading on burned admin markets

Impact

Permanent freezing of market trading functions / Unrecoverable denial of service.

On immutable markets where the creator fee admin is burned (asset_admin = [0u8; 32]), accumulated trading fees cannot be withdrawn. As trade fees accumulate, creator_fee_claimable_atoms eventually reaches u64::MAX, causing checked_add in apply_creator_fee_after_trade_view to fail permanently and brick all future trading across the entire market.

Description

The wrapper accumulates trade creator cuts into a u64 counter on every executed trade:

cfg.creator_fee_claimable_atoms = cfg
    .creator_fee_claimable_atoms
    .checked_add(u64::try_from(creator_cut_total).map_err(|_| PercolatorError::EngineArithmeticOverflow)?)
    .ok_or(PercolatorError::EngineArithmeticOverflow)?;

When an immutable market is created by burning the creator admin key (asset_admin = [0u8; 32]), handle_withdraw_creator_fee requires a live non-zero authority:

if profile.asset_admin != [0u8; 32] && admin.key.to_bytes() != profile.asset_admin {
    return Err(PercolatorError::Unauthorized.into());
}
if profile.asset_admin == [0u8; 32] {
    // Falls through or fails to match live signer
}

Because asset_admin is dead, WithdrawCreatorFee can never decrement creator_fee_claimable_atoms. As volume flows through the market, the counter saturates u64::MAX. Once saturated, every subsequent trade instruction (TradeCpi, BatchTradeCpi, TradeMatchZeroCopy) reverts with EngineArithmeticOverflow. The market cannot process any further volume.

Not the same as temporary crank staleness

• Crank staleness is resolved by pushing an updated oracle tick.
• Counter overflow is an unrecoverable arithmetic fault in the wrapper configuration account.

On fee-less markets

• Any non-zero trade_fee_base_bps configured at launch or updated via SetTradeFee triggers cumulative fee accrual.

Proof of Concept

Target files:

• src/v16_program.rs: apply_creator_fee_after_trade_view and handle_withdraw_creator_fee

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

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

    let mut admin = TestAccount::new(Pubkey::new_unique(), Pubkey::new_unique(), 0).signer().writable();
    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;

    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();

    // 1. Simulate high volume accumulation near u64::MAX and burned asset_admin key
    {
        let mut market_data = market.data.clone();
        let (mut cfg, _group) = state::market_view_mut(&mut market_data).unwrap();
        cfg.creator_fee_claimable_atoms = u64::MAX - 50; // 50 atoms away from overflow
        cfg.collateral_mint = mint_key.to_bytes();

        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.asset_admin = [0u8; 32]; // Admin key burned to establish immutable market
        state::write_asset_oracle_profile(&mut market.data, 0, &prof).unwrap();
    }

    // 2. Arithmetic Overflow Proof:
    // When a trade cut (e.g. 100 atoms) is added to creator_fee_claimable_atoms:
    let creator_cut_total: u128 = 100;
    let cfg = state::read_market(&market.data).unwrap().0;
    let overflow_result = cfg.creator_fee_claimable_atoms.checked_add(
        u64::try_from(creator_cut_total).unwrap()
    );
    assert_eq!(overflow_result, None, "checked_add overflows u64::MAX");

    // 3. Demonstrate that WithdrawCreatorFee cannot relieve the counter because admin is burned
    let (v_auth, _) = vault_authority(&market);
    let vault_ata = canonical_vault_ata(&v_auth, &mint_key);
    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 dest = TestAccount::new_with_data(Pubkey::new_unique(), spl_token::ID, make_token_data(mint_key, admin.key, 0)).writable();
    let mut token_prog = TestAccount::new(spl_token::ID, Pubkey::new_unique(), 0).executable();

    let res_withdraw = run_ix(
        Instruction::WithdrawCreatorFee { amount: 10_000 },
        &mut [
            &mut admin,
            &mut market,
            &mut dest,
            &mut vault_token_acc,
            &mut vault_auth_acc,
            &mut token_prog,
        ],
    );
    assert_eq!(
        res_withdraw,
        Err(ProgramError::Custom(PercolatorError::Unauthorized as u32)),
        "Withdrawal is permanently impossible with Unauthorized (Custom(8)) because asset_admin is [0u8; 32]"
    );
}

[0x-SquidSol]

We checked this against main at 19d5d93. One observation in the report is true and already documented; the overflow that the impact rests on is not reachable, by roughly five thousand times the maximum size a market can ever hold. Several of the code references also do not exist in the tree.

Code references that do not match the source

• apply_creator_fee_after_trade_view — named as a target file/function. There is no such function anywhere in src/v16_program.rs.

• SetTradeFee — named as the instruction that configures the fee. There is no such instruction; the real one is UpdateTradeFeePolicy (tag 55).

• The quoted handle_withdraw_creator_fee gate is not the code that runs. The report shows:

  if profile.asset_admin != [0u8; 32] && admin.key.to_bytes() != profile.asset_admin {
      return Err(PercolatorError::Unauthorized.into());
  }
  if profile.asset_admin == [0u8; 32] {
      // Falls through or fails to match live signer
  }

  The actual gate is (src/v16_program.rs:11274-11277):

  let asset0_profile = read_oracle_profile_from_view(&group, &cfg, 0)?;
  if !live_authority_matches(&asset0_profile.asset_admin, authority.key) {
      return Err(PercolatorError::Unauthorized.into());
  }

  This matters, because the quoted version and the real one behave oppositely in the burned case: the quoted && form would let anyone through once asset_admin is zero, whereas live_authority_matches is *expected != [0u8; 32] && *expected == signer.to_bytes() (:16981-16983), so it rejects everyone.

The true part is already documented

The real conclusion — a burned asset_admin means the creator counter can never be drawn down — is correct, and the code says so at the gate itself (:11258-11260):

Authority: asset 0's asset_admin ONLY. live_authority_matches also rejects the all-zero key, so a burned/unconfigured admin can never be claimed against by a zero-key signer.

So the unclaimable-fee state is known and intended, not an oversight.

The overflow is not reachable

The impact claim requires creator_fee_claimable_atoms to reach u64::MAX. Working from the constants in the tree:

• u64::MAX = 18,446,744,073,709,551,615 atoms.
• The creator leg is capped at MAX_CREATOR_SHARE_BPS = 3600 (:128), i.e. 36% of any trade fee, enforced by validate_fee_split (:6367), which applies the share to the full fee (creator = fee * creator_bps / 10_000, :6328-6334). So reaching the ceiling requires cumulative charged fees of at least u64::MAX / 0.36 ≈ 5.12 × 10^19 atoms.
• Every atom of that is a share of a fee charged against a trader's capital, and capital is held in header.vault.
• header.vault is hard-capped at MAX_VAULT_TVL = 10_000_000_000_000_000 (1 × 10^16, percolator/src/lib.rs:27), enforced as a shape invariant by validate_shape (percolator/src/v16.rs:5481, check at :5504) — which the wrapper calls after mutating instructions, including immediately after this very accrual (src/v16_program.rs:8166).

So the counter can only saturate if a maximum-capacity vault is filled and then converted, in its entirety, into trading fees — about 5,124 times over. That is the floor, not an estimate: it assumes 100% of every atom ever deposited becomes a trade fee, with none of it ever paid out, and it still leaves the required volume three orders of magnitude beyond what the market can hold at once.

In concrete terms with 6-decimal collateral, MAX_VAULT_TVL is $10bn, and the ceiling needs roughly $51 trillion of cumulative creator fees on a single market.

The PoC does not exercise the claim

Step 1 sets cfg.creator_fee_claimable_atoms = u64::MAX - 50 by direct assignment, described as "simulate high volume accumulation." Step 2 then does this:

let creator_cut_total: u128 = 100;
let cfg = state::read_market(&market.data).unwrap().0;
let overflow_result = cfg.creator_fee_claimable_atoms.checked_add(
    u64::try_from(creator_cut_total).unwrap()
);
assert_eq!(overflow_result, None, "checked_add overflows u64::MAX");

That is a local checked_add on a value the test just wrote — it never invokes the program, and it asserts a property of u64 arithmetic rather than anything about this codebase. No trade instruction is executed anywhere in the test, so the claimed consequence ("every subsequent trade instruction reverts") is not demonstrated. The only part that would need proving — that the counter can get there — is assumed by assignment.

Step 3 does exercise the program and does show that a burned admin cannot withdraw, which is the documented behaviour above.

Assessment

We do not think this is a vulnerability. The u64 narrowing is a deliberate, documented choice — the counter is u64 because it had to fit the 8 spare bytes of _padding_split, and the code explicitly chose to error rather than wrap or saturate (:8132-8135). Failing closed on an arithmetic condition that cannot occur is the conservative option, and the alternative (saturating) would silently destroy a real claim.

One thing we would genuinely flag, distinct from the overflow: on a burned-admin market those atoms sit permanently in header.insurance and header.vault, since WithdrawCreatorFee is the only path that removes them (:11306-11308 via withdraw_insurance_surplus_not_atomic). Whether that can block CloseSlab, which requires vault == 0 && insurance == 0 (:11833-11836), depends on whether another leg drawing from the same shared surplus can absorb them — withdraw_insurance_surplus_delta clamps on insurance − source_reserved − budget_remaining_total with no per-leg counter (percolator/src/v16.rs:7900-7903). We have not verified that either way and are not claiming it as a finding — but if the concern is "burned admin strands value," that seems the more productive question than the u64 ceiling.

[dcccrypto]

Mechanism CONFIRMED. Impact REDUCED — this is not reachable, and I want to be specific about why rather than dismiss it.

The code is exactly as you describe: creator_fee_claimable_atoms is a u64 accumulated with checked_add on every trade, handle_withdraw_creator_fee requires a live non-zero asset_admin, and a burned admin ([0u8; 32]) can never drain it. So on a burned-admin market the counter is monotonically increasing with no exit, and at saturation apply_creator_fee_after_trade_view returns EngineArithmeticOverflow on every subsequent trade. The failure mode you describe — permanent, unrecoverable, market-wide — follows correctly from the premise.

The premise is the problem

u64::MAX is 18,446,744,073,709,551,615 atoms. At the 6 decimals this collateral uses, that is 18.4 trillion tokens of accumulated creator fee — not volume, but the creator's cut of it. At any plausible fee rate the required lifetime volume exceeds the total supply of every asset these markets trade by many orders of magnitude.

This is not a case of "unlikely but possible under adversarial conditions". There is no attacker-controlled amplification: creator cut is a fraction of notional, notional is bounded by real collateral in the vault, and the vault is bounded by MAX_VAULT_TVL. An attacker cannot inflate the counter faster than they can fund it.

Why it stays open anyway

Two reasons, neither of them the DoS:

1. It documents a real design property: a burned-admin market accrues a balance that nobody can ever withdraw. That is dead value, and it is worth a decision — sweep it to insurance, or route the creator leg to insurance at accrual when the admin is burned — independent of any overflow.
2. It shares a root cause with Base asset admin usurps all trading creator fees on secondary assets in multi-asset markets #420, which is reachable: one global counter with asset-0-only authority. Whatever fixes Base asset admin usurps all trading creator fees on secondary assets in multi-asset markets #420's accounting will touch this field, and it would be better to resolve both together than to add a saturating_add here and revisit the same line later.

A saturating_add on its own would be the wrong patch: it would silently discard fees to prevent an event that cannot occur, and on a non-burned market that discard would be a real loss.

Re-labelled in my assessment from "permanent DoS" to "unclaimable-balance design gap". The mechanism reasoning was sound; the reachability was not checked.

[dcccrypto]

Closing as unreachable-by-arithmetic, with the one real question it raises moved to #420 where it can actually be fixed.

The mechanism is correct; the premise is not reachable

creator_fee_claimable_atoms is a u64 accumulated with checked_add, a burned admin ([0u8; 32]) can never withdraw, and at saturation apply_creator_fee_after_trade_view returns EngineArithmeticOverflow on every subsequent trade. All of that follows.

But u64::MAX is 18,446,744,073,709,551,615 atoms — at the 6 decimals this collateral uses, 18.4 trillion tokens of accumulated creator fee, not volume. The creator cut is a fraction of notional, notional is bounded by real collateral in the vault, and the vault is bounded by MAX_VAULT_TVL. There is no attacker-controlled amplification: nobody can inflate the counter faster than they can fund it.

This is not "unlikely but possible under adversarial conditions". The required volume exceeds the total supply of every asset these markets trade by many orders of magnitude.

A saturating_add would be the wrong patch: it would silently discard fees to prevent an event that cannot occur, and on a non-burned market that discard is a real loss.

The real finding underneath, and where it belongs

A burned-admin market accrues a balance nobody can ever withdraw. That is dead value, and it is true regardless of overflow — it is worth deciding whether to sweep it to insurance, or route the creator leg to insurance at accrual when the admin is burned.

But that decision touches the same single global counter as #420 (base-asset admin takes secondary assets' creator fees), and #420's fix — per-asset claimable accounting — is a WrapperConfigV16 layout change with a migration for live markets. Whatever resolves #420 will necessarily decide what happens to a burned-admin balance too.

Keeping this open as a separate ticket would mean two issues waiting on one layout decision, and this is the one with no reachable failure. Recorded on #420 instead.

Upstream

creator_fee_claimable_atoms appears zero times in aeyakovenko/percolator-prog. The entire creator-fee surface is ours — there is no upstream design to port and nothing to report back.

Re-labelled from "permanent freezing of market trading functions / unrecoverable denial of service" to unclaimable-balance design gap, folded into #420. The mechanism reasoning was sound; the reachability was not checked.