# Lack of rebalance rate limiting allow operators to drain vaults

Arrakis SimpleManager lacked rebalance rate limiting, letting a compromised operator repeatedly rebalance within one tx to extract up to ~26% of vault funds via accepted slippage.

- Payout: Contest reward
- Severity: medium
- Program: Arrakis
- Credited: cergyk
- Disclosed: 2023-06-05
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-06-arrakis-judging/issues/25
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-06-arrakis%3AM-2
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic vuln:oracle-manipulation

**Target:** SimpleManager.rebalance / ArrakisV2 vault
**Root cause:** SimpleManager enforces per-call slippage and price-deviation checks but no cooldown or cumulative-loss limit, so an operator can call rebalance many times in one transaction, each time paying the accepted ~1% slippage.
**Steps:**
1. Operator crafts a rebalance payload routing swaps through a bogus pool/poison token with ~0.01% fee, or an unfavorable pool within maxSlippage.
2. Call `SimpleManager.rebalance` repeatedly in a single transaction; each call loses up to maxSlippage (~1%) of vault funds.
3. Repeat ~30 times per block: cumulative loss ≈ 1-0.99^30 ≈ 26% of vault funds before owner can react.
**How found:** Code review of SimpleManager's safety checks (univ3 price deviation vs chainlink, `_checkMinReturn` slippage) revealed they bound only a single call; noting no rate limit/cooldown on rebalance led to the hypothesis that repeated calls compound the tolerated slippage.
**Exploitation:** A compromised/malicious operator submits a rebalance payload that swaps vault tokens on an attacker-controlled pool at the maximum allowed slippage, then loops rebalance calls within one transaction to compound the accepted loss, extracting a large share of TVL before the owner can replace the operator.
**Escalation:** Batching many rebalance calls in one transaction bypasses the per-call slippage cap's intent, scaling loss from ~1% to ~26% per block.
**Insight:** When a contract bounds loss per call (slippage, deviation) but not per-epoch cumulative loss, check whether the function is repeatable within one tx/block—per-call caps multiply into large drains.