fix: taking round down into consideration when calculates swap fee #14
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A bug found when adding invariant test which could cause
collect
function revertContext
Considering for the same range, there are multiple LP tokens, let say LP1, LP2, LP3 ...
feesOwed0
,feesOwed1
can be 0 due to the round down calculation butfeeGrowthInside0LastX128
andfeeGrowthInside1LastX128
in v4-core has been updated anyway. (the fee accumulated in step1 has in fact been chopped)feeGrowthInside0LastX128
andfeeGrowthInside1LastX128
in LP1 remains the original value because the position is untouched in the perspective of nfp contract.feeGrowthInside0LastX128
andfeeGrowthInside1LastX128
in v4-core will be constantly updated and the fee accumulated is collected by NFP in the form of vaultToken but the amount has been truncated due the the reason above.(feeGrowthInside0FromV4Core - feeGrowthInsideFromNfp) * liquidity / Q128 > 1
, but the fee accumulated is still less than 1 in fact it's 0 after round down.collect
, the tx will revertHow v3 handles it
Looks back to v3 I notice it's using similar workaround