QuantAMM
QuantAMM
49,600 OP
View results
Previous Next
Submission Details
Severity: low
Valid

MultiHopOracle - Precision Loss Due to Consecutive Integer Division When `oracleConfig.invert` is True

bladesec

Title

MultiHopOracle - Precision Loss Due to Consecutive Integer Division When oracleConfig.invert is True

Summary

The _getData function in the MultiHopOracle contract suffers from a critical precision loss issue when oracleConfig.invert is set to true. The repeated integer division significantly reduces precision, especially in cases involving small values or multiple hops with inversions, leading to inaccurate oracle data and unreliable price feeds.

Vulnerability Details

Here's the implementation of _getData function of MultihHopOracle contract:

function _getData() internal view override returns (int216 data, uint40 timestamp) {
HopConfig memory firstOracle = oracles[0];
(data, timestamp) = firstOracle.oracle.getData();
if (firstOracle.invert) {
data = 10 ** 36 / data; // 10^36 (i.e., 1 with 18 decimals * 10^18) to get the inverse with 18 decimals.
// 10**36 is automatically precomputed by the compiler, no explicit caching needed
}
uint256 oracleLength = oracles.length;
​
for (uint i = 1; i < oracleLength; ) {
HopConfig memory oracleConfig = oracles[i];
(int216 oracleRes, uint40 oracleTimestamp) = oracleConfig.oracle.getData();
if (oracleTimestamp < timestamp) {
timestamp = oracleTimestamp; // Return minimum timestamp
}
​
// depends which way the oracle conversion is happening
if (oracleConfig.invert) {
>> data = (data * 10 ** 18) / oracleRes;
} else {
data = (data * oracleRes) / 10 ** 18;
}
unchecked {
++i;
}
}
}

As seen above, The _getData function has the issue consecutive integer division operations involving oracleRes, where fractions are truncated, leading to errors. Due to repeated inversions compound this precision loss, it would make the final calculation highly inaccurate, especially for small token values or low-liquidity assets.

Key Issues:

  • Inversion Logic: Division by small values leads to truncation and loss of meaningful data.
    Chained Operations: Multi-hop paths amplify the precision loss through repeated inversions.

  • Unreliable Price Feeds: Results in inaccurate pricing for micro-tokens or inverted pairs, impacting downstream protocols.

This flaw renders the oracle unreliable for small-value tokens and multi-hop scenarios, introducing risks like incorrect pricing or economic losses across the ecosystem.

Impact

This flaw causes incorrect price calculations, especially for small tokens or multi-hop paths, where repeated operations lose precision. It can lead to unreliable price feeds, opening the door to potential financial losses, mispricing, and exploitation risks like arbitrage opportunities.

Tools Used

Manual Review

Recommendations

Consider Utilizing a 3rd party like FixedPoint and restructure calculations to perform division only at the final step of multiplication. Preferably, consider doing the division as the last step.

Updates

Lead Judging Commences

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

finding_MultiHopOracle_getData_invert_precision_loss_low_decimals

Likelihood: Informational/Very Low, admin should use a price feed with 18 decimals and this feed should compare a assets with a very small value and an asset with a biggest amount to have the smallest price possible. Admin wouldn't do that intentionally, but one token could collapse, and with multiple hop, it increases a bit the probability. Impact: High, complete loss of precision. Probability near 0 but not 0: deserve a Low

Support

FAQs

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