# BkdLocker#depositFees() can be front run to steal the newly added rewardToken

BkdLocker.depositFees() credits rewards instantly, so an attacker can front-run the deposit with a large lock, then claim a share of the new fees.

- Payout: Contest reward
- Severity: medium
- Program: Backd
- Credited: WatchPug
- Disclosed: 2022-07-19
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-05-backd-findings/issues/95
- Library page: https://bugbountylibrary.com/r/c4%3A2022-05-backd%3AM-05
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:race-window technique:source-review vuln:business-logic vuln:reward-distribution

**Target:** BkdLocker staking/reward contract (Solidity)
**Root cause:** depositFees() adds to feeIntegral immediately with no vesting, so rewards are distributed pro-rata to current totalLockedBoosted at the instant of deposit rather than over time.
**Steps:**
1. Observe pending depositFees(1000) with totalLockedBoosted=100,000.
2. Front-run with `lock(100,000 govToken)` to take 50% of shares.
3. After depositFees mines, call `claimFees()` to receive ~500 rewardToken.
4. Withdraw after _WITHDRAW_DELAY (short/0 makes it practical).
**How found:** Code reading of depositFees() showing feeIntegral updated instantly against current totalLockedBoosted, recognizing the classic front-run/just-in-time staking reward-sniping pattern.
**Exploitation:** Attacker sandwiches the depositFees transaction: locks a large amount just before the fee surge, claims the proportional share of newly added rewardToken, then exits after the withdrawal delay, diluting existing lockers' rewards.
**Escalation:** If token is liquid, attacker can short to hedge lock risk, making withdrawal delay ineffective and delta-neutral profit.
**Insight:** Any reward accrual that updates an integral at deposit time without time-weighting is sandwichable; check whether withdrawal delay actually bounds the attack or can be configured to 0.