Deep Orange Bison
High
The matchOffersV3 function on DebitaV3Aggregator contract does not account for the decimals returned by the price feed from various oracles. This can lead to incorrect calculations of collateral-to-principal ratios (LTV), fees, and incentives, causing potential discrepancies in the protocol’s lending processes. This oversight introduces risks in how collateral and principal amounts are calculated, potentially impacting both the security and trustworthiness of the protocol.
The root cause is the lack of normalization for price values returned by oracles, which may vary in decimal precision. Without adjusting the decimals, the function uses prices with inconsistent scales directly in calculations, resulting in inaccuracies in collateral and principal amounts.
No response
No response
No response
If decimal discrepancies are ignored, LTV ratios can be miscalculated, affecting the collateral required for loans. This could allow undercollateralized loans, increasing the risk of losses in case of defaults. Misaligned decimals can cause errors in fee and incentive calculations, either overcharging users or reducing protocol revenue. Attackers could exploit these decimal inaccuracies to manipulate LTV calculations, potentially borrowing more than the fair collateral would allow.
When using Oracle price feeds, developers must consider that different feeds can have varying decimal precision. Assuming uniform precision across feeds is a mistake, as not all price feeds follow the same standard. For instance, most non-ETH pairs typically use 8 decimals, while ETH pairs usually use 18 decimals. However, exceptions exist—ETH/USD, considered a non-ETH pair, reports with 8 decimals, while some feeds like AMPL/USD use 18 decimals, contrary to the usual 8-decimal format for USD pairs.
Smart contracts can use DebitaChainlink.getDecimals() to retrieve the exact decimal precision for each price feed, ensuring calculations are accurate across different feed formats.
No response