# A malicious user can avoid unfavorable score updates after alpha/multiplier changes, resulting in accrual of outsized rewards for the attacker at the expense of other users

Attacker mints and burns Prime tokens to decrement pendingScoreUpdates, freezing their inflated score after alpha/multiplier changes and accruing outsized rewards at others' expense.

- Payout: Contest reward
- Severity: high
- Program: Venus Protocol
- Credited: 0xDetermination
- Disclosed: 2023-11-29
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2023-09-venus-findings/issues/555
- Library page: https://bugbountylibrary.com/r/c4%3A2023-09-venus%3AH-02
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:chained technique:source-review vuln:accounting-error vuln:business-logic vuln:reward-distribution

**Target:** Prime.sol reward score accounting (updateScores/pendingScoreUpdates)
**Root cause:** _mint does not increment pendingScoreUpdates while _burn decrements it, so minting then burning a token after an alpha/multiplier update wrongly decrements the counter, letting the attacker exhaust it before their own score is updated.
**Steps:**
1. Attacker stakes minimum XVS 90 days in advance on multiple addresses.
2. Protocol calls updateAlpha()/updateMultipliers(), setting pendingScoreUpdates to N.
3. Attacker backruns: claim() then withdraw XVS below minimum to burn, decrementing pendingScoreUpdates (isScoreUpdated default false).
4. Repeat with more addresses to decrement further.
5. Attacker calls updateScores() on other users until pendingScoreUpdates hits 0.
6. Further updateScores() reverts NoScoreUpdatesRequired(), leaving attacker's inflated score frozen.
**How found:** Code reading of claim()/_mint() vs _burn()/_updateRoundAfterTokenBurned(): noticed _mint never touches pendingScoreUpdates while _burn decrements it, and isScoreUpdated defaults false for freshly minted tokens.
**Exploitation:** Attacker freezes a higher-than-appropriate score after a score-decreasing alpha/multiplier change; rewards are score/totalScore so inflated score accrues more rewards. claimInterest() does not update scores, so rewards can be claimed anytime. Attacker can also freeze other users' scores that would have increased.
**Escalation:** Frontrun updateMultipliers() with staking/lending to inflate score before freezing; combine with irrevocable-token bypass to reduce required stake by 1000 XVS; mint/burn multiple tokens to decrement by more than one.
**Insight:** When a counter gates a batch-update loop, audit every path that mutates it asymmetrically: mint vs burn, add vs remove. A freshly created entity with default-false 'updated' flag can be burned to silently consume a slot meant for a real pending update.