Skip to content

Edge cases to validate/test for #29

@kadenzipfel

Description

@kadenzipfel

I've listed below some of the most likely edge cases in the system that we'll want to create systems to prevent and test for:

  • Deltas must always be correct
    • Direction is likely the biggest gotcha here
    • afterSwap
    • modifyLiquidity
    • take/settle
    • tickAccumulator/accumulatorDelta
  • Tick/price direction must always be correct
    • Does higher tick for token0 always imply higher price and vice versa?
    • Consider price denomination in determining whether the direction is correct
      • I think we should include this in _sortTicks
    • Lower slug
    • Upper slug
    • Price discovery slug
  • Rounding is directionally optimal
    • Basically anything that's not wad logic should be considered
      • Even some wad logic too as other invariants/expectations depend on them
      • Requires clarifying which direction that it's safest to round in in any given circumstance
    • Rounding to nearest tickSpacing
    • Rounding tick to the nearest tickSpacing should maybe have some more directional consideration
      • i.e. since the accumulatorDelta could be positive or negative and we have invariants to protect like not allowing the price to go out of range
  • Off by one errors
    • Likely some overlap with above rounding errors
    • Epoch retrieval
    • Computing future epochs
    • Careful with 1-indexed epochs
  • Under/overflow
    • Ticks
      • Maybe makes sense to just bound every tick to the min/max when they're assigned?
        • Ideally we can enforce this when we initialize immutables such that it's mathematically impossible for them to over/underflow?
    • Prices
    • Why do we compute the expected tick including the elapsed gamma in the oversold case?
  • Safe tick bounds
    • Due to rounding we can have tick ranges of 0 which will not work

For testing, we should convert every tick/price/amount to an asset denominated price/amount such that we can be certain that our validation logic is correct

For the contract itself, we should split the logic that determines things like direction into separate functions such that we can test that those functions individually rather than carefully testing each instance where we compute these things

Metadata

Metadata

Assignees

Labels

🧪 testAnything related to testing

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions