# Boost modifications apply retroactively to reward shares, allowing boosting of past times- pans

Aquarius reward checkpointing used current boosted veICE balance for past timestamps, letting users retroactively boost past LP rewards and inflating claims.

- Payout: Contest reward
- Severity: high
- Program: Aquarius
- Credited: Catowice
- Disclosed: 2025-09-01
- Write-up quality: 7/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_aquarius_aug2025.pdf#3.1.1
- Library page: https://bugbountylibrary.com/r/cantina%3Aaquarius_aug2025%3A3.1.1
- Tags: domain:web3 impact:funds-loss kind:contest platform:cantina sev:high tech:solidity technique:source-review vuln:accounting-error vuln:reward-distribution

**Target:** Soroban liquidity pool rewards manager (claim/checkpoint)
**Root cause:** update_working_balance() returns the newly computed effective balance and uses it in update_user_reward() for the elapsed block range, instead of the previous working balance, so boost changes apply retroactively to past timestamps.
**Steps:**
1. Deposit equal LP for user0 and user1 in liquidity_pool.
2. Advance time 30s (`jump(&env, 30)`).
3. Mint boost tokens to user1 and set total_supply via reward_boost_feed (lines A-B).
4. Call `liq_pool.claim(&users[0])` and `liq_pool.claim(&users[1])`.
5. Observe assertion fails: user1 gets 3937500000 vs user0 1575000000, proving retroactive boost.
6. Run: `cargo test --package soroban-liquidity-pool-contract --lib -- test::test_user2_reward_boost --exact --show-output`
**How found:** Code reading of claim_reward -> checkpoint_user -> update_working_balance; noticed the function returns current working_balance and that update_user_reward applies it across last_block..current block, contradicting decaying veICE semantics.
**Exploitation:** LP, wait, then acquire/lock veICE boost before claiming; checkpoint_user computes rewards over the whole elapsed period using the new boosted balance, so the attacker collects boosted rewards for time they were unboosted.
**Insight:** In ve-model reward accounting, check whether checkpoint functions apply the freshly computed effective balance to the elapsed interval rather than the stored previous balance; a decaying boost token makes this retroactivity exploitable by claiming right after boosting.