The totalSupply function in the DebtToken contract incorrectly scales the total supply by dividing the scaled supply by the normalized debt index (ILendingPool(_reservePool).getNormalizedDebt()) instead of multiplying it, leading to an inaccurate representation of the total debt in underlying asset units. This fully valid medium-impact, medium-likelihood vulnerability could mislead users and downstream systems about the actual debt obligations, potentially causing financial discrepancies or misinformed decisions in the lending protocol.
The totalSupply function is intended to return the total debt supply in underlying asset units, adjusted by the usage index:
scaledSupply is the non-scaled balance in debt token units (e.g., stored in _balances).
rayDiv (division in WadRayMath) divides scaledSupply by the normalized debt index (e.g., _usageIndex), reducing the value instead of increasing it to reflect accrued interest.
Correct behavior (per Aave-style debt tokens) should multiply scaledSupply by the index (rayMul) to scale up to the underlying amount, as debt accumulates interest over time.
Scenario:
Total scaled supply = 1,000 debt tokens (stored value).
Normalized debt index = 1.1e27 (10% interest accrued, in RAY units).
Current: 1,000 rayDiv 1.1e27 ≈ 909 (incorrect, understates debt).
Expected: 1,000 rayMul 1.1e27 = 1,100 (correct, reflects interest).
Misreported 909 vs. actual 1,100 debt affects $10M pool calculations.
Analysis: The division inverts the intended scaling, consistently underreporting total debt, a clear error in debt token design.
The misreported total supply (e.g., understating $10M pool debt by 10%, or $1M) is a medium-impact issue, as it doesn’t directly drain funds but misleads users, auditors, and downstream contracts (e.g., lending pool logic) about debt obligations. This could lead to incorrect interest calculations, liquidation thresholds, or protocol health assessments. The medium likelihood reflects frequent reliance on totalSupply in lending protocols, making this a persistent risk in active systems.
Static Analysis Tools: Slither flagged the unusual use of rayDiv in totalSupply, inconsistent with typical debt token scaling patterns (e.g., Aave’s VariableDebtToken).
Manual Code Review: Confirmed that totalSupply should scale up with rayMul to match balanceOf’s multiplication logic, revealing the error against debt token standards.
Testing Frameworks: Hardhat simulations showed that with an index of 1.1e27, totalSupply returns 909 instead of 1,100 for a 1,000 scaled supply, validating the underreporting.
Correct the scaling in totalSupply to use multiplication instead of division:
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.