Obedient Lava Monkey
Medium
Summary The inclusion of reserve.accruedToTreasury in the supply cap validation may cause minor inaccuracies in the enforcement of supply caps for reserves, as the treasury balance might not always reflect the most recent accrued interest. However, these inaccuracies are typically minimal and temporary.
Root Cause
In ValidationLogic.validateSupply
, the supply cap is validated using:
((IAToken(reserveCache.aTokenAddress).scaledTotalSupply() +
uint256(reserve.accruedToTreasury)).rayMul(reserveCache.nextLiquidityIndex) + amount) <=
supplyCap * (10 ** reserveCache.reserveConfiguration.getDecimals()),
Errors.SUPPLY_CAP_EXCEEDED
The potential imprecision arises because reserve.accruedToTreasury
is updated during specific protocol events and might temporarily lag behind the actual accrued amount. However, this lag is typically brief and the difference is usually minimal relative to the total supply.
Internal Pre-conditions
- The reserve supply must be very close to the
supplyCap
. - The
reserve.accruedToTreasury
value must not reflect the most recent interest accrual. - The difference between actual and recorded treasury accrual must be meaningful relative to total supply (unlikely in practice).
External Pre-conditions
- A user attempts to supply funds when the supply is extremely close to the cap.
- The timing of the supply must coincide with the brief window before treasury accrual updates.
Attack Path
- A user monitors the reserve's
accruedToTreasury
state - User identifies a moment when
accruedToTreasury
hasn't updated recently - User supplies funds during this brief window Note: This path is difficult to execute reliably and would likely result in minimal gain (hence medium severity)
Impact The protocol may experience very minor, temporary deviations from intended supply caps.
Mitigation Options
Consider excluding accruedToTreasury
from the supply cap calculation if exact cap enforcement is critical.