# Rewards distribution can be delayed/never distributed on AuraLocker.sol#L848

Attacker sends 1 wei of a reward token to AuraStakingProxy and calls distributeOther, resetting the reward period and diluting rewardRate so emissions are delayed or never fully distributed.

- Payout: Contest reward
- Severity: medium
- Program: Aura Finance
- Credited: 0xjuicer
- Disclosed: 2022-07-26
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-05-aura-findings/issues/1
- Library page: https://bugbountylibrary.com/r/c4%3A2022-05-aura%3AM-06
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** AuraLocker / AuraStakingProxy reward distribution (Solidity)
**Root cause:** _notifyReward recomputes rewardRate as (newReward + leftover)/rewardsDuration whenever any amount is notified, restarting the full 7-day period even for a 1 wei addition, with no minimum threshold like queueNewRewards' 120% check.
**Steps:**
1. Attacker transfers 1 wei of a non-cvxCrv reward token to AuraStakingProxy.
2. Attacker calls `distributeOther()` on AuraStakingProxy, which calls notifyRewardAmount -> _notifyReward on AuraLocker.
3. In _notifyReward: `remaining = periodFinish - block.timestamp; leftover = remaining * rewardRate; rewardRate = (reward + leftover) / rewardsDuration`.
4. With 3.5 days left at rate 1e18/s, leftover=302400e18, new rate = 302400e18/604800 = 0.5e18, halving emissions and extending distribution over a fresh 7 days.
5. Repeat each period to perpetually delay or prevent full distribution.
**How found:** Code reading of _notifyReward's leftover/rate recomputation, noticing the contrast with queueNewRewards' 120% protective threshold that prevents period restarts for small additions.
**Exploitation:** Any holder of a dust amount of the reward token griefs the protocol: send 1 wei to AuraStakingProxy, call distributeOther, forcing rewardRate dilution and period restart. Repeated calls keep stretching the schedule so rewards are delayed indefinitely or never fully distributed.
**Insight:** When a contract recomputes a rate as (newAmount + leftover)/duration on every notify, check whether a permissionless dust deposit can trigger it; compare sibling functions (queueNewRewards) for a threshold that the vulnerable path lacks.