Open code423n4 opened 2 years ago
Keeping track of the observations as a sum and then dividing is a good suggestion. The price values have 18 decimals and the max discrepancy introduced is very small (10**-15) with expected parameter ranges. The potential risk to the protocol seems low though.
Please notice that discrepancy here is unbounded, i.e. the logic itself do not have any max discrepancy, the divergence between fact and recorded value can pile up over time without a limit.
If you do imply that markets should behave in some way that minuses be matched with pluses, then I must say that they really shouldn't.
Debating between QA and Med on this one. I am going to award it as medium because there is a potential to leak some value do this imprecision compounding over time.
Lines of code
https://github.com/code-423n4/2022-08-olympus/blob/2a0b515012b4a40076f6eac487f7816aafb8724a/src/modules/PRICE.sol#L134-L139
Vulnerability details
Now the precision is lost in moving average calculations as the difference is calculated separately and added each time, while it typically can be small enough to lose precision in the division involved.
For example,
10000
moves of990
size,numObservations = 1000
. This will yield0
on each update, while must yield9900
increase in the moving average.Proof of Concept
Moving average is calculated with the addition of the difference:
https://github.com/code-423n4/2022-08-olympus/blob/2a0b515012b4a40076f6eac487f7816aafb8724a/src/modules/PRICE.sol#L134-L139
/ numObs
can lose precision ascurrentPrice - earliestPrice
is usually small.It is returned on request as is:
https://github.com/code-423n4/2022-08-olympus/blob/2a0b515012b4a40076f6eac487f7816aafb8724a/src/modules/PRICE.sol#L189-L193
Recommended Mitigation Steps
Consider storing the cumulative
sum
, while returningsum / numObs
on request:https://github.com/code-423n4/2022-08-olympus/blob/2a0b515012b4a40076f6eac487f7816aafb8724a/src/modules/PRICE.sol#L189-L193