Submission Details
Severity:
Treasury's _totalValue incorrectly aggregates tokens with different decimals
Description
The Treasury contract directly adds token amounts with different decimals to _totalValue without normalization:
function deposit(address token, uint256 amount) external {
IERC20(token).transferFrom(msg.sender, address(this), amount);
_balances[token] += amount;
_totalValue += amount; // @audit aggregates different decimals
}
function withdraw(address token, uint256 amount, address recipient) external {
_balances[token] -= amount;
_totalValue -= amount; // @audit same issue in withdraw
}
This causes significant precision issues since tokens have different decimal places:
1 USDC (6 decimals) = 1,000,000
1 WETH (18 decimals) = 1,000,000,000,000,000,000
Making _totalValue and getTotalValue() return meaningless aggregates.
Recommendation
Remove _totalValue tracking if not needed, or normalize values to same decimal places before adding:
function deposit(address token, uint256 amount) external {
IERC20 tokenContract = IERC20(token);
uint8 decimals = tokenContract.decimals();
uint256 normalizedAmount = amount * (10 ** (18 - decimals));
_totalValue += normalizedAmount;
}
Updates
Lead Judging Commences
inallhonesty 3 months ago
Submission Judgement Published Assigned finding tags:
Treasury::deposit increments _totalValue regardless of the token, be it malicious, different decimals, FoT etc.
Prize pool breakdown
Total prize
77,280 USDC
nSLOC
3,86420 USDC / LOC
74,000
3,280
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.