# Updating rate limit for addresses restores their entire buffer amount

Updating an address's rate limit in MultiRateLimited resets bufferStored to full bufferCap, letting the address spend its entire buffer twice via frontrunning.

- Payout: Audit contest
- Severity: medium
- Program: Volt Protocol
- Credited: cmichel
- Disclosed: 2022-06-29
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-03-volt-findings/issues/27
- Library page: https://bugbountylibrary.com/r/c4%3A2022-03-volt%3AM-05
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:business-logic vuln:race-condition

**Target:** MultiRateLimited.sol rate limiter contract
**Root cause:** In _updateAddress, bufferStored is set to the new _bufferCap instead of being capped by the existing individualBuffer, discarding consumed buffer.
**Steps:**
1. Address consumes its entire buffer via rate-limited spend.
2. Admin calls updateAddress to change bufferCap/rateLimitPerSecond.
3. bufferStored is reset to full _bufferCap, replenishing the buffer.
4. Address spends the entire buffer a second time.
**How found:** Code review of _updateAddress noticed bufferStored assigned directly to _bufferCap rather than preserving consumed amount.
**Exploitation:** Frontrun the updateAddress transaction: spend the full buffer, then after the update the buffer is replenished to full cap, allowing a second full spend.
**Insight:** When auditing rate limiters, check whether config updates reset accumulated state (bufferStored) rather than preserving it capped by the new limit; frontrunning config changes can double-spend the buffer.