# eMode implementation is completely broken

AaveLeverageStrategyExtension reads base pool LTV via getReserveConfigurationData instead of eMode-adjusted values, so eMode's higher LTV is never usable.

- Payout: Contest reward
- Severity: high
- Program: Index
- Credited: 0x52
- Disclosed: 2023-05-11
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-05-Index-judging/issues/251
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-05-Index%3AH-1
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:misconfiguration

**Target:** AaveLeverageStrategyExtension.sol (Aave V3 leverage adapter)
**Root cause:** _calculateMaxBorrowCollateral calls AaveProtocolDataProvider.getReserveConfigurationData, which returns base reserve LTV/liquidation threshold and never the eMode-category-adjusted values, so the strategy computes borrow limits from the wrong parameters.
**Steps:**
1. Read `_calculateMaxBorrowCollateral` in AaveLeverageStrategyExtension.sol#L1095-L1109.
2. Observe it calls `strategy.aaveProtocolDataProvider.getReserveConfigurationData(collateralAsset)` for maxLtvRaw and liquidationThresholdRaw.
3. Check AaveProtocolDataProvider.getReserveConfigurationData: it reads `IPool.getConfiguration(asset)` base params only, ignoring eMode category.
4. Enable eMode on the SetToken and attempt leverage; computed netBorrowLimit still uses base LTV, so the higher eMode LTV is never reached.
5. Note downstream modules assume the higher LTV, producing misconfiguration/erratic behavior.
**How found:** Code review of the leverage adapter's borrow-limit math against Aave V3's data provider, noticing the wrong getter is used for eMode-aware parameters.
**Insight:** When integrating Aave V3 eMode, base reserve config getters silently return non-eMode LTV/liquidation threshold; verify which getter reflects the user's eMode category before trusting computed borrow limits.