# sortVaultsByDelta doesn't work as expected

sortVaultsByDelta initializes max/min delta to 0, so all-positive deltas yield duplicate/out-of-range vault indexes, causing withdrawals from wrong vaults or reverts.

- Payout: Audit contest
- Severity: high
- Program: Gro Protocol
- Found by: gpersoon
- Disclosed: 2021-08-30
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-06-gro-findings/issues/2
- Library page: https://bugbountylibrary.com/r/c4%3A2021-06-gro%3AH-04
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** Exposure.sol sortVaultsByDelta vault ordering function
**Root cause:** maxDelta and minDelta are initialized to 0 instead of int256 min/max, so when all deltas are positive (or all negative) neither branch updates minIndex/maxIndex, leaving both at 0.
**Steps:**
1. Assume deltas delta1>=delta2>=delta3>0; loop never satisfies delta<minDelta(0), so minIndex stays 0 and maxIndex=0.
2. With bigFirst=true: vaultIndexes[0]=0, vaultIndexes[2]=0, vaultIndexes[1]=N_COINS-0-0=3, out of range [0..2].
3. Downstream withdrawal logic uses these indexes, withdrawing from wrong vaults or reverting.
4. Fix: init maxDelta=-2**255, minDelta=2**255 and require maxIndex != minIndex.
**How found:** Code review of the ordering loop noticing sentinel values 0 for max/min delta fail when all deltas share a sign.
**Insight:** When a min/max search uses 0 as sentinel, test inputs where all values are same-sign; deltas around a target are frequently all positive or all negative.