Base asset admin usurps all trading creator fees on secondary assets in multi-asset markets

[v1ktorrr0x]

Base asset admin usurps all trading creator fees on secondary assets in multi-asset markets

Impact

Theft of unclaimed yield or earned fees.

In multi-asset markets, all trade creator fees accumulate into a single global counter, but fee withdrawals check only the Asset 0 admin. Secondary asset creators cannot claim their earned revenue, while the base market deployer can drain all accumulated fees from every asset.

Description

The wrapper tracks trade creator fees in a single global accumulator inside WrapperConfigV16:

cfg.creator_fee_claimable_atoms = cfg.creator_fee_claimable_atoms.checked_add(u64::try_from(creator_cut_total)?)?;

Trading fees generated on any asset slot (e.g. Asset 1) flow into this shared counter. When withdrawing fees via WithdrawCreatorFee, handle_withdraw_creator_fee hardcodes an authorization check against Asset 0 only:

let profile = read_oracle_profile_for_asset(&market_data, &cfg, 0)?;
if profile.asset_admin != [0u8; 32] && admin.key.to_bytes() != profile.asset_admin {
    return Err(PercolatorError::Unauthorized.into());
}

The signer is checked exclusively against profile(0).asset_admin. Secondary creators attempting to withdraw their fees are rejected with Unauthorized. The Asset 0 deployer can invoke WithdrawCreatorFee to sweep the entire global accumulator, stealing 100% of trading fees generated by secondary markets.

Not the same as per-asset authority updates

• UpdateAssetLifecycle correctly provisions per-asset administrators.
• The flaw is the single global fee pool paired with a hardcoded Asset 0 gate on withdrawal.

On permissionless multi-asset deployment

• Multi-asset markets explicitly permit independent asset listings via UpdateAssetLifecycle(ASSET_ACTION_ACTIVATE).
• The fee architecture fails to isolate creator earnings per asset.

Proof of Concept

Target file:

• src/v16_program.rs: handle_withdraw_creator_fee

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

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

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

    // Initialize market with 2 asset slots
    run_ix(
        Instruction::InitMarket {
            max_portfolio_assets: 2,
            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_0.clone(), &mut market, &mut mint],
    ).unwrap();

    let (v_auth, _) = vault_authority(&market);
    let vault_ata = canonical_vault_ata(&v_auth, &mint_key);

    // Setup: Asset 0 has admin_0, Asset 1 has creator_2.
    // Trading on Asset 1 accumulated 50,000 atoms into cfg.creator_fee_claimable_atoms.
    {
        let mut market_data = market.data.clone();
        let (mut cfg, group) = state::market_view_mut(&mut market_data).unwrap();
        cfg.creator_fee_claimable_atoms = 50_000;
        cfg.collateral_mint = mint_key.to_bytes();
        group.header.insurance = percolator::V16PodU128::new(100_000);
        group.header.vault = percolator::V16PodU128::new(100_000);

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

        let mut prof0 = state::read_asset_oracle_profile(&market.data, 0).unwrap();
        prof0.asset_admin = admin_0.key.to_bytes();
        state::write_asset_oracle_profile(&mut market.data, 0, &prof0).unwrap();

        let mut prof1 = state::read_asset_oracle_profile(&market.data, 1).unwrap();
        prof1.asset_admin = creator_2.key.to_bytes();
        state::write_asset_oracle_profile(&mut market.data, 1, &prof1).unwrap();
    }

    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 creator2_dest = TestAccount::new_with_data(Pubkey::new_unique(), spl_token::ID, make_token_data(mint_key, creator_2.key, 0)).writable();
    let mut admin0_dest = TestAccount::new_with_data(Pubkey::new_unique(), spl_token::ID, make_token_data(mint_key, admin_0.key, 0)).writable();
    let mut token_prog = TestAccount::new(spl_token::ID, Pubkey::new_unique(), 0).executable();

    // ── STEP 1: Creator 2 attempts to withdraw their earned fees ───────────────
    let res_creator2 = run_ix(
        Instruction::WithdrawCreatorFee { amount: 50_000 },
        &mut [
            &mut creator_2,
            &mut market,
            &mut creator2_dest,
            &mut vault_token_acc,
            &mut vault_auth_acc,
            &mut token_prog,
        ],
    );
    assert_eq!(
        res_creator2,
        Err(ProgramError::Custom(PercolatorError::Unauthorized as u32)),
        "Creator 2 must be rejected with Unauthorized (Custom(8)) because handle_withdraw_creator_fee hardcodes Asset 0"
    );

    // ── STEP 2: Asset 0 Admin executes the withdrawal ──────────────────────────
    let res_admin0 = run_ix(
        Instruction::WithdrawCreatorFee { amount: 50_000 },
        &mut [
            &mut admin_0,
            &mut market,
            &mut admin0_dest,
            &mut vault_token_acc,
            &mut vault_auth_acc,
            &mut token_prog,
        ],
    );
    assert!(res_admin0.is_ok(), "Asset 0 Admin successfully captures all creator fees from secondary assets");

    let cfg_final = state::read_market(&market.data).unwrap().0;
    assert_eq!(cfg_final.creator_fee_claimable_atoms, 0, "Creator fee counter drained to 0 by Asset 0 Admin");
}

[0x-SquidSol]

We checked this against main at 19d5d93. The mechanics are described accurately, but we do not think this is a vulnerability — it is the documented, deliberate design, and the "theft" framing rests on an entitlement that does not exist anywhere in the code.

The mechanics are right

Both observations hold:

• creator fees accrue to a single market-level counter, cfg.creator_fee_claimable_atoms (src/v16_program.rs:8136-8142)
• withdrawal is gated on asset 0's admin only — live_authority_matches(&asset0_profile.asset_admin, authority.key) (:11275-11276)

But that gate is the design, stated explicitly

handle_withdraw_creator_fee's own documentation names it as the first of three deliberate divergences from handle_withdraw_protocol_fee (:11175-11183):

AUTHORITY is asset 0's asset_admin, and ONLY that. It bootstraps to the asset activator (the creator) at InitMarket / activation, and is rotated ONLY by its holder via UpdateAssetAuthority self-rotation. […] So asset_admin for asset 0 is stable creator-only.

The same block explains why it is pinned there rather than to any other role: on a staked market StakeInitPool + BindInsuranceAuthority rotate marketauth, insurance_authority and insurance_operator to program PDAs, so gating the claim on any of those would make the creator's fees permanently unclaimable — no wallet holds a PDA key.

There is also a defense-in-depth guard added specifically to keep this claim with asset 0 (:12969 onward), which rejects asset_index == 0 in the re-activation branch precisely so that marketauth cannot rewrite asset-0's asset_admin and take the claim. Upstream did not overlook the alternative — they blocked the path that would have enabled it.

The premise does not hold

The report describes this as secondary creators being unable to claim "their earned revenue," and the base deployer "stealing 100% of trading fees generated by secondary markets." That presupposes a per-asset creator entitlement. There is none:

• there is no per-asset creator-fee accounting anywhere in the wrapper — the counter is singular and lives in WrapperConfigV16
• it sits alongside protocol_fee_accrued_atoms (:1167), lp_fee_accrued_atoms (:1192) and insurance_reserve_accrued_atoms (:1197) — the fee split has four market-level legs, and "creator" is the market creator's leg, structurally a sibling of the protocol's
• no code path ever credits a secondary asset's admin with a trade-fee share, so there is no balance being diverted

Activating a secondary slot costs the lister permissionless_market_init_fee (:1113); it does not enrol them in the market-level fee split. So there is nothing accrued to a secondary creator for asset 0's admin to take — the counter being drawn down is asset 0's own leg, credited by the market they deployed.

A secondary lister is not necessarily left with nothing, either. Backing-utilisation fees accrue into that asset's own bucket as utilization_fee_earnings (engine v16.rs:10072) and are withdrawn through WithdrawBackingBucketEarnings (tag 52), gated on the asset's own backing_bucket_authority (src/v16_program.rs:10590-10591) — a role the lister holds, not asset 0's admin. Whoever capitalises an asset's domains earns against that asset, through a leg that is genuinely per-asset.

We would not overstate that: those fees are driven by the engine's own lien-utilisation config, not by the profile's backing_trade_fee_bps_long/short, and we could find no live application path for the latter in the wrapper — :6164-6170 records that backing_trade_fee_bps is 0 on every deployed market. So the size of that leg in practice is a separate question we have not measured. The structural point stands regardless: per-asset economics are routed through backing, and the market-creator counter is a market-level leg.

We would also note the PoC constructs this by writing cfg.creator_fee_claimable_atoms = 50_000 directly and then attributing that balance to Asset 1 trading in a comment. Nothing in the fixture ties any portion of the counter to a particular asset, because the program has no such attribution to reproduce.

Where we think it does belong

The economic question underneath is a fair one to ask: should a third party who lists an asset on someone else's market receive a share of the trade fees their asset generates? That is a reasonable product design discussion, and if permissionless listing is marketed anywhere as fee-earning, the mismatch would be worth correcting in the docs or the fee split.

But as filed — "theft of unclaimed yield or earned fees" — we do not think it stands, because the yield in question was never allocated to the party said to be losing it. We would suggest reclassifying it as a design/product question rather than a security finding.

Happy to be corrected if there is a spec or public statement that promises secondary listers a trade-fee share — that would change our read, and we could not find one in the repo.

[dcccrypto]

CONFIRMED. Escalated — this is the more serious of the creator-fee pair (#420/#421) and needs a layout decision.

Verified on the deployed wrapper: cfg.creator_fee_claimable_atoms is a single global u64 on WrapperConfigV16, trade creator cuts from every asset slot accumulate into it, and handle_withdraw_creator_fee reads asset 0's profile and gates on profile.asset_admin — with the source comment stating the intent outright:

Authority: asset 0's asset_admin ONLY.

So in a multi-asset market the base deployer can withdraw fees generated by secondary assets, and secondary creators can withdraw nothing. Your severity framing is right: this is misappropriation of earned revenue, not griefing.

Why it cannot be patched in this pass

The accumulator is one field. Correct per-creator accounting needs per-asset claimable balances, which is a WrapperConfigV16 layout change — and this program is deployed, so that is an ABI break plus a migration for live markets, not a code fix. Any interim patch that redistributes from a single counter has to invent an attribution rule for fees already accrued, and there is no per-asset record to attribute them from.

The narrower stopgap — refuse WithdrawCreatorFee on multi-asset markets — stops the misappropriation and simultaneously strands every creator's fees, including asset 0's. That trades a fairness bug for a liveness bug.

Two notes for whoever takes the decision

Upstream has neither the handler nor the field. I checked upstream/main: creator_fee_claimable_atoms appears zero times. The creator-fee surface is ours alone, so there is no upstream design to port and no upstream fix waiting. Worth knowing before someone goes looking.

#421 shares this root cause — one global counter plus asset-0-only authority — but is far less reachable, and I have said so on that issue rather than treating them as one finding.

[dcccrypto]

Adding #421's finding here, because both wait on the same layout decision.

#421 reports that a burned-admin market (asset_admin = [0u8; 32]) accrues creator_fee_claimable_atoms that nobody can ever withdraw — handle_withdraw_creator_fee requires a live non-zero authority.

Its stated consequence — u64 overflow bricking trading — is not reachable: u64::MAX is 18.4 trillion tokens of creator fee at 6 decimals, with no attacker amplification (the cut is a fraction of notional, notional is bounded by vault collateral, the vault by MAX_VAULT_TVL). Closed on that basis.

What survives is a dead-value question that belongs with this issue, because both are downstream of the same design:

one global creator_fee_claimable_atoms counter + asset-0-only withdrawal authority

• This issue (Base asset admin usurps all trading creator fees on secondary assets in multi-asset markets #420): secondary-asset creators cannot claim their earned fees, and the base deployer can withdraw them. Misappropriation of earned revenue.
• Creator fee accumulator overflow permanently halts trading on burned admin markets #421's residual: on a burned-admin market, that balance is unwithdrawable by anyone. Dead value.

Per-asset claimable accounting fixes both. A sweep-to-insurance rule (or routing the creator leg to insurance at accrual when the admin is burned) fixes the second alone.

Since the fix here is a WrapperConfigV16 layout change plus a migration for live markets, whoever takes that decision will necessarily decide the burned-admin case too. Deciding them together avoids a second migration.

Upstream, recorded: creator_fee_claimable_atoms appears zero times in aeyakovenko/percolator-prog. The whole creator-fee surface is ours — no upstream design to port, nothing to report back.

[dcccrypto]

Fixed by #463, merged as a327b4b0.

Creator fees now accrue and are claimed per asset: AssetOracleProfileV16 gained creator_fee_claimable_atoms, and tag 90 takes an asset selector (payload 17 → 19 bytes) with per-asset authority. The base asset admin can no longer sweep fees earned by secondary assets in a multi-asset market.

ASSET_ORACLE_PROFILE_LEN grew 400 → 408 inside the fixed 512-byte slot, so WRAPPER_CONFIG_LEN stays 576 and no deployed market shifts.

Merged, not yet deployed. Tag 90's wire format changed, so this is half of a lockstep pair with the SDK — an old SDK against the new program sends a short payload. Fixed in main, not on chain.