-
Notifications
You must be signed in to change notification settings - Fork 3
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.
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
An easily manipulated tick data is being used when minting the full range liquidity #351
Comments
Picodes marked the issue as duplicate of #537 |
Picodes marked the issue as satisfactory |
Picodes marked the issue as partial-50 |
Giving partial credit because the impact and this part "If the currentSqrtPriceX96 is higher, it means the price of the pool's tokens is higher. Consequently, the amount of liquidity minted will be lower because the same amount of assets (in terms of token0 and token1) will provide less liquidity at a higher price." is unclear. |
Hi @Picodes, thanks for judging, however I believe this report explains the issue sufficiently and would like you to consider reassigning it's full duplicate status, cause without the current primary report, this report does a good job explaining the root cause of the issue, going section to section in both report we can see that: The first part of the report, i.e impact section reads:
The first part of this report also hints how using the spot price is not problematic in other instances, but not when minting the full range liquidity, i.e
Additionally, the impact section in this also grows on this fact:
Now the current primary report, asides the aforementioned impact section, the code snippet is the same as is attached in this report, the recommended mitigation step is also the same as is in this report, the only other statement is one under the POC section, which is also covered in this report, i.e Under POC:
In this report:
Now the confusing section you've hinted is just a generic comment on issues arising from price manipulations, and I believe even without that section this report sufficiently hints where the issue is and how to fix it, considering these arguments, I believe the additional 30% for being selected for report on the primary is already a sufficient addition considering it's short and straight to the point, however I also believe a full duplication should be applied to this report, since tagging this as |
@Bauchibred I still believe that the part I highlighted above - the part that is trying to explain what the issue would be in this report - is unclear, as there is no "higher price" or "lower price" but only a relative price between the 2 tokens, but do agree with you that you have correctly flagged the issue and this seems to be a wording mistake so I'll give back full credit. |
Picodes marked the issue as full credit |
Picodes marked the issue as satisfactory |
Lines of code
https://github.com/code-423n4/2024-04-panoptic/blob/833312ebd600665b577fbd9c03ffa0daf250ed24/contracts/PanopticFactory.sol#L335-L412
Vulnerability details
Proof of Concept
Protocol in multiple instances uses data returned from uniswapV3 pool's
slot0
as can be confirmed using this search command: https://github.com/search?q=repo%3Acode-423n4%2F2024-04-panoptic+slot0+NOT+language%3AMarkdown&type=code, now whereas it's right and logical for this to be used in some instances like say if we are to check the current solvency state or what not, using this in some instances is wrong, see reasoning below.Take a look at https://github.com/code-423n4/2024-04-panoptic/blob/833312ebd600665b577fbd9c03ffa0daf250ed24/contracts/PanopticFactory.sol#L335-L412
This function is used to seed the Uniswap V3 pool with a full-tick-range liquidity deployment using funds from caller, however it uses the
currentSqrtPriceX96
fromslot0
to do this calculation.Now Uniswap.slot0 is the most recent data point and can be manipulated easily via MEV bots and Flashloans with sandwich attacks; which can cause the loss of funds or leak of value to protocol when users are interacting with this function.
If the
currentSqrtPriceX96
is higher, it means the price of the pool's tokens is higher. Consequently, the amount of liquidity minted will be lower because the same amount of assets (in terms of token0 and token1) will provide less liquidity at a higher price.Conversely, if the
currentSqrtPriceX96
is lower, it means the price of the pool's tokens is lower. In this case, the amount of liquidity minted will be higher because the same amount of assets will provide more liquidity at a lower price. This is because liquidity is more valuable when the price of the tokens is lower, as it covers a wider price range.Impact
An easily manipulated tick data could be used when minting the positions since the value of
currentSqrtPriceX96
directly influences the amount of liquidity that can be minted in the_mintFullRange
function.Recommended Mitigation Steps
Reimplement some core functionalities where
slot0
is being implemented like shown in this report, cases where current data needs to be strictly used can have this implementation however if there is a valid case to use atwapTick
then this should be used as it way more harder to manipulate the data returned from this.Assessed type
Context
The text was updated successfully, but these errors were encountered: