# Possible frontrun on deposits on LiquidityPool

LiquidityPool rewards lack time-weighting, letting an attacker sandwich a victim's deposit to claim reward twice.

- Payout: Audit contest
- Severity: medium
- Program: Biconomy
- Found by: Cantor_Dust
- Disclosed: 2022-07-25
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-03-biconomy-findings/issues/180
- Library page: https://bugbountylibrary.com/r/c4%3A2022-03-biconomy%3AM-18
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:race-window vuln:business-logic vuln:reward-distribution

**Target:** LiquidityPool deposit/reward logic (Solidity contract)
**Root cause:** getRewardAmount computes reward from instantaneous available-vs-supplied liquidity with no time-weighting or frontrun protection, so a deposit that shifts pool state earns a reward.
**Steps:**
1. Watch mempool for a victim depositNative/deposit ERC20 tx that will earn a reward.
2. Front-run with higher gas: deposit to push pool to near-equilibrium, collecting reward #1.
3. Victim's deposit executes, pushing pool out of equilibrium.
4. Back-run with a second deposit restoring equilibrium, collecting reward #2.
**How found:** Reading depositNative and getRewardAmount, noticed reward derives from current available vs supplied liquidity with no time-weighted checks and no frontrun protection, implying state can be manipulated around a victim tx.
**Exploitation:** Attacker sandwiches victim deposit with a pre-deposit and post-deposit, each earning a reward because reward depends only on instantaneous pool imbalance, yielding double rewards at victim's expense.
**Insight:** When a reward/incentive is a function of instantaneous pool state, check whether an attacker can sandwich a legitimate state-changing tx to harvest the incentive twice; look for missing time-weighting or TWAP on reward inputs.