# Setting the strategy cap to "0" does not update the total shares held or the withdrawal queue

Setting an operator strategy cap to 0 queues EigenLayer withdrawal but leaves assetRegistry shares and withdrawalQueue stale, letting users double-count withdrawals.

- Payout: Contest reward
- Severity: high
- Program: Rio Network Core Protocol
- Credited: Aymen0909
- Disclosed: 2024-02-14
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2024-02-rio-network-core-protocol-judging/issues/10
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-02-rio-network-core-protocol%3AH-2
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:incomplete-fix technique:source-review vuln:accounting-error vuln:business-logic

**Target:** RioLRTOperatorRegistry / OperatorRegistryV1Admin strategy cap admin
**Root cause:** setOperatorStrategyCap queues an EigenLayer withdrawal for the operator's shares but does not decrement assetRegistry's tracked EigenLayer shares nor update the withdrawalQueue, so the same shares remain counted as available.
**Steps:**
1. Deploy LSR with one operator holding 1000e18 strategy shares (500/500 across two operators).
2. Owner calls `setOperatorStrategyShareCaps(operatorId, [{strategy, cap:0}])`.
3. Observe `OperatorStrategyExitQueued` event: `queueWithdrawalForOperatorExit` calls `delegationManager.queueWithdrawals` for the operator's shares.
4. assetRegistry still reports 1000e18 shares; withdrawalQueue unaware of the queued exit.
5. User calls `coordinator.requestWithdrawal(cbETH, lrtAmount)` for the same share value, which succeeds.
6. At epoch settlement, rebalance double-counts the same shares, so user withdrawals fail.
**How found:** Code review of setOperatorStrategyCap branch for cap>0 -> cap==0: noticed it calls queueOperatorStrategyExit but never updates assetRegistry shares or withdrawalQueue, then wrote a Foundry PoC asserting the exit event and a subsequent successful requestWithdrawal.
**Exploitation:** Admin action (cap set to 0) triggers EigenLayer withdrawal of operator shares while internal accounting stays inflated; users then request withdrawals against phantom shares, causing double-counting and failed withdrawals at rebalance.
**Insight:** When an admin setter triggers an external withdrawal (e.g. EigenLayer queueWithdrawals), check every internal accounting structure that mirrors those shares—assetRegistry totals and withdrawalQueue—for a corresponding decrement; stale mirrors enable double-counting.