# A single external protocol can DOS rebalancing process

A single external money market revert (pause, upgrade failure, interface change) reverts the whole Notional rebalance loop, blocking fund reallocation.

- Payout: Contest reward
- Severity: medium
- Program: Notional
- Credited: 0xGoodess
- Disclosed: 2023-03-09
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-03-notional-judging/issues/175
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-03-notional%3AM-7
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:chained technique:source-review vuln:business-logic vuln:dos

**Target:** ProportionalRebalancingStrategy / TreasuryAction rebalance loop
**Root cause:** Rebalance loops over all holdings and executes low-level calls to each external money market without catching reverts, so any single failing market reverts the entire transaction.
**Steps:**
1. Rebalance calls `ProportionalRebalancingStrategy.calculateRebalance` building redeem/deposit calldata for every holding.
2. `TreasuryAction._executeDeposits` and `TokenHandler.executeMoneyMarketRedemptions` loop over targets calling `GenericToken.executeLowLevelCall` per market.
3. Make one integrated market (e.g. Aave/Compound/Morpho) revert: pause it, upgrade-break it, or change its interface.
4. The low-level call reverts, reverting the whole rebalance; Notional cannot move funds out of the failing market.
**How found:** Code review of the rebalance loop: noticed per-market low-level calls are not wrapped in try/catch, so a single external revert propagates to the whole rebalance.
**Escalation:** If the failing market is compromised or vulnerable, inability to rebalance traps funds there, risking protocol fund drain.
**Insight:** In multi-target batch loops (rebalance, harvest, claim), an unguarded per-target external call makes every integrated protocol a liveness dependency; check whether one revert bricks the whole batch.
