The Treasury contract's _totalValue
calculation is fundamentally flawed as it treats all tokens as having equal value and decimal places, leading to incorrect TVL reporting.
The current implementation has several critical issues in how it tracks the total value.
Different ERC20 tokens can have different decimal places. For example:
USDC uses 6 decimals (1 USDC = 1000000)
crvUSD uses 18 decimals (1 crvUSD = 1000000000000000000)
WETH uses 18 decimals (1 WETH = 1000000000000000000)
The current implementation simply adds raw token amounts, example when depositing.
also in withdraws;
The contract assumes all tokens have equal value, which is incorrect.
The contract lacks price feed integration to convert token amounts to a common denomination (like USD), which is necessary for meaningful TVL calculation.
Here am using just WETH and USDC as an example for simplicty, but I understand the protocol uses tokens such as RAACToken, crvUSD, RTokens, DETokens and so on.
Alice deposits 1 WETH (1e18 wei, worth $2000)
_totalValue increases by 1e18
Bob deposits 2000 USDC (2000 * 1e6 wei, worth $2000)
_totalValue increases by 2000 * 1e6
Result: _totalValue = 1e18 + 2e9
Despite both deposits having equal USD value, they contribute vastly different amounts to _totalValue
The final _totalValue is meaningless as it mixes different decimal places and values
Severely inaccurate reporting of total value locked (TVL)
Potential mismanagement of funds due to incorrect value tracking
Unreliable protocol metrics for stakeholders
Manual code review
Implement a price-aware and decimal-aware TVL tracking.
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.