Open c4-bot-8 opened 10 months ago
0xleastwood marked the issue as primary issue
Good suggestion, receipiant should be added here too: https://github.com/code-423n4/2023-12-particle/blob/main/contracts/libraries/LiquidityPosition.sol#L329
I would argue this is good design and should not be changed to allow for arbitrary recipients. If a token is blacklisted, and a protocol allows the user to circumvent this blacklist, then they may potentially be liable for the behaviour of this individual. Better to take an agnostic approach and leave it as is unless liquidations are ultimately being limited because of this.
0xleastwood marked the issue as selected for report
wukong-particle (sponsor) acknowledged
I agree with the judge. We shouldn't facilitate to temper the blacklist. So only acknowledging the issue.
Lines of code
https://github.com/code-423n4/2023-12-particle/blob/a3af40839b24aa13f5764d4f84933dbfa8bc8134/contracts/protocol/ParticlePositionManager.sol#L135
Vulnerability details
Vulnerability details
LP
has only one way to retrievetoken
, firstdecreaseLiquidity()
, then retrieve through thecollectLiquidity()
method.collectLiquidity()
only has one parameter,tokenId
.So
LP
can only transfer the retrievedtoken
to himself:msg.sender
.This leads to a problem. If
LP
enters the blacklist of a certaintoken
, such as theUSDC
blacklist,Because the recipient cannot be specified (
lps[]
cannot be transferred), this will cause anothertoken
not to be retrieved, such asWETH
.Refer to
NonfungiblePositionManager.collect()
andUniswapV3Pool.collect()
, both can specifyrecipient
to avoid this problem.Impact
collectLiquidity()
cannot specify the recipient, causingLP
to enter the blacklist of a certain token, and both tokens cannot be retrieved.Recommended Mitigation
Assessed type
Other