Root + Impact

Description

• In normal behavior, a liquidity provider deposits amount_a of token A, and the program computes the corresponding amount_b of token B needed to maintain the pool ratio. Then both amounts are transferred to the pool vaults, and the appropriate number of LP tokens is minted to the user.

• However, the function calculate_token_b_provision_with_a_given depends on reading accurate vault balances. If the vault accounts are not explicitly reloaded (.reload()), the cached state may not reflect recent external token transfers, causing the amount of token B to be miscalculated.

Risk

Likelihood:

• This will occur when tokens have been transferred into either vault_a or vault_b before the instruction executes, either as part of a batched transaction or as an external manipulation.

• Programs using cached account state without a fresh .reload() are susceptible to using outdated balances, particularly in multi-instruction transactions.

Impact:

• The calculated amount_b could be incorrect, leading to an imbalance in the pool and unfair liquidity provision.

• LP tokens could be minted at an incorrect ratio, diluting other liquidity providers or benefiting manipulators.

Proof of Concept

External actor or same user pre-loads vault_a with extra tokens
send_tokens_to(vault_a, 10_000);

Then provides liquidity based on stale vault_a reserve
provide_liquidity(amount_a = 100_000);

vault_a balance appears lower than reality during calculation, but includes added tokens during transfer
// This creates misalignment between expected and actual pool state

Recommended Mitigation

Always reload token accounts before using them in reserve-sensitive calculations to prevent stale state from impacting logi