Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

feat: introduce max change per trade #228

Merged
merged 14 commits into from
Nov 18, 2024
Merged

feat: introduce max change per trade #228

merged 14 commits into from
Nov 18, 2024

Conversation

xenide
Copy link
Contributor

@xenide xenide commented Mar 16, 2024 •
edited
Loading

Motivation

Solution

with the implementation of this extra check (max change per trade), there are 4 possible scenarios:

  1. raw price doesn't violate both conditions
  • simple: clampedPrice = rawPrice
  1. raw price only violates rate of change, doesn't violate max change per trade
  • use the rate-of-change capped price
  • is it possible that the max-change-per-trade capped price is a smaller change than rate-of-change-capped price?
    • e.g. maxChangePerTrade is 2%, rate of change is 3bp/s.
      • trade comes after 30 seconds, doing a 1% change in price.
      • max-change-per-trade capped price is 102%, rate-of-change capped price is 100.9%
    • e.g. maxChangePerTrade is 2%, rate of change is 100bp/s.
      • trade comes after 3 seconds, doing a 1% change in price
      • max-change-per-trade capped price is 102%, rate-of-change capped price is 103%
    • seems that it's not possible
  1. raw price only violates max change per trade, doesn't violate rate of change
  • use the max-change-per-trade capped price
  1. raw violates both rate of change and max change per trade
  • should we take the rate-of-change capped or max-change-per-trade capped?
  • should choose the closer one? Arithmetic / geometric mean of the two?
    • Arithmetic mean would be cheaper than geometric mean due to gas cost
  • Propose to choose the closer one (smaller change)

@codecov Codecov
Copy link

codecov bot commented Mar 16, 2024 •
edited
Loading

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.21%. Comparing base (5a606bc) to head (5a606bc).

❗ Current head 5a606bc differs from pull request most recent head 18bd916. Consider uploading reports for the commit 18bd916 to get more accurate results

Additional details and impacted files 
@@                Coverage Diff                 @@
##           fix/oracle-struct     #228   +/-   ##
==================================================
  Coverage              88.21%   88.21%           
==================================================
  Files                     12       12           
  Lines                    611      611           
==================================================
  Hits                     539      539           
  Misses                    72       72

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

xenide
xenide commented Mar 17, 2024
View reviewed changes
src/ReservoirPair.sol
} else {
assert(aPrevClampedPrice > aCurrRawPrice);
rClampedPrice = aPrevClampedPrice.fullMulDiv(1e18 - maxChangeRate * aTimeElapsed, 1e18);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the auditors missed this. This underflow vuln has got to be a critical, and is live on our production pairs right now

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the vuln, it freezes the pair if it overflows? How realistic is 1e18 seconds elapsed, surely that's like super far away?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's the product of maxChangeRate and aTimeElapsed that's easy to overflow 1e18.

e.g. 86400 (seconds in a day) * 0.00003e18 (0.3bp / s) = 2.592e18 > 1e18

Yes it freezes the pair as it's an arithmetic underflow. I discovered it during regression testing. Kinda weird that it didn't show up before

src/ReservoirPair.sol Outdated Show resolved Hide resolved
@xenide xenide linked an issue Mar 18, 2024 that may be closed by this pull request
Caveats regarding the clamp #226
Open
@xenide xenide marked this pull request as ready for review March 18, 2024 04:27
@xenide xenide merged commit 33218e2 into fix/oracle-struct Nov 18, 2024
3 of 9 checks passed
@xenide xenide deleted the feat/max-clamp-per-trade branch November 18, 2024 00:12
@xenide xenide mentioned this pull request Nov 18, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@OliverNChalk OliverNChalk OliverNChalk left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Caveats regarding the clamp
2 participants
@xenide @OliverNChalk