Solana Agg Settlement Program - 0x Project

The swap_amount_in instruction executes a sequence of actions, each represented as an encoded Cross-Program Invocation (CPI), invoking their respective programs. Each action includes specific parameters encoded within the instruction data, such as amount_in_bps, which helps determine the token amounts involved, along with other execution parameters required for the CPI call.

To efficiently track spendable balances, the program maintains a TokenBalanceCache, which stores token balances (including lamports) available for the program’s use, indexed by each account’s public key. This cached balance is assumed to be nonzero before instruction execution.

The internal balance ledger (intra_program_balances) functions as follows:

• Debits balances when tokens are spent.

• Credits balances when tokens are received.

• Updates occur at the end of each action, after the corresponding CPI execution.

The first entry in intra_program_balances corresponds to the sell account, setting its balance to the provided amount_in value, which represents the spendable amount available for the actions. However, the program does not validate whether amount_in is lower than the actual balance of the sell account.

If amount_in is insufficient relative to the actual balance of the sell account, the instruction will ultimately fail, as at least one action will be unable to execute due to an insufficient token balance. The exact failure point will depend on the amount_in_bps values assigned to each action.

processor/swap_amount_in.rs

 let initial_buy_token_balance = get_token_balance(&accounts[RECEIVING_ACCOUNT_INDEX])?;
    let initial_sell_token_balance = get_token_balance(&accounts[SELL_ACCOUNT_INDEX])?;
    // Start offset at 2 as the first 2 accounts are reserved for the "sell account" and the
    // "receiving account". These accounts must be prepended to the account list as we cannot
    // know where they are in the set of actions (or at the very least it would require overly
    // complex heuristics).
    let mut account_offset: usize = 2;

    // We maintain an internal ledger of token balances (including lamports) available to
    // spend by the program. This internal ledger is debited whenever a token is spent and
    // credited as tokens are received. This credit/debit usually happens at the end of each
    // action after the CPI has been processed.
    let mut intra_program_balances = TokenBalanceCache::new();
    intra_program_balances.insert(*accounts[SELL_ACCOUNT_INDEX].key(), amount_in);

To prevent unexpected failures during execution, it is recommended to validate that amount_in is not lower than the actual balance of the sell account before executing any actions. This ensures that the instruction will not fail mid-execution due to insufficient funds, improving reliability and predictability.

SOLVED: The ZeroEx team solved this issue by adding a check to ensure the requested amount in does not exceed the sell account balance.

The swap_amount_in instruction and the calculate_token_out_for_sol_in() function utilize expect() immediately after performing checked arithmetic operations. While checked arithmetic functions such as checked_sub are designed to prevent overflows by returning an Option<T>, appending expect() directly forces an immediate panic in case of an overflow, rather than handling the error in a controlled manner.

Using expect() in this context can introduce unnecessary risks and reduce the robustness of the program:

• Unexpected Transaction Failures

  • If an overflow occurs, expect() will cause the program to panic, leading to an abrupt termination of the instruction.

  • This prevents graceful error handling and may result in unintended transaction failures.

• Limited Debugging and Error Transparency

  • A panic triggered by expect() does not provide structured error handling, making it more difficult to diagnose issues.

  • Without meaningful error messages, understanding the cause of a failure may require additional debugging efforts.

processor/swap_amount_in.rs

        let final_sell_token_balance = get_token_balance(&accounts[SELL_ACCOUNT_INDEX])?;
    let final_sell_token_diff = initial_sell_token_balance
        .checked_sub(final_sell_token_balance)
        .expect("overflow");
    if final_sell_token_diff > amount_in {
        return Err(SolSettlerError::MaxAmountInExceeded.into());
    }

    // Assert the amount of tokens received is greater than the minimum expected.
    let final_buy_token_balance = get_token_balance(&accounts[RECEIVING_ACCOUNT_INDEX])?;
    let buy_token_balance_diff = final_buy_token_balance
        .checked_sub(initial_buy_token_balance)
        .expect("overflow");

dexes/pumpfun/accounts.rs

     pub fn calculate_token_out_for_sol_in(&self, amount_in_u128: u128) -> u64 {
        let denominator = u128::from(*self.virtual_sol_reserves())
            .checked_add(amount_in_u128)
            .expect("overflow");
        let ret = u128::from(*self.virtual_token_reserves())
            .checked_mul(amount_in_u128)
            .expect("overflow")
            .checked_div(denominator)
            .expect("overflow");
        u64::try_from(ret).expect("overflow")
    }

To address this issue, it is recommended to replace expect() with structured error-handling mechanisms that provide meaningful feedback and prevent abrupt failures.

SOLVED: The ZeroEx team solved this issue by replacing expect() with a structured error-handling mechanism as recommended.