Core Contracts

Regnum Aurum Acquisition Corp
HardhatReal World AssetsNFT
77,280 USDC
View results
Submission Details
Severity: medium
Valid

Incorrect Total Supply Scaling in totalSupply Function

Summary

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.

Vulnerability Details

The totalSupply function is intended to return the total debt supply in underlying asset units, adjusted by the usage index:

Issue:

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.

Impact

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.

Tools Used

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.

Recommendations

Correct the scaling in totalSupply to use multiplication instead of division:

function totalSupply() public view override(ERC20, IERC20) returns (uint256) {
uint256 scaledSupply = super.totalSupply();
return scaledSupply.rayMul(ILendingPool(_reservePool).getNormalizedDebt());
}
Updates

Lead Judging Commences

inallhonesty Lead Judge 7 months ago
Submission Judgement Published
Validated
Assigned finding tags:

DebtToken::totalSupply incorrectly uses rayDiv instead of rayMul, severely under-reporting total debt and causing lending protocol accounting errors

inallhonesty Lead Judge 7 months ago
Submission Judgement Published
Validated
Assigned finding tags:

DebtToken::totalSupply incorrectly uses rayDiv instead of rayMul, severely under-reporting total debt and causing lending protocol accounting errors

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!