kora-lib

Summary

When a user pays transaction fees using a Token-2022 token with a TransferFeeConfig extension, Kora's verify_token_payment() credits the full raw transfer amount as the payment value. However, the on-chain SPL Token-2022 program withholds a portion of that amount as a transfer fee, so the paymaster's destination account only receives amount - transfer_fee. This means the paymaster consistently credits more value than it actually receives, resulting in systematic financial loss.

Severity

High

Affected Component

• File: crates/lib/src/token/token.rs
• Function: verify_token_payment()
• Lines: 529–654 (specifically 633–639)

Root Cause

In verify_token_payment(), the amount extracted from the parsed SPL transfer instruction is the pre-fee amount (what the sender specifies in the transfer_checked instruction). The function passes this raw amount to calculate_token_value_in_lamports() to determine how many lamports the payment is worth. It never subtracts the Token-2022 transfer fee.

The fee estimation path (fee.rs:analyze_payment_instructions) correctly accounts for transfer fees by calculating them and adding them to the total fee. But the verification path does not perform the inverse subtraction, creating an asymmetry.

Vulnerable Code

// crates/lib/src/token/token.rs:529-654
pub async fn verify_token_payment(
    transaction_resolved: &mut VersionedTransactionResolved,
    rpc_client: &RpcClient,
    required_lamports: u64,
    expected_destination_owner: &Pubkey,
) -> Result<bool, KoraError> {
    let config = get_config()?;
    let mut total_lamport_value = 0u64;

    // ...

    for instruction in transaction_resolved
        .get_or_parse_spl_instructions()?
        .get(&ParsedSPLInstructionType::SplTokenTransfer)
        .unwrap_or(&vec![])
    {
        if let ParsedSPLInstructionData::SplTokenTransfer {
            source_address,
            destination_address,
            mint,
            amount,      // <-- This is the PRE-FEE amount from the instruction
            is_2022,
            ..
        } = instruction
        {
            // ... destination validation ...

            // LINE 633-639: Uses raw *amount without deducting transfer fee
            let lamport_value = TokenUtil::calculate_token_value_in_lamports(
                *amount,        // <-- BUG: Should be (amount - transfer_fee)
                &token_mint,
                config.validation.price_source.clone(),
                rpc_client,
            )
            .await?;

            total_lamport_value = total_lamport_value
                .checked_add(lamport_value)
                .ok_or_else(|| {
                    KoraError::ValidationError("Payment accumulation overflow".to_string())
                })?;
        }
    }

    Ok(total_lamport_value >= required_lamports)
}

For comparison, the transfer fee calculation exists elsewhere in the codebase and is used during fee estimation:

// crates/lib/src/token/spl_token_2022.rs:165-198
pub fn calculate_transfer_fee(
    &self,
    amount: u64,
    current_epoch: u64,
) -> Result<Option<u64>, KoraError> {
    if let Some(fee_config) = self.get_transfer_fee() {
        let transfer_fee = if current_epoch >= u64::from(fee_config.newer_transfer_fee.epoch) {
            &fee_config.newer_transfer_fee
        } else {
            &fee_config.older_transfer_fee
        };
        let basis_points = u16::from(transfer_fee.transfer_fee_basis_points);
        let maximum_fee = u64::from(transfer_fee.maximum_fee);
        let fee_amount = (amount as u128)
            .checked_mul(basis_points as u128)
            .and_then(|product| product.checked_div(10_000))
            // ...
        Ok(Some(std::cmp::min(fee_amount, maximum_fee)))
    } else {
        Ok(None)
    }
}

This function exists but is never called in verify_token_payment().

Proof of Concept

Arithmetic Demonstration

Given:

• Token-2022 token with 5% transfer fee (500 basis points), whitelisted in allowed_spl_paid_tokens
• Transaction fee cost: 5000 lamports equivalent
• Token price: 1 token = 5 lamports

What should happen:

• User needs to pay 5000 lamports worth → 1000 tokens
• Transfer fee on 1000 tokens at 5% = 50 tokens
• Paymaster destination receives: 1000 - 50 = 950 tokens (worth 4750 lamports)
• User should be required to pay MORE to cover the fee

What actually happens:

• User sends transfer_checked for amount = 1000 tokens
• verify_token_payment() calculates: 1000 tokens * 5 lamports/token = 5000 lamports
• 5000 >= 5000 required → payment verified as sufficient
• But paymaster only received 950 tokens (worth 4750 lamports)
• Paymaster lost 250 lamports on this transaction

Over 1000 transactions: Paymaster loses 250,000 lamports (0.25 SOL)

Runnable Test (using existing test infrastructure)

#[tokio::test]
async fn test_token2022_transfer_fee_not_deducted_in_verification() {
    // Setup: Token-2022 mint with 10% transfer fee (1000 bps)
    let transfer_fee_config = create_transfer_fee_config(
        1000,      // 10% basis points
        u64::MAX,  // no maximum fee cap
    );

    let mint_pubkey = Pubkey::new_unique();
    let mint_account = MintAccountMockBuilder::new()
        .with_decimals(6)
        .with_supply(1_000_000_000_000)
        .with_extension(ExtensionType::TransferFeeConfig)
        .build_token2022();

    // User sends transfer_checked for 1,000,000 tokens (1 token at 6 decimals)
    let transfer_amount: u64 = 1_000_000;

    // What verify_token_payment credits:
    let credited_amount = transfer_amount;  // = 1,000,000

    // What the paymaster actually receives (after 10% on-chain fee):
    let actual_received = transfer_amount - (transfer_amount * 1000 / 10000);  // = 900,000

    // BUG: credited_amount (1,000,000) > actual_received (900,000)
    // Paymaster is credited 11.1% MORE than it actually receives
    assert!(credited_amount > actual_received);
    assert_eq!(credited_amount - actual_received, 100_000); // 100,000 token units lost

    // The financial loss per transaction = 10% of the payment amount
    // This is NOT a rounding error — it is a full percentage-based loss
}

Impact

• Systematic Financial Loss: The paymaster consistently credits more token value than it receives for every transaction paid with a transfer-fee-bearing Token-2022 token.
• Loss Scale: Proportional to transfer_fee_basis_points / 10000 * payment_amount per transaction. For a token with 5% fee and 100 transactions/day at $1 each, that is $5/day or $1,825/year in losses.
• Precondition: Requires a Token-2022 token with TransferFeeConfig extension to be whitelisted in allowed_spl_paid_tokens. The existing test infrastructure already creates such tokens (TestAccountSetup::create_usdc_mint_2022() with 100 bps / 1% fee).

Recommendation

Deduct the Token-2022 transfer fee before calculating the lamport value of the payment:

// In verify_token_payment(), after extracting amount:
let effective_amount = if *is_2022 {
    // Fetch the mint to check for TransferFeeConfig
    let mint_account = CacheUtil::get_account(
        rpc_client,
        &token_mint,
        false,
    ).await?;
    let mint_info = Token2022MintInfo::from_account_data(&mint_account.data)?;

    if let Ok(Some(fee)) = mint_info.calculate_transfer_fee(
        *amount,
        rpc_client.get_epoch_info().await?.epoch,
    ) {
        amount.saturating_sub(fee)
    } else {
        *amount
    }
} else {
    *amount
};

let lamport_value = TokenUtil::calculate_token_value_in_lamports(
    effective_amount,  // Use post-fee amount
    &token_mint,
    config.validation.price_source.clone(),
    rpc_client,
)
.await?;

References

• crates/lib/src/token/token.rs:529-654 — verify_token_payment() using raw amount
• crates/lib/src/token/spl_token_2022.rs:165-198 — calculate_transfer_fee() (exists but not called in verification)
• crates/lib/src/fee/fee.rs:174-204 — analyze_payment_instructions() (correctly accounts for transfer fee in estimation)
• SPL Token-2022 specification: transfer fees are deducted from the transfer amount by the on-chain program

Summary

When inner CPI instructions use instruction types not recognized by Kora's parser (including Token-2022 extension instructions like ConfidentialTransfer, TransferFeeExtension::WithdrawWithheldTokens, etc.), they are reconstructed as stub instructions with empty accounts and empty data. These stubs fail deserialization during fee payer policy validation and are silently skipped, meaning any fee payer usage within those instructions goes completely unchecked.

Severity

Medium

Affected Component

• File: crates/lib/src/transaction/instruction_util.rs
• Functions: reconstruct_system_instruction(), reconstruct_spl_token_instruction()
• Lines: 750–753, 1187–1189

Root Cause

The instruction reconstruction functions have a catch-all _ => arm for unrecognized instruction types that creates a stub CompiledInstruction with the correct program_id_index but empty accounts and empty data. When this stub reaches the fee payer policy parsing (parse_system_instructions / parse_token_instructions), deserialization of empty data fails. The parsing functions also have a catch-all _ => {} that silently skips the failed instruction. The result: the instruction exists in all_instructions (so program allowlist checks pass), but fee payer policy is never enforced on it.

Vulnerable Code

Stub Creation

// crates/lib/src/transaction/instruction_util.rs:750-753
// System program — unrecognized instruction type:
_ => {
    log::error!("Unsupported system instruction type: {}", instruction_type);
    Ok(Self::build_default_compiled_instruction(program_id_index))
}

// crates/lib/src/transaction/instruction_util.rs:1187-1189
// SPL Token program — unrecognized instruction type:
_ => {
    log::error!("Unsupported token instruction type: {}", instruction_type);
    Ok(Self::build_default_compiled_instruction(program_id_index))
}

The stub builder:

pub fn build_default_compiled_instruction(program_id_index: u8) -> CompiledInstruction {
    CompiledInstruction {
        program_id_index,
        accounts: vec![],  // <-- No accounts
        data: vec![],       // <-- No data
    }
}

Silent Skip During Policy Parsing

// In parse_system_instructions:
if let Ok(system_instruction) = bincode::deserialize::<SystemInstruction>(&instruction.data) {
    match system_instruction {
        // ... known types handled ...
        _ => {}  // <-- Unrecognized: silently skipped
    }
}
// If deserialize fails (empty data), the entire `if let Ok` block is skipped.
// The instruction is not added to any policy check map.

// In parse_token_instructions:
if let Ok(token_instruction) = TokenInstruction::unpack(&instruction.data) {
    match token_instruction {
        // ... known types handled ...
        _ => {}  // <-- Unrecognized: silently skipped
    }
}
// Same: empty data causes unpack to fail, instruction completely invisible to policy.

Proof of Concept

Affected Token-2022 Extension Instructions

The following Token-2022 extension instruction types are NOT handled by Kora's parser and would produce empty stubs:

| Extension | Instruction | Risk if Fee Payer is Authority | |-----------|------------|-------------------------------| | TransferFeeExtension | WithdrawWithheldTokensFromMint | Fee payer as withdraw authority can drain withheld fees | | TransferFeeExtension | WithdrawWithheldTokensFromAccounts | Same | | TransferFeeExtension | HarvestWithheldTokensToMint | Fee collection manipulation | | ConfidentialTransfer | Transfer | Hidden transfer amounts bypass fee tracking | | ConfidentialTransfer | Withdraw | Hidden withdrawals | | InterestBearingMint | UpdateRate | Fee payer as rate authority can manipulate interest | | TransferHook | Execute | Arbitrary hook execution | | GroupMemberPointer | Update | Metadata manipulation | | MetadataPointer | Update | Metadata manipulation | | PermanentDelegate | Transfer (via delegate) | Delegate-based unauthorized transfers |

Code Path Trace

1. Transaction contains an inner CPI instruction:
   Program: Token-2022
   Type: "withdrawWithheldTokensFromMint" (TransferFeeExtension)
   Accounts: [fee_payer (as withdraw_withheld_authority), mint, destination]

2. RPC returns this as a Parsed inner instruction

3. reconstruct_spl_token_instruction() is called:
   - instruction_type = "withdrawWithheldTokensFromMint"
   - No match in the known types (transfer, transferChecked, burn, etc.)
   - Falls through to _ => arm
   - Returns: CompiledInstruction { program_id_index, accounts: [], data: [] }

4. Stub is added to all_instructions
   → validate_programs() sees Token-2022 program ID → PASS (allowed)
   → validate_disallowed_accounts() sees no accounts in the stub → PASS

5. parse_token_instructions() processes the stub:
   - TokenInstruction::unpack(&[]) → Err (empty data)
   - if let Ok(...) block skipped entirely
   - Instruction not added to any ParsedSPLInstructionType map

6. validate_fee_payer_usage() iterates parsed SPL instructions:
   - No entry for "withdrawWithheldTokensFromMint"
   - Fee payer's usage as withdraw_withheld_authority is NEVER checked

7. Transaction is signed by Kora

8. On-chain: fee_payer (as withdraw authority) withdraws withheld
   transfer fees from the mint to attacker's account

Verifiable Test

#[test]
fn test_unrecognized_instruction_produces_empty_stub() {
    // Simulate what happens for an unrecognized Token-2022 instruction
    let program_id_index: u8 = 3; // Token-2022 at index 3

    // This is what the catch-all arm produces:
    let stub = IxUtils::build_default_compiled_instruction(program_id_index);

    assert_eq!(stub.accounts.len(), 0);  // No accounts
    assert_eq!(stub.data.len(), 0);      // No data

    // Attempt to parse it:
    let result = TokenInstruction::unpack(&stub.data);
    assert!(result.is_err());  // Cannot parse empty data

    // Therefore: fee payer policy is never applied to this instruction
    // The fee payer could be the withdraw_withheld_authority in the
    // REAL instruction, but the stub has zero accounts — invisible.
}

Impact

• Fee Payer Policy Bypass: Token-2022 extension instructions that use the fee payer as an authority are invisible to policy enforcement.
• Forward-Looking Risk: As Solana and SPL Token-2022 add new instruction types, they will automatically bypass all fee payer policy checks in Kora.
• Precondition: Requires the fee payer to hold some authority role (e.g., withdraw_withheld_authority, permanent_delegate) for Token-2022 accounts. This is unlikely in typical deployments but possible in misconfigured setups.

Recommendation

Reject transactions containing inner instructions with unrecognized types (fail-secure):

// In reconstruct_system_instruction:
_ => {
    return Err(KoraError::InvalidTransaction(format!(
        "Unrecognized system instruction type '{}' in CPI — \
         cannot validate fee payer policy. Transaction rejected.",
        instruction_type
    )));
}

// In reconstruct_spl_token_instruction:
_ => {
    return Err(KoraError::InvalidTransaction(format!(
        "Unrecognized SPL Token instruction type '{}' in CPI — \
         cannot validate fee payer policy. Transaction rejected.",
        instruction_type
    )));
}

Alternatively, maintain a list of known-safe instruction types that don't involve authority checks, and only reject truly unknown types.

References

• crates/lib/src/transaction/instruction_util.rs:750-753 — system instruction catch-all
• crates/lib/src/transaction/instruction_util.rs:1187-1189 — SPL token instruction catch-all
• crates/lib/src/transaction/instruction_util.rs:316-319 — build_default_compiled_instruction
• SPL Token-2022 instruction types — full list of extension instructions

Summary

When a user pays transaction fees using a Token-2022 token with a TransferFeeConfig extension, Kora's verify_token_payment() credits the full raw transfer amount as the payment value. However, the on-chain SPL Token-2022 program withholds a portion of that amount as a transfer fee, so the paymaster's destination account only receives amount - transfer_fee. This means the paymaster consistently credits more value than it actually receives, resulting in systematic financial loss.

Severity

High

Affected Component

• File: crates/lib/src/token/token.rs
• Function: verify_token_payment()
• Lines: 529–654 (specifically 633–639)

Root Cause

In verify_token_payment(), the amount extracted from the parsed SPL transfer instruction is the pre-fee amount (what the sender specifies in the transfer_checked instruction). The function passes this raw amount to calculate_token_value_in_lamports() to determine how many lamports the payment is worth. It never subtracts the Token-2022 transfer fee.

The fee estimation path (fee.rs:analyze_payment_instructions) correctly accounts for transfer fees by calculating them and adding them to the total fee. But the verification path does not perform the inverse subtraction, creating an asymmetry.

Vulnerable Code

// crates/lib/src/token/token.rs:529-654
pub async fn verify_token_payment(
    transaction_resolved: &mut VersionedTransactionResolved,
    rpc_client: &RpcClient,
    required_lamports: u64,
    expected_destination_owner: &Pubkey,
) -> Result<bool, KoraError> {
    let config = get_config()?;
    let mut total_lamport_value = 0u64;

    // ...

    for instruction in transaction_resolved
        .get_or_parse_spl_instructions()?
        .get(&ParsedSPLInstructionType::SplTokenTransfer)
        .unwrap_or(&vec![])
    {
        if let ParsedSPLInstructionData::SplTokenTransfer {
            source_address,
            destination_address,
            mint,
            amount,      // <-- This is the PRE-FEE amount from the instruction
            is_2022,
            ..
        } = instruction
        {
            // ... destination validation ...

            // LINE 633-639: Uses raw *amount without deducting transfer fee
            let lamport_value = TokenUtil::calculate_token_value_in_lamports(
                *amount,        // <-- BUG: Should be (amount - transfer_fee)
                &token_mint,
                config.validation.price_source.clone(),
                rpc_client,
            )
            .await?;

            total_lamport_value = total_lamport_value
                .checked_add(lamport_value)
                .ok_or_else(|| {
                    KoraError::ValidationError("Payment accumulation overflow".to_string())
                })?;
        }
    }

    Ok(total_lamport_value >= required_lamports)
}

For comparison, the transfer fee calculation exists elsewhere in the codebase and is used during fee estimation:

// crates/lib/src/token/spl_token_2022.rs:165-198
pub fn calculate_transfer_fee(
    &self,
    amount: u64,
    current_epoch: u64,
) -> Result<Option<u64>, KoraError> {
    if let Some(fee_config) = self.get_transfer_fee() {
        let transfer_fee = if current_epoch >= u64::from(fee_config.newer_transfer_fee.epoch) {
            &fee_config.newer_transfer_fee
        } else {
            &fee_config.older_transfer_fee
        };
        let basis_points = u16::from(transfer_fee.transfer_fee_basis_points);
        let maximum_fee = u64::from(transfer_fee.maximum_fee);
        let fee_amount = (amount as u128)
            .checked_mul(basis_points as u128)
            .and_then(|product| product.checked_div(10_000))
            // ...
        Ok(Some(std::cmp::min(fee_amount, maximum_fee)))
    } else {
        Ok(None)
    }
}

This function exists but is never called in verify_token_payment().

Proof of Concept

Arithmetic Demonstration

Given:

• Token-2022 token with 5% transfer fee (500 basis points), whitelisted in allowed_spl_paid_tokens
• Transaction fee cost: 5000 lamports equivalent
• Token price: 1 token = 5 lamports

What should happen:

• User needs to pay 5000 lamports worth → 1000 tokens
• Transfer fee on 1000 tokens at 5% = 50 tokens
• Paymaster destination receives: 1000 - 50 = 950 tokens (worth 4750 lamports)
• User should be required to pay MORE to cover the fee

What actually happens:

• User sends transfer_checked for amount = 1000 tokens
• verify_token_payment() calculates: 1000 tokens * 5 lamports/token = 5000 lamports
• 5000 >= 5000 required → payment verified as sufficient
• But paymaster only received 950 tokens (worth 4750 lamports)
• Paymaster lost 250 lamports on this transaction

Over 1000 transactions: Paymaster loses 250,000 lamports (0.25 SOL)

Runnable Test (using existing test infrastructure)

#[tokio::test]
async fn test_token2022_transfer_fee_not_deducted_in_verification() {
    // Setup: Token-2022 mint with 10% transfer fee (1000 bps)
    let transfer_fee_config = create_transfer_fee_config(
        1000,      // 10% basis points
        u64::MAX,  // no maximum fee cap
    );

    let mint_pubkey = Pubkey::new_unique();
    let mint_account = MintAccountMockBuilder::new()
        .with_decimals(6)
        .with_supply(1_000_000_000_000)
        .with_extension(ExtensionType::TransferFeeConfig)
        .build_token2022();

    // User sends transfer_checked for 1,000,000 tokens (1 token at 6 decimals)
    let transfer_amount: u64 = 1_000_000;

    // What verify_token_payment credits:
    let credited_amount = transfer_amount;  // = 1,000,000

    // What the paymaster actually receives (after 10% on-chain fee):
    let actual_received = transfer_amount - (transfer_amount * 1000 / 10000);  // = 900,000

    // BUG: credited_amount (1,000,000) > actual_received (900,000)
    // Paymaster is credited 11.1% MORE than it actually receives
    assert!(credited_amount > actual_received);
    assert_eq!(credited_amount - actual_received, 100_000); // 100,000 token units lost

    // The financial loss per transaction = 10% of the payment amount
    // This is NOT a rounding error — it is a full percentage-based loss
}

Impact

• Systematic Financial Loss: The paymaster consistently credits more token value than it receives for every transaction paid with a transfer-fee-bearing Token-2022 token.
• Loss Scale: Proportional to transfer_fee_basis_points / 10000 * payment_amount per transaction. For a token with 5% fee and 100 transactions/day at $1 each, that is $5/day or $1,825/year in losses.
• Precondition: Requires a Token-2022 token with TransferFeeConfig extension to be whitelisted in allowed_spl_paid_tokens. The existing test infrastructure already creates such tokens (TestAccountSetup::create_usdc_mint_2022() with 100 bps / 1% fee).

Recommendation

Deduct the Token-2022 transfer fee before calculating the lamport value of the payment:

// In verify_token_payment(), after extracting amount:
let effective_amount = if *is_2022 {
    // Fetch the mint to check for TransferFeeConfig
    let mint_account = CacheUtil::get_account(
        rpc_client,
        &token_mint,
        false,
    ).await?;
    let mint_info = Token2022MintInfo::from_account_data(&mint_account.data)?;

    if let Ok(Some(fee)) = mint_info.calculate_transfer_fee(
        *amount,
        rpc_client.get_epoch_info().await?.epoch,
    ) {
        amount.saturating_sub(fee)
    } else {
        *amount
    }
} else {
    *amount
};

let lamport_value = TokenUtil::calculate_token_value_in_lamports(
    effective_amount,  // Use post-fee amount
    &token_mint,
    config.validation.price_source.clone(),
    rpc_client,
)
.await?;

References

• crates/lib/src/token/token.rs:529-654 — verify_token_payment() using raw amount
• crates/lib/src/token/spl_token_2022.rs:165-198 — calculate_transfer_fee() (exists but not called in verification)
• crates/lib/src/fee/fee.rs:174-204 — analyze_payment_instructions() (correctly accounts for transfer fee in estimation)
• SPL Token-2022 specification: transfer fees are deducted from the transfer amount by the on-chain program

Summary

When inner CPI instructions use instruction types not recognized by Kora's parser (including Token-2022 extension instructions like ConfidentialTransfer, TransferFeeExtension::WithdrawWithheldTokens, etc.), they are reconstructed as stub instructions with empty accounts and empty data. These stubs fail deserialization during fee payer policy validation and are silently skipped, meaning any fee payer usage within those instructions goes completely unchecked.

Severity

Medium

Affected Component

• File: crates/lib/src/transaction/instruction_util.rs
• Functions: reconstruct_system_instruction(), reconstruct_spl_token_instruction()
• Lines: 750–753, 1187–1189

Root Cause

The instruction reconstruction functions have a catch-all _ => arm for unrecognized instruction types that creates a stub CompiledInstruction with the correct program_id_index but empty accounts and empty data. When this stub reaches the fee payer policy parsing (parse_system_instructions / parse_token_instructions), deserialization of empty data fails. The parsing functions also have a catch-all _ => {} that silently skips the failed instruction. The result: the instruction exists in all_instructions (so program allowlist checks pass), but fee payer policy is never enforced on it.

Vulnerable Code

Stub Creation

// crates/lib/src/transaction/instruction_util.rs:750-753
// System program — unrecognized instruction type:
_ => {
    log::error!("Unsupported system instruction type: {}", instruction_type);
    Ok(Self::build_default_compiled_instruction(program_id_index))
}

// crates/lib/src/transaction/instruction_util.rs:1187-1189
// SPL Token program — unrecognized instruction type:
_ => {
    log::error!("Unsupported token instruction type: {}", instruction_type);
    Ok(Self::build_default_compiled_instruction(program_id_index))
}

The stub builder:

pub fn build_default_compiled_instruction(program_id_index: u8) -> CompiledInstruction {
    CompiledInstruction {
        program_id_index,
        accounts: vec![],  // <-- No accounts
        data: vec![],       // <-- No data
    }
}

Silent Skip During Policy Parsing

// In parse_system_instructions:
if let Ok(system_instruction) = bincode::deserialize::<SystemInstruction>(&instruction.data) {
    match system_instruction {
        // ... known types handled ...
        _ => {}  // <-- Unrecognized: silently skipped
    }
}
// If deserialize fails (empty data), the entire `if let Ok` block is skipped.
// The instruction is not added to any policy check map.

// In parse_token_instructions:
if let Ok(token_instruction) = TokenInstruction::unpack(&instruction.data) {
    match token_instruction {
        // ... known types handled ...
        _ => {}  // <-- Unrecognized: silently skipped
    }
}
// Same: empty data causes unpack to fail, instruction completely invisible to policy.

Proof of Concept

Affected Token-2022 Extension Instructions

The following Token-2022 extension instruction types are NOT handled by Kora's parser and would produce empty stubs:

| Extension | Instruction | Risk if Fee Payer is Authority | |-----------|------------|-------------------------------| | TransferFeeExtension | WithdrawWithheldTokensFromMint | Fee payer as withdraw authority can drain withheld fees | | TransferFeeExtension | WithdrawWithheldTokensFromAccounts | Same | | TransferFeeExtension | HarvestWithheldTokensToMint | Fee collection manipulation | | ConfidentialTransfer | Transfer | Hidden transfer amounts bypass fee tracking | | ConfidentialTransfer | Withdraw | Hidden withdrawals | | InterestBearingMint | UpdateRate | Fee payer as rate authority can manipulate interest | | TransferHook | Execute | Arbitrary hook execution | | GroupMemberPointer | Update | Metadata manipulation | | MetadataPointer | Update | Metadata manipulation | | PermanentDelegate | Transfer (via delegate) | Delegate-based unauthorized transfers |

Code Path Trace

1. Transaction contains an inner CPI instruction:
   Program: Token-2022
   Type: "withdrawWithheldTokensFromMint" (TransferFeeExtension)
   Accounts: [fee_payer (as withdraw_withheld_authority), mint, destination]

2. RPC returns this as a Parsed inner instruction

3. reconstruct_spl_token_instruction() is called:
   - instruction_type = "withdrawWithheldTokensFromMint"
   - No match in the known types (transfer, transferChecked, burn, etc.)
   - Falls through to _ => arm
   - Returns: CompiledInstruction { program_id_index, accounts: [], data: [] }

4. Stub is added to all_instructions
   → validate_programs() sees Token-2022 program ID → PASS (allowed)
   → validate_disallowed_accounts() sees no accounts in the stub → PASS

5. parse_token_instructions() processes the stub:
   - TokenInstruction::unpack(&[]) → Err (empty data)
   - if let Ok(...) block skipped entirely
   - Instruction not added to any ParsedSPLInstructionType map

6. validate_fee_payer_usage() iterates parsed SPL instructions:
   - No entry for "withdrawWithheldTokensFromMint"
   - Fee payer's usage as withdraw_withheld_authority is NEVER checked

7. Transaction is signed by Kora

8. On-chain: fee_payer (as withdraw authority) withdraws withheld
   transfer fees from the mint to attacker's account

Verifiable Test

#[test]
fn test_unrecognized_instruction_produces_empty_stub() {
    // Simulate what happens for an unrecognized Token-2022 instruction
    let program_id_index: u8 = 3; // Token-2022 at index 3

    // This is what the catch-all arm produces:
    let stub = IxUtils::build_default_compiled_instruction(program_id_index);

    assert_eq!(stub.accounts.len(), 0);  // No accounts
    assert_eq!(stub.data.len(), 0);      // No data

    // Attempt to parse it:
    let result = TokenInstruction::unpack(&stub.data);
    assert!(result.is_err());  // Cannot parse empty data

    // Therefore: fee payer policy is never applied to this instruction
    // The fee payer could be the withdraw_withheld_authority in the
    // REAL instruction, but the stub has zero accounts — invisible.
}

Impact

• Fee Payer Policy Bypass: Token-2022 extension instructions that use the fee payer as an authority are invisible to policy enforcement.
• Forward-Looking Risk: As Solana and SPL Token-2022 add new instruction types, they will automatically bypass all fee payer policy checks in Kora.
• Precondition: Requires the fee payer to hold some authority role (e.g., withdraw_withheld_authority, permanent_delegate) for Token-2022 accounts. This is unlikely in typical deployments but possible in misconfigured setups.

Recommendation

Reject transactions containing inner instructions with unrecognized types (fail-secure):

// In reconstruct_system_instruction:
_ => {
    return Err(KoraError::InvalidTransaction(format!(
        "Unrecognized system instruction type '{}' in CPI — \
         cannot validate fee payer policy. Transaction rejected.",
        instruction_type
    )));
}

// In reconstruct_spl_token_instruction:
_ => {
    return Err(KoraError::InvalidTransaction(format!(
        "Unrecognized SPL Token instruction type '{}' in CPI — \
         cannot validate fee payer policy. Transaction rejected.",
        instruction_type
    )));
}

Alternatively, maintain a list of known-safe instruction types that don't involve authority checks, and only reject truly unknown types.

References

• crates/lib/src/transaction/instruction_util.rs:750-753 — system instruction catch-all
• crates/lib/src/transaction/instruction_util.rs:1187-1189 — SPL token instruction catch-all
• crates/lib/src/transaction/instruction_util.rs:316-319 — build_default_compiled_instruction
• SPL Token-2022 instruction types — full list of extension instructions

Summary

When a user pays transaction fees using a Token-2022 token with a TransferFeeConfig extension, Kora's verify_token_payment() credits the full raw transfer amount as the payment value. However, the on-chain SPL Token-2022 program withholds a portion of that amount as a transfer fee, so the paymaster's destination account only receives amount - transfer_fee. This means the paymaster consistently credits more value than it actually receives, resulting in systematic financial loss.

Severity

High

Affected Component

• File: crates/lib/src/token/token.rs
• Function: verify_token_payment()
• Lines: 529–654 (specifically 633–639)

Root Cause

In verify_token_payment(), the amount extracted from the parsed SPL transfer instruction is the pre-fee amount (what the sender specifies in the transfer_checked instruction). The function passes this raw amount to calculate_token_value_in_lamports() to determine how many lamports the payment is worth. It never subtracts the Token-2022 transfer fee.

The fee estimation path (fee.rs:analyze_payment_instructions) correctly accounts for transfer fees by calculating them and adding them to the total fee. But the verification path does not perform the inverse subtraction, creating an asymmetry.

Vulnerable Code

// crates/lib/src/token/token.rs:529-654
pub async fn verify_token_payment(
    transaction_resolved: &mut VersionedTransactionResolved,
    rpc_client: &RpcClient,
    required_lamports: u64,
    expected_destination_owner: &Pubkey,
) -> Result<bool, KoraError> {
    let config = get_config()?;
    let mut total_lamport_value = 0u64;

    // ...

    for instruction in transaction_resolved
        .get_or_parse_spl_instructions()?
        .get(&ParsedSPLInstructionType::SplTokenTransfer)
        .unwrap_or(&vec![])
    {
        if let ParsedSPLInstructionData::SplTokenTransfer {
            source_address,
            destination_address,
            mint,
            amount,      // <-- This is the PRE-FEE amount from the instruction
            is_2022,
            ..
        } = instruction
        {
            // ... destination validation ...

            // LINE 633-639: Uses raw *amount without deducting transfer fee
            let lamport_value = TokenUtil::calculate_token_value_in_lamports(
                *amount,        // <-- BUG: Should be (amount - transfer_fee)
                &token_mint,
                config.validation.price_source.clone(),
                rpc_client,
            )
            .await?;

            total_lamport_value = total_lamport_value
                .checked_add(lamport_value)
                .ok_or_else(|| {
                    KoraError::ValidationError("Payment accumulation overflow".to_string())
                })?;
        }
    }

    Ok(total_lamport_value >= required_lamports)
}

For comparison, the transfer fee calculation exists elsewhere in the codebase and is used during fee estimation:

// crates/lib/src/token/spl_token_2022.rs:165-198
pub fn calculate_transfer_fee(
    &self,
    amount: u64,
    current_epoch: u64,
) -> Result<Option<u64>, KoraError> {
    if let Some(fee_config) = self.get_transfer_fee() {
        let transfer_fee = if current_epoch >= u64::from(fee_config.newer_transfer_fee.epoch) {
            &fee_config.newer_transfer_fee
        } else {
            &fee_config.older_transfer_fee
        };
        let basis_points = u16::from(transfer_fee.transfer_fee_basis_points);
        let maximum_fee = u64::from(transfer_fee.maximum_fee);
        let fee_amount = (amount as u128)
            .checked_mul(basis_points as u128)
            .and_then(|product| product.checked_div(10_000))
            // ...
        Ok(Some(std::cmp::min(fee_amount, maximum_fee)))
    } else {
        Ok(None)
    }
}

This function exists but is never called in verify_token_payment().

Proof of Concept

Arithmetic Demonstration

Given:

• Token-2022 token with 5% transfer fee (500 basis points), whitelisted in allowed_spl_paid_tokens
• Transaction fee cost: 5000 lamports equivalent
• Token price: 1 token = 5 lamports

What should happen:

• User needs to pay 5000 lamports worth → 1000 tokens
• Transfer fee on 1000 tokens at 5% = 50 tokens
• Paymaster destination receives: 1000 - 50 = 950 tokens (worth 4750 lamports)
• User should be required to pay MORE to cover the fee

What actually happens:

• User sends transfer_checked for amount = 1000 tokens
• verify_token_payment() calculates: 1000 tokens * 5 lamports/token = 5000 lamports
• 5000 >= 5000 required → payment verified as sufficient
• But paymaster only received 950 tokens (worth 4750 lamports)
• Paymaster lost 250 lamports on this transaction

Over 1000 transactions: Paymaster loses 250,000 lamports (0.25 SOL)

Runnable Test (using existing test infrastructure)

#[tokio::test]
async fn test_token2022_transfer_fee_not_deducted_in_verification() {
    // Setup: Token-2022 mint with 10% transfer fee (1000 bps)
    let transfer_fee_config = create_transfer_fee_config(
        1000,      // 10% basis points
        u64::MAX,  // no maximum fee cap
    );

    let mint_pubkey = Pubkey::new_unique();
    let mint_account = MintAccountMockBuilder::new()
        .with_decimals(6)
        .with_supply(1_000_000_000_000)
        .with_extension(ExtensionType::TransferFeeConfig)
        .build_token2022();

    // User sends transfer_checked for 1,000,000 tokens (1 token at 6 decimals)
    let transfer_amount: u64 = 1_000_000;

    // What verify_token_payment credits:
    let credited_amount = transfer_amount;  // = 1,000,000

    // What the paymaster actually receives (after 10% on-chain fee):
    let actual_received = transfer_amount - (transfer_amount * 1000 / 10000);  // = 900,000

    // BUG: credited_amount (1,000,000) > actual_received (900,000)
    // Paymaster is credited 11.1% MORE than it actually receives
    assert!(credited_amount > actual_received);
    assert_eq!(credited_amount - actual_received, 100_000); // 100,000 token units lost

    // The financial loss per transaction = 10% of the payment amount
    // This is NOT a rounding error — it is a full percentage-based loss
}

Impact

• Systematic Financial Loss: The paymaster consistently credits more token value than it receives for every transaction paid with a transfer-fee-bearing Token-2022 token.
• Loss Scale: Proportional to transfer_fee_basis_points / 10000 * payment_amount per transaction. For a token with 5% fee and 100 transactions/day at $1 each, that is $5/day or $1,825/year in losses.
• Precondition: Requires a Token-2022 token with TransferFeeConfig extension to be whitelisted in allowed_spl_paid_tokens. The existing test infrastructure already creates such tokens (TestAccountSetup::create_usdc_mint_2022() with 100 bps / 1% fee).

Recommendation

Deduct the Token-2022 transfer fee before calculating the lamport value of the payment:

// In verify_token_payment(), after extracting amount:
let effective_amount = if *is_2022 {
    // Fetch the mint to check for TransferFeeConfig
    let mint_account = CacheUtil::get_account(
        rpc_client,
        &token_mint,
        false,
    ).await?;
    let mint_info = Token2022MintInfo::from_account_data(&mint_account.data)?;

    if let Ok(Some(fee)) = mint_info.calculate_transfer_fee(
        *amount,
        rpc_client.get_epoch_info().await?.epoch,
    ) {
        amount.saturating_sub(fee)
    } else {
        *amount
    }
} else {
    *amount
};

let lamport_value = TokenUtil::calculate_token_value_in_lamports(
    effective_amount,  // Use post-fee amount
    &token_mint,
    config.validation.price_source.clone(),
    rpc_client,
)
.await?;

References

• crates/lib/src/token/token.rs:529-654 — verify_token_payment() using raw amount
• crates/lib/src/token/spl_token_2022.rs:165-198 — calculate_transfer_fee() (exists but not called in verification)
• crates/lib/src/fee/fee.rs:174-204 — analyze_payment_instructions() (correctly accounts for transfer fee in estimation)
• SPL Token-2022 specification: transfer fees are deducted from the transfer amount by the on-chain program

Summary

When inner CPI instructions use instruction types not recognized by Kora's parser (including Token-2022 extension instructions like ConfidentialTransfer, TransferFeeExtension::WithdrawWithheldTokens, etc.), they are reconstructed as stub instructions with empty accounts and empty data. These stubs fail deserialization during fee payer policy validation and are silently skipped, meaning any fee payer usage within those instructions goes completely unchecked.

Severity

Medium

Affected Component

• File: crates/lib/src/transaction/instruction_util.rs
• Functions: reconstruct_system_instruction(), reconstruct_spl_token_instruction()
• Lines: 750–753, 1187–1189

Root Cause

The instruction reconstruction functions have a catch-all _ => arm for unrecognized instruction types that creates a stub CompiledInstruction with the correct program_id_index but empty accounts and empty data. When this stub reaches the fee payer policy parsing (parse_system_instructions / parse_token_instructions), deserialization of empty data fails. The parsing functions also have a catch-all _ => {} that silently skips the failed instruction. The result: the instruction exists in all_instructions (so program allowlist checks pass), but fee payer policy is never enforced on it.

Vulnerable Code

Stub Creation

// crates/lib/src/transaction/instruction_util.rs:750-753
// System program — unrecognized instruction type:
_ => {
    log::error!("Unsupported system instruction type: {}", instruction_type);
    Ok(Self::build_default_compiled_instruction(program_id_index))
}

// crates/lib/src/transaction/instruction_util.rs:1187-1189
// SPL Token program — unrecognized instruction type:
_ => {
    log::error!("Unsupported token instruction type: {}", instruction_type);
    Ok(Self::build_default_compiled_instruction(program_id_index))
}

The stub builder:

pub fn build_default_compiled_instruction(program_id_index: u8) -> CompiledInstruction {
    CompiledInstruction {
        program_id_index,
        accounts: vec![],  // <-- No accounts
        data: vec![],       // <-- No data
    }
}

Silent Skip During Policy Parsing

// In parse_system_instructions:
if let Ok(system_instruction) = bincode::deserialize::<SystemInstruction>(&instruction.data) {
    match system_instruction {
        // ... known types handled ...
        _ => {}  // <-- Unrecognized: silently skipped
    }
}
// If deserialize fails (empty data), the entire `if let Ok` block is skipped.
// The instruction is not added to any policy check map.

// In parse_token_instructions:
if let Ok(token_instruction) = TokenInstruction::unpack(&instruction.data) {
    match token_instruction {
        // ... known types handled ...
        _ => {}  // <-- Unrecognized: silently skipped
    }
}
// Same: empty data causes unpack to fail, instruction completely invisible to policy.

Proof of Concept

Affected Token-2022 Extension Instructions

The following Token-2022 extension instruction types are NOT handled by Kora's parser and would produce empty stubs:

| Extension | Instruction | Risk if Fee Payer is Authority | |-----------|------------|-------------------------------| | TransferFeeExtension | WithdrawWithheldTokensFromMint | Fee payer as withdraw authority can drain withheld fees | | TransferFeeExtension | WithdrawWithheldTokensFromAccounts | Same | | TransferFeeExtension | HarvestWithheldTokensToMint | Fee collection manipulation | | ConfidentialTransfer | Transfer | Hidden transfer amounts bypass fee tracking | | ConfidentialTransfer | Withdraw | Hidden withdrawals | | InterestBearingMint | UpdateRate | Fee payer as rate authority can manipulate interest | | TransferHook | Execute | Arbitrary hook execution | | GroupMemberPointer | Update | Metadata manipulation | | MetadataPointer | Update | Metadata manipulation | | PermanentDelegate | Transfer (via delegate) | Delegate-based unauthorized transfers |

Code Path Trace

1. Transaction contains an inner CPI instruction:
   Program: Token-2022
   Type: "withdrawWithheldTokensFromMint" (TransferFeeExtension)
   Accounts: [fee_payer (as withdraw_withheld_authority), mint, destination]

2. RPC returns this as a Parsed inner instruction

3. reconstruct_spl_token_instruction() is called:
   - instruction_type = "withdrawWithheldTokensFromMint"
   - No match in the known types (transfer, transferChecked, burn, etc.)
   - Falls through to _ => arm
   - Returns: CompiledInstruction { program_id_index, accounts: [], data: [] }

4. Stub is added to all_instructions
   → validate_programs() sees Token-2022 program ID → PASS (allowed)
   → validate_disallowed_accounts() sees no accounts in the stub → PASS

5. parse_token_instructions() processes the stub:
   - TokenInstruction::unpack(&[]) → Err (empty data)
   - if let Ok(...) block skipped entirely
   - Instruction not added to any ParsedSPLInstructionType map

6. validate_fee_payer_usage() iterates parsed SPL instructions:
   - No entry for "withdrawWithheldTokensFromMint"
   - Fee payer's usage as withdraw_withheld_authority is NEVER checked

7. Transaction is signed by Kora

8. On-chain: fee_payer (as withdraw authority) withdraws withheld
   transfer fees from the mint to attacker's account

Verifiable Test

#[test]
fn test_unrecognized_instruction_produces_empty_stub() {
    // Simulate what happens for an unrecognized Token-2022 instruction
    let program_id_index: u8 = 3; // Token-2022 at index 3

    // This is what the catch-all arm produces:
    let stub = IxUtils::build_default_compiled_instruction(program_id_index);

    assert_eq!(stub.accounts.len(), 0);  // No accounts
    assert_eq!(stub.data.len(), 0);      // No data

    // Attempt to parse it:
    let result = TokenInstruction::unpack(&stub.data);
    assert!(result.is_err());  // Cannot parse empty data

    // Therefore: fee payer policy is never applied to this instruction
    // The fee payer could be the withdraw_withheld_authority in the
    // REAL instruction, but the stub has zero accounts — invisible.
}

Impact

• Fee Payer Policy Bypass: Token-2022 extension instructions that use the fee payer as an authority are invisible to policy enforcement.
• Forward-Looking Risk: As Solana and SPL Token-2022 add new instruction types, they will automatically bypass all fee payer policy checks in Kora.
• Precondition: Requires the fee payer to hold some authority role (e.g., withdraw_withheld_authority, permanent_delegate) for Token-2022 accounts. This is unlikely in typical deployments but possible in misconfigured setups.

Recommendation

Reject transactions containing inner instructions with unrecognized types (fail-secure):

// In reconstruct_system_instruction:
_ => {
    return Err(KoraError::InvalidTransaction(format!(
        "Unrecognized system instruction type '{}' in CPI — \
         cannot validate fee payer policy. Transaction rejected.",
        instruction_type
    )));
}

// In reconstruct_spl_token_instruction:
_ => {
    return Err(KoraError::InvalidTransaction(format!(
        "Unrecognized SPL Token instruction type '{}' in CPI — \
         cannot validate fee payer policy. Transaction rejected.",
        instruction_type
    )));
}

Alternatively, maintain a list of known-safe instruction types that don't involve authority checks, and only reject truly unknown types.

References

• crates/lib/src/transaction/instruction_util.rs:750-753 — system instruction catch-all
• crates/lib/src/transaction/instruction_util.rs:1187-1189 — SPL token instruction catch-all
• crates/lib/src/transaction/instruction_util.rs:316-319 — build_default_compiled_instruction
• SPL Token-2022 instruction types — full list of extension instructions

Summary

When a user pays transaction fees using a Token-2022 token with a TransferFeeConfig extension, Kora's verify_token_payment() credits the full raw transfer amount as the payment value. However, the on-chain SPL Token-2022 program withholds a portion of that amount as a transfer fee, so the paymaster's destination account only receives amount - transfer_fee. This means the paymaster consistently credits more value than it actually receives, resulting in systematic financial loss.

Severity

High

Affected Component

• File: crates/lib/src/token/token.rs
• Function: verify_token_payment()
• Lines: 529–654 (specifically 633–639)

Root Cause

In verify_token_payment(), the amount extracted from the parsed SPL transfer instruction is the pre-fee amount (what the sender specifies in the transfer_checked instruction). The function passes this raw amount to calculate_token_value_in_lamports() to determine how many lamports the payment is worth. It never subtracts the Token-2022 transfer fee.

The fee estimation path (fee.rs:analyze_payment_instructions) correctly accounts for transfer fees by calculating them and adding them to the total fee. But the verification path does not perform the inverse subtraction, creating an asymmetry.

Vulnerable Code

// crates/lib/src/token/token.rs:529-654
pub async fn verify_token_payment(
    transaction_resolved: &mut VersionedTransactionResolved,
    rpc_client: &RpcClient,
    required_lamports: u64,
    expected_destination_owner: &Pubkey,
) -> Result<bool, KoraError> {
    let config = get_config()?;
    let mut total_lamport_value = 0u64;

    // ...

    for instruction in transaction_resolved
        .get_or_parse_spl_instructions()?
        .get(&ParsedSPLInstructionType::SplTokenTransfer)
        .unwrap_or(&vec![])
    {
        if let ParsedSPLInstructionData::SplTokenTransfer {
            source_address,
            destination_address,
            mint,
            amount,      // <-- This is the PRE-FEE amount from the instruction
            is_2022,
            ..
        } = instruction
        {
            // ... destination validation ...

            // LINE 633-639: Uses raw *amount without deducting transfer fee
            let lamport_value = TokenUtil::calculate_token_value_in_lamports(
                *amount,        // <-- BUG: Should be (amount - transfer_fee)
                &token_mint,
                config.validation.price_source.clone(),
                rpc_client,
            )
            .await?;

            total_lamport_value = total_lamport_value
                .checked_add(lamport_value)
                .ok_or_else(|| {
                    KoraError::ValidationError("Payment accumulation overflow".to_string())
                })?;
        }
    }

    Ok(total_lamport_value >= required_lamports)
}

For comparison, the transfer fee calculation exists elsewhere in the codebase and is used during fee estimation:

// crates/lib/src/token/spl_token_2022.rs:165-198
pub fn calculate_transfer_fee(
    &self,
    amount: u64,
    current_epoch: u64,
) -> Result<Option<u64>, KoraError> {
    if let Some(fee_config) = self.get_transfer_fee() {
        let transfer_fee = if current_epoch >= u64::from(fee_config.newer_transfer_fee.epoch) {
            &fee_config.newer_transfer_fee
        } else {
            &fee_config.older_transfer_fee
        };
        let basis_points = u16::from(transfer_fee.transfer_fee_basis_points);
        let maximum_fee = u64::from(transfer_fee.maximum_fee);
        let fee_amount = (amount as u128)
            .checked_mul(basis_points as u128)
            .and_then(|product| product.checked_div(10_000))
            // ...
        Ok(Some(std::cmp::min(fee_amount, maximum_fee)))
    } else {
        Ok(None)
    }
}

This function exists but is never called in verify_token_payment().

Proof of Concept

Arithmetic Demonstration

Given:

• Token-2022 token with 5% transfer fee (500 basis points), whitelisted in allowed_spl_paid_tokens
• Transaction fee cost: 5000 lamports equivalent
• Token price: 1 token = 5 lamports

What should happen:

• User needs to pay 5000 lamports worth → 1000 tokens
• Transfer fee on 1000 tokens at 5% = 50 tokens
• Paymaster destination receives: 1000 - 50 = 950 tokens (worth 4750 lamports)
• User should be required to pay MORE to cover the fee

What actually happens:

• User sends transfer_checked for amount = 1000 tokens
• verify_token_payment() calculates: 1000 tokens * 5 lamports/token = 5000 lamports
• 5000 >= 5000 required → payment verified as sufficient
• But paymaster only received 950 tokens (worth 4750 lamports)
• Paymaster lost 250 lamports on this transaction

Over 1000 transactions: Paymaster loses 250,000 lamports (0.25 SOL)

Runnable Test (using existing test infrastructure)

#[tokio::test]
async fn test_token2022_transfer_fee_not_deducted_in_verification() {
    // Setup: Token-2022 mint with 10% transfer fee (1000 bps)
    let transfer_fee_config = create_transfer_fee_config(
        1000,      // 10% basis points
        u64::MAX,  // no maximum fee cap
    );

    let mint_pubkey = Pubkey::new_unique();
    let mint_account = MintAccountMockBuilder::new()
        .with_decimals(6)
        .with_supply(1_000_000_000_000)
        .with_extension(ExtensionType::TransferFeeConfig)
        .build_token2022();

    // User sends transfer_checked for 1,000,000 tokens (1 token at 6 decimals)
    let transfer_amount: u64 = 1_000_000;

    // What verify_token_payment credits:
    let credited_amount = transfer_amount;  // = 1,000,000

    // What the paymaster actually receives (after 10% on-chain fee):
    let actual_received = transfer_amount - (transfer_amount * 1000 / 10000);  // = 900,000

    // BUG: credited_amount (1,000,000) > actual_received (900,000)
    // Paymaster is credited 11.1% MORE than it actually receives
    assert!(credited_amount > actual_received);
    assert_eq!(credited_amount - actual_received, 100_000); // 100,000 token units lost

    // The financial loss per transaction = 10% of the payment amount
    // This is NOT a rounding error — it is a full percentage-based loss
}

Impact

• Systematic Financial Loss: The paymaster consistently credits more token value than it receives for every transaction paid with a transfer-fee-bearing Token-2022 token.
• Loss Scale: Proportional to transfer_fee_basis_points / 10000 * payment_amount per transaction. For a token with 5% fee and 100 transactions/day at $1 each, that is $5/day or $1,825/year in losses.
• Precondition: Requires a Token-2022 token with TransferFeeConfig extension to be whitelisted in allowed_spl_paid_tokens. The existing test infrastructure already creates such tokens (TestAccountSetup::create_usdc_mint_2022() with 100 bps / 1% fee).

Recommendation

Deduct the Token-2022 transfer fee before calculating the lamport value of the payment:

// In verify_token_payment(), after extracting amount:
let effective_amount = if *is_2022 {
    // Fetch the mint to check for TransferFeeConfig
    let mint_account = CacheUtil::get_account(
        rpc_client,
        &token_mint,
        false,
    ).await?;
    let mint_info = Token2022MintInfo::from_account_data(&mint_account.data)?;

    if let Ok(Some(fee)) = mint_info.calculate_transfer_fee(
        *amount,
        rpc_client.get_epoch_info().await?.epoch,
    ) {
        amount.saturating_sub(fee)
    } else {
        *amount
    }
} else {
    *amount
};

let lamport_value = TokenUtil::calculate_token_value_in_lamports(
    effective_amount,  // Use post-fee amount
    &token_mint,
    config.validation.price_source.clone(),
    rpc_client,
)
.await?;

References

• crates/lib/src/token/token.rs:529-654 — verify_token_payment() using raw amount
• crates/lib/src/token/spl_token_2022.rs:165-198 — calculate_transfer_fee() (exists but not called in verification)
• crates/lib/src/fee/fee.rs:174-204 — analyze_payment_instructions() (correctly accounts for transfer fee in estimation)
• SPL Token-2022 specification: transfer fees are deducted from the transfer amount by the on-chain program

Summary

When inner CPI instructions use instruction types not recognized by Kora's parser (including Token-2022 extension instructions like ConfidentialTransfer, TransferFeeExtension::WithdrawWithheldTokens, etc.), they are reconstructed as stub instructions with empty accounts and empty data. These stubs fail deserialization during fee payer policy validation and are silently skipped, meaning any fee payer usage within those instructions goes completely unchecked.

Severity

Medium

Affected Component

• File: crates/lib/src/transaction/instruction_util.rs
• Functions: reconstruct_system_instruction(), reconstruct_spl_token_instruction()
• Lines: 750–753, 1187–1189

Root Cause

The instruction reconstruction functions have a catch-all _ => arm for unrecognized instruction types that creates a stub CompiledInstruction with the correct program_id_index but empty accounts and empty data. When this stub reaches the fee payer policy parsing (parse_system_instructions / parse_token_instructions), deserialization of empty data fails. The parsing functions also have a catch-all _ => {} that silently skips the failed instruction. The result: the instruction exists in all_instructions (so program allowlist checks pass), but fee payer policy is never enforced on it.

Vulnerable Code

Stub Creation

// crates/lib/src/transaction/instruction_util.rs:750-753
// System program — unrecognized instruction type:
_ => {
    log::error!("Unsupported system instruction type: {}", instruction_type);
    Ok(Self::build_default_compiled_instruction(program_id_index))
}

// crates/lib/src/transaction/instruction_util.rs:1187-1189
// SPL Token program — unrecognized instruction type:
_ => {
    log::error!("Unsupported token instruction type: {}", instruction_type);
    Ok(Self::build_default_compiled_instruction(program_id_index))
}

The stub builder:

pub fn build_default_compiled_instruction(program_id_index: u8) -> CompiledInstruction {
    CompiledInstruction {
        program_id_index,
        accounts: vec![],  // <-- No accounts
        data: vec![],       // <-- No data
    }
}

Silent Skip During Policy Parsing

// In parse_system_instructions:
if let Ok(system_instruction) = bincode::deserialize::<SystemInstruction>(&instruction.data) {
    match system_instruction {
        // ... known types handled ...
        _ => {}  // <-- Unrecognized: silently skipped
    }
}
// If deserialize fails (empty data), the entire `if let Ok` block is skipped.
// The instruction is not added to any policy check map.

// In parse_token_instructions:
if let Ok(token_instruction) = TokenInstruction::unpack(&instruction.data) {
    match token_instruction {
        // ... known types handled ...
        _ => {}  // <-- Unrecognized: silently skipped
    }
}
// Same: empty data causes unpack to fail, instruction completely invisible to policy.

Proof of Concept

Affected Token-2022 Extension Instructions

The following Token-2022 extension instruction types are NOT handled by Kora's parser and would produce empty stubs:

| Extension | Instruction | Risk if Fee Payer is Authority | |-----------|------------|-------------------------------| | TransferFeeExtension | WithdrawWithheldTokensFromMint | Fee payer as withdraw authority can drain withheld fees | | TransferFeeExtension | WithdrawWithheldTokensFromAccounts | Same | | TransferFeeExtension | HarvestWithheldTokensToMint | Fee collection manipulation | | ConfidentialTransfer | Transfer | Hidden transfer amounts bypass fee tracking | | ConfidentialTransfer | Withdraw | Hidden withdrawals | | InterestBearingMint | UpdateRate | Fee payer as rate authority can manipulate interest | | TransferHook | Execute | Arbitrary hook execution | | GroupMemberPointer | Update | Metadata manipulation | | MetadataPointer | Update | Metadata manipulation | | PermanentDelegate | Transfer (via delegate) | Delegate-based unauthorized transfers |

Code Path Trace

1. Transaction contains an inner CPI instruction:
   Program: Token-2022
   Type: "withdrawWithheldTokensFromMint" (TransferFeeExtension)
   Accounts: [fee_payer (as withdraw_withheld_authority), mint, destination]

2. RPC returns this as a Parsed inner instruction

3. reconstruct_spl_token_instruction() is called:
   - instruction_type = "withdrawWithheldTokensFromMint"
   - No match in the known types (transfer, transferChecked, burn, etc.)
   - Falls through to _ => arm
   - Returns: CompiledInstruction { program_id_index, accounts: [], data: [] }

4. Stub is added to all_instructions
   → validate_programs() sees Token-2022 program ID → PASS (allowed)
   → validate_disallowed_accounts() sees no accounts in the stub → PASS

5. parse_token_instructions() processes the stub:
   - TokenInstruction::unpack(&[]) → Err (empty data)
   - if let Ok(...) block skipped entirely
   - Instruction not added to any ParsedSPLInstructionType map

6. validate_fee_payer_usage() iterates parsed SPL instructions:
   - No entry for "withdrawWithheldTokensFromMint"
   - Fee payer's usage as withdraw_withheld_authority is NEVER checked

7. Transaction is signed by Kora

8. On-chain: fee_payer (as withdraw authority) withdraws withheld
   transfer fees from the mint to attacker's account

Verifiable Test

#[test]
fn test_unrecognized_instruction_produces_empty_stub() {
    // Simulate what happens for an unrecognized Token-2022 instruction
    let program_id_index: u8 = 3; // Token-2022 at index 3

    // This is what the catch-all arm produces:
    let stub = IxUtils::build_default_compiled_instruction(program_id_index);

    assert_eq!(stub.accounts.len(), 0);  // No accounts
    assert_eq!(stub.data.len(), 0);      // No data

    // Attempt to parse it:
    let result = TokenInstruction::unpack(&stub.data);
    assert!(result.is_err());  // Cannot parse empty data

    // Therefore: fee payer policy is never applied to this instruction
    // The fee payer could be the withdraw_withheld_authority in the
    // REAL instruction, but the stub has zero accounts — invisible.
}

Impact

• Fee Payer Policy Bypass: Token-2022 extension instructions that use the fee payer as an authority are invisible to policy enforcement.
• Forward-Looking Risk: As Solana and SPL Token-2022 add new instruction types, they will automatically bypass all fee payer policy checks in Kora.
• Precondition: Requires the fee payer to hold some authority role (e.g., withdraw_withheld_authority, permanent_delegate) for Token-2022 accounts. This is unlikely in typical deployments but possible in misconfigured setups.

Recommendation

Reject transactions containing inner instructions with unrecognized types (fail-secure):

// In reconstruct_system_instruction:
_ => {
    return Err(KoraError::InvalidTransaction(format!(
        "Unrecognized system instruction type '{}' in CPI — \
         cannot validate fee payer policy. Transaction rejected.",
        instruction_type
    )));
}

// In reconstruct_spl_token_instruction:
_ => {
    return Err(KoraError::InvalidTransaction(format!(
        "Unrecognized SPL Token instruction type '{}' in CPI — \
         cannot validate fee payer policy. Transaction rejected.",
        instruction_type
    )));
}

Alternatively, maintain a list of known-safe instruction types that don't involve authority checks, and only reject truly unknown types.

References

• crates/lib/src/transaction/instruction_util.rs:750-753 — system instruction catch-all
• crates/lib/src/transaction/instruction_util.rs:1187-1189 — SPL token instruction catch-all
• crates/lib/src/transaction/instruction_util.rs:316-319 — build_default_compiled_instruction
• SPL Token-2022 instruction types — full list of extension instructions

Summary

When a user pays transaction fees using a Token-2022 token with a TransferFeeConfig extension, Kora's verify_token_payment() credits the full raw transfer amount as the payment value. However, the on-chain SPL Token-2022 program withholds a portion of that amount as a transfer fee, so the paymaster's destination account only receives amount - transfer_fee. This means the paymaster consistently credits more value than it actually receives, resulting in systematic financial loss.

Severity

High

Affected Component

• File: crates/lib/src/token/token.rs
• Function: verify_token_payment()
• Lines: 529–654 (specifically 633–639)

Root Cause

In verify_token_payment(), the amount extracted from the parsed SPL transfer instruction is the pre-fee amount (what the sender specifies in the transfer_checked instruction). The function passes this raw amount to calculate_token_value_in_lamports() to determine how many lamports the payment is worth. It never subtracts the Token-2022 transfer fee.

The fee estimation path (fee.rs:analyze_payment_instructions) correctly accounts for transfer fees by calculating them and adding them to the total fee. But the verification path does not perform the inverse subtraction, creating an asymmetry.

Vulnerable Code

// crates/lib/src/token/token.rs:529-654
pub async fn verify_token_payment(
    transaction_resolved: &mut VersionedTransactionResolved,
    rpc_client: &RpcClient,
    required_lamports: u64,
    expected_destination_owner: &Pubkey,
) -> Result<bool, KoraError> {
    let config = get_config()?;
    let mut total_lamport_value = 0u64;

    // ...

    for instruction in transaction_resolved
        .get_or_parse_spl_instructions()?
        .get(&ParsedSPLInstructionType::SplTokenTransfer)
        .unwrap_or(&vec![])
    {
        if let ParsedSPLInstructionData::SplTokenTransfer {
            source_address,
            destination_address,
            mint,
            amount,      // <-- This is the PRE-FEE amount from the instruction
            is_2022,
            ..
        } = instruction
        {
            // ... destination validation ...

            // LINE 633-639: Uses raw *amount without deducting transfer fee
            let lamport_value = TokenUtil::calculate_token_value_in_lamports(
                *amount,        // <-- BUG: Should be (amount - transfer_fee)
                &token_mint,
                config.validation.price_source.clone(),
                rpc_client,
            )
            .await?;

            total_lamport_value = total_lamport_value
                .checked_add(lamport_value)
                .ok_or_else(|| {
                    KoraError::ValidationError("Payment accumulation overflow".to_string())
                })?;
        }
    }

    Ok(total_lamport_value >= required_lamports)
}

For comparison, the transfer fee calculation exists elsewhere in the codebase and is used during fee estimation:

// crates/lib/src/token/spl_token_2022.rs:165-198
pub fn calculate_transfer_fee(
    &self,
    amount: u64,
    current_epoch: u64,
) -> Result<Option<u64>, KoraError> {
    if let Some(fee_config) = self.get_transfer_fee() {
        let transfer_fee = if current_epoch >= u64::from(fee_config.newer_transfer_fee.epoch) {
            &fee_config.newer_transfer_fee
        } else {
            &fee_config.older_transfer_fee
        };
        let basis_points = u16::from(transfer_fee.transfer_fee_basis_points);
        let maximum_fee = u64::from(transfer_fee.maximum_fee);
        let fee_amount = (amount as u128)
            .checked_mul(basis_points as u128)
            .and_then(|product| product.checked_div(10_000))
            // ...
        Ok(Some(std::cmp::min(fee_amount, maximum_fee)))
    } else {
        Ok(None)
    }
}

This function exists but is never called in verify_token_payment().

Proof of Concept

Arithmetic Demonstration

Given:

• Token-2022 token with 5% transfer fee (500 basis points), whitelisted in allowed_spl_paid_tokens
• Transaction fee cost: 5000 lamports equivalent
• Token price: 1 token = 5 lamports

What should happen:

• User needs to pay 5000 lamports worth → 1000 tokens
• Transfer fee on 1000 tokens at 5% = 50 tokens
• Paymaster destination receives: 1000 - 50 = 950 tokens (worth 4750 lamports)
• User should be required to pay MORE to cover the fee

What actually happens:

• User sends transfer_checked for amount = 1000 tokens
• verify_token_payment() calculates: 1000 tokens * 5 lamports/token = 5000 lamports
• 5000 >= 5000 required → payment verified as sufficient
• But paymaster only received 950 tokens (worth 4750 lamports)
• Paymaster lost 250 lamports on this transaction

Over 1000 transactions: Paymaster loses 250,000 lamports (0.25 SOL)

Runnable Test (using existing test infrastructure)

#[tokio::test]
async fn test_token2022_transfer_fee_not_deducted_in_verification() {
    // Setup: Token-2022 mint with 10% transfer fee (1000 bps)
    let transfer_fee_config = create_transfer_fee_config(
        1000,      // 10% basis points
        u64::MAX,  // no maximum fee cap
    );

    let mint_pubkey = Pubkey::new_unique();
    let mint_account = MintAccountMockBuilder::new()
        .with_decimals(6)
        .with_supply(1_000_000_000_000)
        .with_extension(ExtensionType::TransferFeeConfig)
        .build_token2022();

    // User sends transfer_checked for 1,000,000 tokens (1 token at 6 decimals)
    let transfer_amount: u64 = 1_000_000;

    // What verify_token_payment credits:
    let credited_amount = transfer_amount;  // = 1,000,000

    // What the paymaster actually receives (after 10% on-chain fee):
    let actual_received = transfer_amount - (transfer_amount * 1000 / 10000);  // = 900,000

    // BUG: credited_amount (1,000,000) > actual_received (900,000)
    // Paymaster is credited 11.1% MORE than it actually receives
    assert!(credited_amount > actual_received);
    assert_eq!(credited_amount - actual_received, 100_000); // 100,000 token units lost

    // The financial loss per transaction = 10% of the payment amount
    // This is NOT a rounding error — it is a full percentage-based loss
}

Impact

• Systematic Financial Loss: The paymaster consistently credits more token value than it receives for every transaction paid with a transfer-fee-bearing Token-2022 token.
• Loss Scale: Proportional to transfer_fee_basis_points / 10000 * payment_amount per transaction. For a token with 5% fee and 100 transactions/day at $1 each, that is $5/day or $1,825/year in losses.
• Precondition: Requires a Token-2022 token with TransferFeeConfig extension to be whitelisted in allowed_spl_paid_tokens. The existing test infrastructure already creates such tokens (TestAccountSetup::create_usdc_mint_2022() with 100 bps / 1% fee).

Recommendation

Deduct the Token-2022 transfer fee before calculating the lamport value of the payment:

// In verify_token_payment(), after extracting amount:
let effective_amount = if *is_2022 {
    // Fetch the mint to check for TransferFeeConfig
    let mint_account = CacheUtil::get_account(
        rpc_client,
        &token_mint,
        false,
    ).await?;
    let mint_info = Token2022MintInfo::from_account_data(&mint_account.data)?;

    if let Ok(Some(fee)) = mint_info.calculate_transfer_fee(
        *amount,
        rpc_client.get_epoch_info().await?.epoch,
    ) {
        amount.saturating_sub(fee)
    } else {
        *amount
    }
} else {
    *amount
};

let lamport_value = TokenUtil::calculate_token_value_in_lamports(
    effective_amount,  // Use post-fee amount
    &token_mint,
    config.validation.price_source.clone(),
    rpc_client,
)
.await?;

References

• crates/lib/src/token/token.rs:529-654 — verify_token_payment() using raw amount
• crates/lib/src/token/spl_token_2022.rs:165-198 — calculate_transfer_fee() (exists but not called in verification)
• crates/lib/src/fee/fee.rs:174-204 — analyze_payment_instructions() (correctly accounts for transfer fee in estimation)
• SPL Token-2022 specification: transfer fees are deducted from the transfer amount by the on-chain program

Summary

When inner CPI instructions use instruction types not recognized by Kora's parser (including Token-2022 extension instructions like ConfidentialTransfer, TransferFeeExtension::WithdrawWithheldTokens, etc.), they are reconstructed as stub instructions with empty accounts and empty data. These stubs fail deserialization during fee payer policy validation and are silently skipped, meaning any fee payer usage within those instructions goes completely unchecked.

Severity

Medium

Affected Component

• File: crates/lib/src/transaction/instruction_util.rs
• Functions: reconstruct_system_instruction(), reconstruct_spl_token_instruction()
• Lines: 750–753, 1187–1189

Root Cause

The instruction reconstruction functions have a catch-all _ => arm for unrecognized instruction types that creates a stub CompiledInstruction with the correct program_id_index but empty accounts and empty data. When this stub reaches the fee payer policy parsing (parse_system_instructions / parse_token_instructions), deserialization of empty data fails. The parsing functions also have a catch-all _ => {} that silently skips the failed instruction. The result: the instruction exists in all_instructions (so program allowlist checks pass), but fee payer policy is never enforced on it.

Vulnerable Code

Stub Creation

// crates/lib/src/transaction/instruction_util.rs:750-753
// System program — unrecognized instruction type:
_ => {
    log::error!("Unsupported system instruction type: {}", instruction_type);
    Ok(Self::build_default_compiled_instruction(program_id_index))
}

// crates/lib/src/transaction/instruction_util.rs:1187-1189
// SPL Token program — unrecognized instruction type:
_ => {
    log::error!("Unsupported token instruction type: {}", instruction_type);
    Ok(Self::build_default_compiled_instruction(program_id_index))
}

The stub builder:

pub fn build_default_compiled_instruction(program_id_index: u8) -> CompiledInstruction {
    CompiledInstruction {
        program_id_index,
        accounts: vec![],  // <-- No accounts
        data: vec![],       // <-- No data
    }
}

Silent Skip During Policy Parsing

// In parse_system_instructions:
if let Ok(system_instruction) = bincode::deserialize::<SystemInstruction>(&instruction.data) {
    match system_instruction {
        // ... known types handled ...
        _ => {}  // <-- Unrecognized: silently skipped
    }
}
// If deserialize fails (empty data), the entire `if let Ok` block is skipped.
// The instruction is not added to any policy check map.

// In parse_token_instructions:
if let Ok(token_instruction) = TokenInstruction::unpack(&instruction.data) {
    match token_instruction {
        // ... known types handled ...
        _ => {}  // <-- Unrecognized: silently skipped
    }
}
// Same: empty data causes unpack to fail, instruction completely invisible to policy.

Proof of Concept

Affected Token-2022 Extension Instructions

The following Token-2022 extension instruction types are NOT handled by Kora's parser and would produce empty stubs:

| Extension | Instruction | Risk if Fee Payer is Authority | |-----------|------------|-------------------------------| | TransferFeeExtension | WithdrawWithheldTokensFromMint | Fee payer as withdraw authority can drain withheld fees | | TransferFeeExtension | WithdrawWithheldTokensFromAccounts | Same | | TransferFeeExtension | HarvestWithheldTokensToMint | Fee collection manipulation | | ConfidentialTransfer | Transfer | Hidden transfer amounts bypass fee tracking | | ConfidentialTransfer | Withdraw | Hidden withdrawals | | InterestBearingMint | UpdateRate | Fee payer as rate authority can manipulate interest | | TransferHook | Execute | Arbitrary hook execution | | GroupMemberPointer | Update | Metadata manipulation | | MetadataPointer | Update | Metadata manipulation | | PermanentDelegate | Transfer (via delegate) | Delegate-based unauthorized transfers |

Code Path Trace

1. Transaction contains an inner CPI instruction:
   Program: Token-2022
   Type: "withdrawWithheldTokensFromMint" (TransferFeeExtension)
   Accounts: [fee_payer (as withdraw_withheld_authority), mint, destination]

2. RPC returns this as a Parsed inner instruction

3. reconstruct_spl_token_instruction() is called:
   - instruction_type = "withdrawWithheldTokensFromMint"
   - No match in the known types (transfer, transferChecked, burn, etc.)
   - Falls through to _ => arm
   - Returns: CompiledInstruction { program_id_index, accounts: [], data: [] }

4. Stub is added to all_instructions
   → validate_programs() sees Token-2022 program ID → PASS (allowed)
   → validate_disallowed_accounts() sees no accounts in the stub → PASS

5. parse_token_instructions() processes the stub:
   - TokenInstruction::unpack(&[]) → Err (empty data)
   - if let Ok(...) block skipped entirely
   - Instruction not added to any ParsedSPLInstructionType map

6. validate_fee_payer_usage() iterates parsed SPL instructions:
   - No entry for "withdrawWithheldTokensFromMint"
   - Fee payer's usage as withdraw_withheld_authority is NEVER checked

7. Transaction is signed by Kora

8. On-chain: fee_payer (as withdraw authority) withdraws withheld
   transfer fees from the mint to attacker's account

Verifiable Test

#[test]
fn test_unrecognized_instruction_produces_empty_stub() {
    // Simulate what happens for an unrecognized Token-2022 instruction
    let program_id_index: u8 = 3; // Token-2022 at index 3

    // This is what the catch-all arm produces:
    let stub = IxUtils::build_default_compiled_instruction(program_id_index);

    assert_eq!(stub.accounts.len(), 0);  // No accounts
    assert_eq!(stub.data.len(), 0);      // No data

    // Attempt to parse it:
    let result = TokenInstruction::unpack(&stub.data);
    assert!(result.is_err());  // Cannot parse empty data

    // Therefore: fee payer policy is never applied to this instruction
    // The fee payer could be the withdraw_withheld_authority in the
    // REAL instruction, but the stub has zero accounts — invisible.
}

Impact

• Fee Payer Policy Bypass: Token-2022 extension instructions that use the fee payer as an authority are invisible to policy enforcement.
• Forward-Looking Risk: As Solana and SPL Token-2022 add new instruction types, they will automatically bypass all fee payer policy checks in Kora.
• Precondition: Requires the fee payer to hold some authority role (e.g., withdraw_withheld_authority, permanent_delegate) for Token-2022 accounts. This is unlikely in typical deployments but possible in misconfigured setups.

Recommendation

Reject transactions containing inner instructions with unrecognized types (fail-secure):

// In reconstruct_system_instruction:
_ => {
    return Err(KoraError::InvalidTransaction(format!(
        "Unrecognized system instruction type '{}' in CPI — \
         cannot validate fee payer policy. Transaction rejected.",
        instruction_type
    )));
}

// In reconstruct_spl_token_instruction:
_ => {
    return Err(KoraError::InvalidTransaction(format!(
        "Unrecognized SPL Token instruction type '{}' in CPI — \
         cannot validate fee payer policy. Transaction rejected.",
        instruction_type
    )));
}

Alternatively, maintain a list of known-safe instruction types that don't involve authority checks, and only reject truly unknown types.

References

• crates/lib/src/transaction/instruction_util.rs:750-753 — system instruction catch-all
• crates/lib/src/transaction/instruction_util.rs:1187-1189 — SPL token instruction catch-all
• crates/lib/src/transaction/instruction_util.rs:316-319 — build_default_compiled_instruction
• SPL Token-2022 instruction types — full list of extension instructions

Summary

When a user pays transaction fees using a Token-2022 token with a TransferFeeConfig extension, Kora's verify_token_payment() credits the full raw transfer amount as the payment value. However, the on-chain SPL Token-2022 program withholds a portion of that amount as a transfer fee, so the paymaster's destination account only receives amount - transfer_fee. This means the paymaster consistently credits more value than it actually receives, resulting in systematic financial loss.

Severity

High

Affected Component

• File: crates/lib/src/token/token.rs
• Function: verify_token_payment()
• Lines: 529–654 (specifically 633–639)

Root Cause

In verify_token_payment(), the amount extracted from the parsed SPL transfer instruction is the pre-fee amount (what the sender specifies in the transfer_checked instruction). The function passes this raw amount to calculate_token_value_in_lamports() to determine how many lamports the payment is worth. It never subtracts the Token-2022 transfer fee.

The fee estimation path (fee.rs:analyze_payment_instructions) correctly accounts for transfer fees by calculating them and adding them to the total fee. But the verification path does not perform the inverse subtraction, creating an asymmetry.

Vulnerable Code

// crates/lib/src/token/token.rs:529-654
pub async fn verify_token_payment(
    transaction_resolved: &mut VersionedTransactionResolved,
    rpc_client: &RpcClient,
    required_lamports: u64,
    expected_destination_owner: &Pubkey,
) -> Result<bool, KoraError> {
    let config = get_config()?;
    let mut total_lamport_value = 0u64;

    // ...

    for instruction in transaction_resolved
        .get_or_parse_spl_instructions()?
        .get(&ParsedSPLInstructionType::SplTokenTransfer)
        .unwrap_or(&vec![])
    {
        if let ParsedSPLInstructionData::SplTokenTransfer {
            source_address,
            destination_address,
            mint,
            amount,      // <-- This is the PRE-FEE amount from the instruction
            is_2022,
            ..
        } = instruction
        {
            // ... destination validation ...

            // LINE 633-639: Uses raw *amount without deducting transfer fee
            let lamport_value = TokenUtil::calculate_token_value_in_lamports(
                *amount,        // <-- BUG: Should be (amount - transfer_fee)
                &token_mint,
                config.validation.price_source.clone(),
                rpc_client,
            )
            .await?;

            total_lamport_value = total_lamport_value
                .checked_add(lamport_value)
                .ok_or_else(|| {
                    KoraError::ValidationError("Payment accumulation overflow".to_string())
                })?;
        }
    }

    Ok(total_lamport_value >= required_lamports)
}

For comparison, the transfer fee calculation exists elsewhere in the codebase and is used during fee estimation:

// crates/lib/src/token/spl_token_2022.rs:165-198
pub fn calculate_transfer_fee(
    &self,
    amount: u64,
    current_epoch: u64,
) -> Result<Option<u64>, KoraError> {
    if let Some(fee_config) = self.get_transfer_fee() {
        let transfer_fee = if current_epoch >= u64::from(fee_config.newer_transfer_fee.epoch) {
            &fee_config.newer_transfer_fee
        } else {
            &fee_config.older_transfer_fee
        };
        let basis_points = u16::from(transfer_fee.transfer_fee_basis_points);
        let maximum_fee = u64::from(transfer_fee.maximum_fee);
        let fee_amount = (amount as u128)
            .checked_mul(basis_points as u128)
            .and_then(|product| product.checked_div(10_000))
            // ...
        Ok(Some(std::cmp::min(fee_amount, maximum_fee)))
    } else {
        Ok(None)
    }
}

This function exists but is never called in verify_token_payment().

Proof of Concept

Arithmetic Demonstration

Given:

• Token-2022 token with 5% transfer fee (500 basis points), whitelisted in allowed_spl_paid_tokens
• Transaction fee cost: 5000 lamports equivalent
• Token price: 1 token = 5 lamports

What should happen:

• User needs to pay 5000 lamports worth → 1000 tokens
• Transfer fee on 1000 tokens at 5% = 50 tokens
• Paymaster destination receives: 1000 - 50 = 950 tokens (worth 4750 lamports)
• User should be required to pay MORE to cover the fee

What actually happens:

• User sends transfer_checked for amount = 1000 tokens
• verify_token_payment() calculates: 1000 tokens * 5 lamports/token = 5000 lamports
• 5000 >= 5000 required → payment verified as sufficient
• But paymaster only received 950 tokens (worth 4750 lamports)
• Paymaster lost 250 lamports on this transaction

Over 1000 transactions: Paymaster loses 250,000 lamports (0.25 SOL)

Runnable Test (using existing test infrastructure)

#[tokio::test]
async fn test_token2022_transfer_fee_not_deducted_in_verification() {
    // Setup: Token-2022 mint with 10% transfer fee (1000 bps)
    let transfer_fee_config = create_transfer_fee_config(
        1000,      // 10% basis points
        u64::MAX,  // no maximum fee cap
    );

    let mint_pubkey = Pubkey::new_unique();
    let mint_account = MintAccountMockBuilder::new()
        .with_decimals(6)
        .with_supply(1_000_000_000_000)
        .with_extension(ExtensionType::TransferFeeConfig)
        .build_token2022();

    // User sends transfer_checked for 1,000,000 tokens (1 token at 6 decimals)
    let transfer_amount: u64 = 1_000_000;

    // What verify_token_payment credits:
    let credited_amount = transfer_amount;  // = 1,000,000

    // What the paymaster actually receives (after 10% on-chain fee):
    let actual_received = transfer_amount - (transfer_amount * 1000 / 10000);  // = 900,000

    // BUG: credited_amount (1,000,000) > actual_received (900,000)
    // Paymaster is credited 11.1% MORE than it actually receives
    assert!(credited_amount > actual_received);
    assert_eq!(credited_amount - actual_received, 100_000); // 100,000 token units lost

    // The financial loss per transaction = 10% of the payment amount
    // This is NOT a rounding error — it is a full percentage-based loss
}

Impact

• Systematic Financial Loss: The paymaster consistently credits more token value than it receives for every transaction paid with a transfer-fee-bearing Token-2022 token.
• Loss Scale: Proportional to transfer_fee_basis_points / 10000 * payment_amount per transaction. For a token with 5% fee and 100 transactions/day at $1 each, that is $5/day or $1,825/year in losses.
• Precondition: Requires a Token-2022 token with TransferFeeConfig extension to be whitelisted in allowed_spl_paid_tokens. The existing test infrastructure already creates such tokens (TestAccountSetup::create_usdc_mint_2022() with 100 bps / 1% fee).

Recommendation

Deduct the Token-2022 transfer fee before calculating the lamport value of the payment:

// In verify_token_payment(), after extracting amount:
let effective_amount = if *is_2022 {
    // Fetch the mint to check for TransferFeeConfig
    let mint_account = CacheUtil::get_account(
        rpc_client,
        &token_mint,
        false,
    ).await?;
    let mint_info = Token2022MintInfo::from_account_data(&mint_account.data)?;

    if let Ok(Some(fee)) = mint_info.calculate_transfer_fee(
        *amount,
        rpc_client.get_epoch_info().await?.epoch,
    ) {
        amount.saturating_sub(fee)
    } else {
        *amount
    }
} else {
    *amount
};

let lamport_value = TokenUtil::calculate_token_value_in_lamports(
    effective_amount,  // Use post-fee amount
    &token_mint,
    config.validation.price_source.clone(),
    rpc_client,
)
.await?;

References

• crates/lib/src/token/token.rs:529-654 — verify_token_payment() using raw amount
• crates/lib/src/token/spl_token_2022.rs:165-198 — calculate_transfer_fee() (exists but not called in verification)
• crates/lib/src/fee/fee.rs:174-204 — analyze_payment_instructions() (correctly accounts for transfer fee in estimation)
• SPL Token-2022 specification: transfer fees are deducted from the transfer amount by the on-chain program

Summary

When inner CPI instructions use instruction types not recognized by Kora's parser (including Token-2022 extension instructions like ConfidentialTransfer, TransferFeeExtension::WithdrawWithheldTokens, etc.), they are reconstructed as stub instructions with empty accounts and empty data. These stubs fail deserialization during fee payer policy validation and are silently skipped, meaning any fee payer usage within those instructions goes completely unchecked.

Severity

Medium

Affected Component

• File: crates/lib/src/transaction/instruction_util.rs
• Functions: reconstruct_system_instruction(), reconstruct_spl_token_instruction()
• Lines: 750–753, 1187–1189

Root Cause

The instruction reconstruction functions have a catch-all _ => arm for unrecognized instruction types that creates a stub CompiledInstruction with the correct program_id_index but empty accounts and empty data. When this stub reaches the fee payer policy parsing (parse_system_instructions / parse_token_instructions), deserialization of empty data fails. The parsing functions also have a catch-all _ => {} that silently skips the failed instruction. The result: the instruction exists in all_instructions (so program allowlist checks pass), but fee payer policy is never enforced on it.

Vulnerable Code

Stub Creation

// crates/lib/src/transaction/instruction_util.rs:750-753
// System program — unrecognized instruction type:
_ => {
    log::error!("Unsupported system instruction type: {}", instruction_type);
    Ok(Self::build_default_compiled_instruction(program_id_index))
}

// crates/lib/src/transaction/instruction_util.rs:1187-1189
// SPL Token program — unrecognized instruction type:
_ => {
    log::error!("Unsupported token instruction type: {}", instruction_type);
    Ok(Self::build_default_compiled_instruction(program_id_index))
}

The stub builder:

pub fn build_default_compiled_instruction(program_id_index: u8) -> CompiledInstruction {
    CompiledInstruction {
        program_id_index,
        accounts: vec![],  // <-- No accounts
        data: vec![],       // <-- No data
    }
}

Silent Skip During Policy Parsing

// In parse_system_instructions:
if let Ok(system_instruction) = bincode::deserialize::<SystemInstruction>(&instruction.data) {
    match system_instruction {
        // ... known types handled ...
        _ => {}  // <-- Unrecognized: silently skipped
    }
}
// If deserialize fails (empty data), the entire `if let Ok` block is skipped.
// The instruction is not added to any policy check map.

// In parse_token_instructions:
if let Ok(token_instruction) = TokenInstruction::unpack(&instruction.data) {
    match token_instruction {
        // ... known types handled ...
        _ => {}  // <-- Unrecognized: silently skipped
    }
}
// Same: empty data causes unpack to fail, instruction completely invisible to policy.

Proof of Concept

Affected Token-2022 Extension Instructions

The following Token-2022 extension instruction types are NOT handled by Kora's parser and would produce empty stubs:

| Extension | Instruction | Risk if Fee Payer is Authority | |-----------|------------|-------------------------------| | TransferFeeExtension | WithdrawWithheldTokensFromMint | Fee payer as withdraw authority can drain withheld fees | | TransferFeeExtension | WithdrawWithheldTokensFromAccounts | Same | | TransferFeeExtension | HarvestWithheldTokensToMint | Fee collection manipulation | | ConfidentialTransfer | Transfer | Hidden transfer amounts bypass fee tracking | | ConfidentialTransfer | Withdraw | Hidden withdrawals | | InterestBearingMint | UpdateRate | Fee payer as rate authority can manipulate interest | | TransferHook | Execute | Arbitrary hook execution | | GroupMemberPointer | Update | Metadata manipulation | | MetadataPointer | Update | Metadata manipulation | | PermanentDelegate | Transfer (via delegate) | Delegate-based unauthorized transfers |

Code Path Trace

1. Transaction contains an inner CPI instruction:
   Program: Token-2022
   Type: "withdrawWithheldTokensFromMint" (TransferFeeExtension)
   Accounts: [fee_payer (as withdraw_withheld_authority), mint, destination]

2. RPC returns this as a Parsed inner instruction

3. reconstruct_spl_token_instruction() is called:
   - instruction_type = "withdrawWithheldTokensFromMint"
   - No match in the known types (transfer, transferChecked, burn, etc.)
   - Falls through to _ => arm
   - Returns: CompiledInstruction { program_id_index, accounts: [], data: [] }

4. Stub is added to all_instructions
   → validate_programs() sees Token-2022 program ID → PASS (allowed)
   → validate_disallowed_accounts() sees no accounts in the stub → PASS

5. parse_token_instructions() processes the stub:
   - TokenInstruction::unpack(&[]) → Err (empty data)
   - if let Ok(...) block skipped entirely
   - Instruction not added to any ParsedSPLInstructionType map

6. validate_fee_payer_usage() iterates parsed SPL instructions:
   - No entry for "withdrawWithheldTokensFromMint"
   - Fee payer's usage as withdraw_withheld_authority is NEVER checked

7. Transaction is signed by Kora

8. On-chain: fee_payer (as withdraw authority) withdraws withheld
   transfer fees from the mint to attacker's account

Verifiable Test

#[test]
fn test_unrecognized_instruction_produces_empty_stub() {
    // Simulate what happens for an unrecognized Token-2022 instruction
    let program_id_index: u8 = 3; // Token-2022 at index 3

    // This is what the catch-all arm produces:
    let stub = IxUtils::build_default_compiled_instruction(program_id_index);

    assert_eq!(stub.accounts.len(), 0);  // No accounts
    assert_eq!(stub.data.len(), 0);      // No data

    // Attempt to parse it:
    let result = TokenInstruction::unpack(&stub.data);
    assert!(result.is_err());  // Cannot parse empty data

    // Therefore: fee payer policy is never applied to this instruction
    // The fee payer could be the withdraw_withheld_authority in the
    // REAL instruction, but the stub has zero accounts — invisible.
}

Impact

• Fee Payer Policy Bypass: Token-2022 extension instructions that use the fee payer as an authority are invisible to policy enforcement.
• Forward-Looking Risk: As Solana and SPL Token-2022 add new instruction types, they will automatically bypass all fee payer policy checks in Kora.
• Precondition: Requires the fee payer to hold some authority role (e.g., withdraw_withheld_authority, permanent_delegate) for Token-2022 accounts. This is unlikely in typical deployments but possible in misconfigured setups.

Recommendation

Reject transactions containing inner instructions with unrecognized types (fail-secure):

// In reconstruct_system_instruction:
_ => {
    return Err(KoraError::InvalidTransaction(format!(
        "Unrecognized system instruction type '{}' in CPI — \
         cannot validate fee payer policy. Transaction rejected.",
        instruction_type
    )));
}

// In reconstruct_spl_token_instruction:
_ => {
    return Err(KoraError::InvalidTransaction(format!(
        "Unrecognized SPL Token instruction type '{}' in CPI — \
         cannot validate fee payer policy. Transaction rejected.",
        instruction_type
    )));
}

Alternatively, maintain a list of known-safe instruction types that don't involve authority checks, and only reject truly unknown types.

References

• crates/lib/src/transaction/instruction_util.rs:750-753 — system instruction catch-all
• crates/lib/src/transaction/instruction_util.rs:1187-1189 — SPL token instruction catch-all
• crates/lib/src/transaction/instruction_util.rs:316-319 — build_default_compiled_instruction
• SPL Token-2022 instruction types — full list of extension instructions

Summary

When a user pays transaction fees using a Token-2022 token with a TransferFeeConfig extension, Kora's verify_token_payment() credits the full raw transfer amount as the payment value. However, the on-chain SPL Token-2022 program withholds a portion of that amount as a transfer fee, so the paymaster's destination account only receives amount - transfer_fee. This means the paymaster consistently credits more value than it actually receives, resulting in systematic financial loss.

Severity

High

Affected Component

• File: crates/lib/src/token/token.rs
• Function: verify_token_payment()
• Lines: 529–654 (specifically 633–639)

Root Cause

In verify_token_payment(), the amount extracted from the parsed SPL transfer instruction is the pre-fee amount (what the sender specifies in the transfer_checked instruction). The function passes this raw amount to calculate_token_value_in_lamports() to determine how many lamports the payment is worth. It never subtracts the Token-2022 transfer fee.

The fee estimation path (fee.rs:analyze_payment_instructions) correctly accounts for transfer fees by calculating them and adding them to the total fee. But the verification path does not perform the inverse subtraction, creating an asymmetry.

Vulnerable Code

// crates/lib/src/token/token.rs:529-654
pub async fn verify_token_payment(
    transaction_resolved: &mut VersionedTransactionResolved,
    rpc_client: &RpcClient,
    required_lamports: u64,
    expected_destination_owner: &Pubkey,
) -> Result<bool, KoraError> {
    let config = get_config()?;
    let mut total_lamport_value = 0u64;

    // ...

    for instruction in transaction_resolved
        .get_or_parse_spl_instructions()?
        .get(&ParsedSPLInstructionType::SplTokenTransfer)
        .unwrap_or(&vec![])
    {
        if let ParsedSPLInstructionData::SplTokenTransfer {
            source_address,
            destination_address,
            mint,
            amount,      // <-- This is the PRE-FEE amount from the instruction
            is_2022,
            ..
        } = instruction
        {
            // ... destination validation ...

            // LINE 633-639: Uses raw *amount without deducting transfer fee
            let lamport_value = TokenUtil::calculate_token_value_in_lamports(
                *amount,        // <-- BUG: Should be (amount - transfer_fee)
                &token_mint,
                config.validation.price_source.clone(),
                rpc_client,
            )
            .await?;

            total_lamport_value = total_lamport_value
                .checked_add(lamport_value)
                .ok_or_else(|| {
                    KoraError::ValidationError("Payment accumulation overflow".to_string())
                })?;
        }
    }

    Ok(total_lamport_value >= required_lamports)
}

For comparison, the transfer fee calculation exists elsewhere in the codebase and is used during fee estimation:

// crates/lib/src/token/spl_token_2022.rs:165-198
pub fn calculate_transfer_fee(
    &self,
    amount: u64,
    current_epoch: u64,
) -> Result<Option<u64>, KoraError> {
    if let Some(fee_config) = self.get_transfer_fee() {
        let transfer_fee = if current_epoch >= u64::from(fee_config.newer_transfer_fee.epoch) {
            &fee_config.newer_transfer_fee
        } else {
            &fee_config.older_transfer_fee
        };
        let basis_points = u16::from(transfer_fee.transfer_fee_basis_points);
        let maximum_fee = u64::from(transfer_fee.maximum_fee);
        let fee_amount = (amount as u128)
            .checked_mul(basis_points as u128)
            .and_then(|product| product.checked_div(10_000))
            // ...
        Ok(Some(std::cmp::min(fee_amount, maximum_fee)))
    } else {
        Ok(None)
    }
}

This function exists but is never called in verify_token_payment().

Proof of Concept

Arithmetic Demonstration

Given:

• Token-2022 token with 5% transfer fee (500 basis points), whitelisted in allowed_spl_paid_tokens
• Transaction fee cost: 5000 lamports equivalent
• Token price: 1 token = 5 lamports

What should happen:

• User needs to pay 5000 lamports worth → 1000 tokens
• Transfer fee on 1000 tokens at 5% = 50 tokens
• Paymaster destination receives: 1000 - 50 = 950 tokens (worth 4750 lamports)
• User should be required to pay MORE to cover the fee

What actually happens:

• User sends transfer_checked for amount = 1000 tokens
• verify_token_payment() calculates: 1000 tokens * 5 lamports/token = 5000 lamports
• 5000 >= 5000 required → payment verified as sufficient
• But paymaster only received 950 tokens (worth 4750 lamports)
• Paymaster lost 250 lamports on this transaction

Over 1000 transactions: Paymaster loses 250,000 lamports (0.25 SOL)

Runnable Test (using existing test infrastructure)

#[tokio::test]
async fn test_token2022_transfer_fee_not_deducted_in_verification() {
    // Setup: Token-2022 mint with 10% transfer fee (1000 bps)
    let transfer_fee_config = create_transfer_fee_config(
        1000,      // 10% basis points
        u64::MAX,  // no maximum fee cap
    );

    let mint_pubkey = Pubkey::new_unique();
    let mint_account = MintAccountMockBuilder::new()
        .with_decimals(6)
        .with_supply(1_000_000_000_000)
        .with_extension(ExtensionType::TransferFeeConfig)
        .build_token2022();

    // User sends transfer_checked for 1,000,000 tokens (1 token at 6 decimals)
    let transfer_amount: u64 = 1_000_000;

    // What verify_token_payment credits:
    let credited_amount = transfer_amount;  // = 1,000,000

    // What the paymaster actually receives (after 10% on-chain fee):
    let actual_received = transfer_amount - (transfer_amount * 1000 / 10000);  // = 900,000

    // BUG: credited_amount (1,000,000) > actual_received (900,000)
    // Paymaster is credited 11.1% MORE than it actually receives
    assert!(credited_amount > actual_received);
    assert_eq!(credited_amount - actual_received, 100_000); // 100,000 token units lost

    // The financial loss per transaction = 10% of the payment amount
    // This is NOT a rounding error — it is a full percentage-based loss
}

Impact

• Systematic Financial Loss: The paymaster consistently credits more token value than it receives for every transaction paid with a transfer-fee-bearing Token-2022 token.
• Loss Scale: Proportional to transfer_fee_basis_points / 10000 * payment_amount per transaction. For a token with 5% fee and 100 transactions/day at $1 each, that is $5/day or $1,825/year in losses.
• Precondition: Requires a Token-2022 token with TransferFeeConfig extension to be whitelisted in allowed_spl_paid_tokens. The existing test infrastructure already creates such tokens (TestAccountSetup::create_usdc_mint_2022() with 100 bps / 1% fee).

Recommendation

Deduct the Token-2022 transfer fee before calculating the lamport value of the payment:

// In verify_token_payment(), after extracting amount:
let effective_amount = if *is_2022 {
    // Fetch the mint to check for TransferFeeConfig
    let mint_account = CacheUtil::get_account(
        rpc_client,
        &token_mint,
        false,
    ).await?;
    let mint_info = Token2022MintInfo::from_account_data(&mint_account.data)?;

    if let Ok(Some(fee)) = mint_info.calculate_transfer_fee(
        *amount,
        rpc_client.get_epoch_info().await?.epoch,
    ) {
        amount.saturating_sub(fee)
    } else {
        *amount
    }
} else {
    *amount
};

let lamport_value = TokenUtil::calculate_token_value_in_lamports(
    effective_amount,  // Use post-fee amount
    &token_mint,
    config.validation.price_source.clone(),
    rpc_client,
)
.await?;

References

• crates/lib/src/token/token.rs:529-654 — verify_token_payment() using raw amount
• crates/lib/src/token/spl_token_2022.rs:165-198 — calculate_transfer_fee() (exists but not called in verification)
• crates/lib/src/fee/fee.rs:174-204 — analyze_payment_instructions() (correctly accounts for transfer fee in estimation)
• SPL Token-2022 specification: transfer fees are deducted from the transfer amount by the on-chain program

Summary

When inner CPI instructions use instruction types not recognized by Kora's parser (including Token-2022 extension instructions like ConfidentialTransfer, TransferFeeExtension::WithdrawWithheldTokens, etc.), they are reconstructed as stub instructions with empty accounts and empty data. These stubs fail deserialization during fee payer policy validation and are silently skipped, meaning any fee payer usage within those instructions goes completely unchecked.

Severity

Medium

Affected Component

• File: crates/lib/src/transaction/instruction_util.rs
• Functions: reconstruct_system_instruction(), reconstruct_spl_token_instruction()
• Lines: 750–753, 1187–1189

Root Cause

The instruction reconstruction functions have a catch-all _ => arm for unrecognized instruction types that creates a stub CompiledInstruction with the correct program_id_index but empty accounts and empty data. When this stub reaches the fee payer policy parsing (parse_system_instructions / parse_token_instructions), deserialization of empty data fails. The parsing functions also have a catch-all _ => {} that silently skips the failed instruction. The result: the instruction exists in all_instructions (so program allowlist checks pass), but fee payer policy is never enforced on it.

Vulnerable Code

Stub Creation

// crates/lib/src/transaction/instruction_util.rs:750-753
// System program — unrecognized instruction type:
_ => {
    log::error!("Unsupported system instruction type: {}", instruction_type);
    Ok(Self::build_default_compiled_instruction(program_id_index))
}

// crates/lib/src/transaction/instruction_util.rs:1187-1189
// SPL Token program — unrecognized instruction type:
_ => {
    log::error!("Unsupported token instruction type: {}", instruction_type);
    Ok(Self::build_default_compiled_instruction(program_id_index))
}

The stub builder:

pub fn build_default_compiled_instruction(program_id_index: u8) -> CompiledInstruction {
    CompiledInstruction {
        program_id_index,
        accounts: vec![],  // <-- No accounts
        data: vec![],       // <-- No data
    }
}

Silent Skip During Policy Parsing

// In parse_system_instructions:
if let Ok(system_instruction) = bincode::deserialize::<SystemInstruction>(&instruction.data) {
    match system_instruction {
        // ... known types handled ...
        _ => {}  // <-- Unrecognized: silently skipped
    }
}
// If deserialize fails (empty data), the entire `if let Ok` block is skipped.
// The instruction is not added to any policy check map.

// In parse_token_instructions:
if let Ok(token_instruction) = TokenInstruction::unpack(&instruction.data) {
    match token_instruction {
        // ... known types handled ...
        _ => {}  // <-- Unrecognized: silently skipped
    }
}
// Same: empty data causes unpack to fail, instruction completely invisible to policy.

Proof of Concept

Affected Token-2022 Extension Instructions

The following Token-2022 extension instruction types are NOT handled by Kora's parser and would produce empty stubs:

| Extension | Instruction | Risk if Fee Payer is Authority | |-----------|------------|-------------------------------| | TransferFeeExtension | WithdrawWithheldTokensFromMint | Fee payer as withdraw authority can drain withheld fees | | TransferFeeExtension | WithdrawWithheldTokensFromAccounts | Same | | TransferFeeExtension | HarvestWithheldTokensToMint | Fee collection manipulation | | ConfidentialTransfer | Transfer | Hidden transfer amounts bypass fee tracking | | ConfidentialTransfer | Withdraw | Hidden withdrawals | | InterestBearingMint | UpdateRate | Fee payer as rate authority can manipulate interest | | TransferHook | Execute | Arbitrary hook execution | | GroupMemberPointer | Update | Metadata manipulation | | MetadataPointer | Update | Metadata manipulation | | PermanentDelegate | Transfer (via delegate) | Delegate-based unauthorized transfers |

Code Path Trace

1. Transaction contains an inner CPI instruction:
   Program: Token-2022
   Type: "withdrawWithheldTokensFromMint" (TransferFeeExtension)
   Accounts: [fee_payer (as withdraw_withheld_authority), mint, destination]

2. RPC returns this as a Parsed inner instruction

3. reconstruct_spl_token_instruction() is called:
   - instruction_type = "withdrawWithheldTokensFromMint"
   - No match in the known types (transfer, transferChecked, burn, etc.)
   - Falls through to _ => arm
   - Returns: CompiledInstruction { program_id_index, accounts: [], data: [] }

4. Stub is added to all_instructions
   → validate_programs() sees Token-2022 program ID → PASS (allowed)
   → validate_disallowed_accounts() sees no accounts in the stub → PASS

5. parse_token_instructions() processes the stub:
   - TokenInstruction::unpack(&[]) → Err (empty data)
   - if let Ok(...) block skipped entirely
   - Instruction not added to any ParsedSPLInstructionType map

6. validate_fee_payer_usage() iterates parsed SPL instructions:
   - No entry for "withdrawWithheldTokensFromMint"
   - Fee payer's usage as withdraw_withheld_authority is NEVER checked

7. Transaction is signed by Kora

8. On-chain: fee_payer (as withdraw authority) withdraws withheld
   transfer fees from the mint to attacker's account

Verifiable Test

#[test]
fn test_unrecognized_instruction_produces_empty_stub() {
    // Simulate what happens for an unrecognized Token-2022 instruction
    let program_id_index: u8 = 3; // Token-2022 at index 3

    // This is what the catch-all arm produces:
    let stub = IxUtils::build_default_compiled_instruction(program_id_index);

    assert_eq!(stub.accounts.len(), 0);  // No accounts
    assert_eq!(stub.data.len(), 0);      // No data

    // Attempt to parse it:
    let result = TokenInstruction::unpack(&stub.data);
    assert!(result.is_err());  // Cannot parse empty data

    // Therefore: fee payer policy is never applied to this instruction
    // The fee payer could be the withdraw_withheld_authority in the
    // REAL instruction, but the stub has zero accounts — invisible.
}

Impact

• Fee Payer Policy Bypass: Token-2022 extension instructions that use the fee payer as an authority are invisible to policy enforcement.
• Forward-Looking Risk: As Solana and SPL Token-2022 add new instruction types, they will automatically bypass all fee payer policy checks in Kora.
• Precondition: Requires the fee payer to hold some authority role (e.g., withdraw_withheld_authority, permanent_delegate) for Token-2022 accounts. This is unlikely in typical deployments but possible in misconfigured setups.

Recommendation

Reject transactions containing inner instructions with unrecognized types (fail-secure):

// In reconstruct_system_instruction:
_ => {
    return Err(KoraError::InvalidTransaction(format!(
        "Unrecognized system instruction type '{}' in CPI — \
         cannot validate fee payer policy. Transaction rejected.",
        instruction_type
    )));
}

// In reconstruct_spl_token_instruction:
_ => {
    return Err(KoraError::InvalidTransaction(format!(
        "Unrecognized SPL Token instruction type '{}' in CPI — \
         cannot validate fee payer policy. Transaction rejected.",
        instruction_type
    )));
}

Alternatively, maintain a list of known-safe instruction types that don't involve authority checks, and only reject truly unknown types.

References

• crates/lib/src/transaction/instruction_util.rs:750-753 — system instruction catch-all
• crates/lib/src/transaction/instruction_util.rs:1187-1189 — SPL token instruction catch-all
• crates/lib/src/transaction/instruction_util.rs:316-319 — build_default_compiled_instruction
• SPL Token-2022 instruction types — full list of extension instructions