Platform: Code4rena
Start Date: 01/04/2024
Pot Size: $120,000 USDC
Total HM: 11
Participants: 55
Period: 21 days
Judge: Picodes
Total Solo HM: 6
Id: 354
League: ETH
Rank: 20/55
Findings: 2
Award: $648.15
🌟 Selected for report: 0
🚀 Solo Findings: 0
🌟 Selected for report: DadeKuma
Also found by: Bauchibred, Dup1337, Vancelot, jesjupyter, sammy
615.1933 USDC - $615.19
The creation of a pool requires the creator to mint full-range liquidity into the corresponding Uniswap V3 pool. However, this fullRangeLiquidity is calculated using the slot0 SqrtPriceX96 from the Uniswap pool, which is susceptible to manipulation.
MEV bots can utilize flash loans to front-run the creation of a pool, thereby increasing the costs for the user. The user may end up paying more token0 and token1 than necessary for creating the pool. Subsequently, these bots may execute trades that profit from the inflated prices after the pool's creation.
Manual Review
Implement the use of TWAP (Time-Weighted Average Price) instead.
MEV
#0 - c4-judge
2024-04-24T19:10:26Z
Picodes marked the issue as duplicate of #562
#1 - c4-judge
2024-05-06T15:55:26Z
Picodes marked the issue as unsatisfactory: Invalid
#2 - sammy-tm
2024-05-10T14:28:37Z
@Picodes Can you please take a look, this is a dup of #537
#3 - c4-judge
2024-05-10T14:30:29Z
Picodes marked the issue as not a duplicate
#4 - c4-judge
2024-05-10T14:30:38Z
Picodes marked the issue as duplicate of #537
#5 - c4-judge
2024-05-10T14:30:42Z
Picodes marked the issue as satisfactory
#6 - c4-judge
2024-05-13T14:24:20Z
Picodes changed the severity to 2 (Med Risk)
🌟 Selected for report: DadeKuma
Also found by: 0xStalin, 0xhacksmithh, 99Crits, Aymen0909, Bauchibred, CodeWasp, Dup1337, IllIllI, John_Femi, K42, KupiaSec, Naresh, Rhaydden, Rolezn, Sathish9098, Topmark, ZanyBonzy, albahaca, bareli, blockchainbuttonmasher, cheatc0d3, codeslide, crc32, d3e4, favelanky, grearlake, hihen, jasonxiale, jesjupyter, lanrebayode77, lirezArAzAvi, lsaudit, mining_mario, oualidpro, pfapostol, radin100, rbserver, sammy, satoshispeedrunner, slvDev, twcctop, zabihullahazadzoi
32.9585 USDC - $32.96
The calculation of the maximum shares received for a deposit in CollateralTracker.sol
is incorrect.
In the mint()
function, the assets received for a mint are being calculated using the previewMint()
function, which has a mismatch with the current maxMint()
function in the scenario in which the max possible assets are being deposited for the mint.
Detailed description of the impact of this finding.
Currently the maxMint()
function calculates the max shares as follows :
maxShares = (((type(uint104).max)*totalSupply()/totalAssets())*DECIMALS)/(DECIMALS+COMMISSION_FEE)
and previewMint()
calculates the assets received as :
assets = (shares*DECIMALS*totalAssets())/(totalSupply*(DECIMALS-COMISSION_FEE)) In the max mint scenario, let's assume the assets required are maximum, i.e, type(uint104).max : type(uint104).max = (maxShares*DECIMALS*totalAssets())/(totalSupply*(DECIMALS-COMISSION_FEE)) Simplifying, we get : maxShares = (type(uint104).ma0x)*totalSupply*(DECIMALS-COMISSION_FEE)/DECIMALS*totalAssets()
The derived formula does not match the formula used in maxMint()
leading to incorrect calculation of shares.
Manual Review
- return (convertToShares(type(uint104).max) * DECIMALS) / (DECIMALS + COMMISSION_FEE); + return (convertToShares(type(uint104).max) * (DECIMALS - COMMISSION_FEE)) / DECIMALS; ## Assessed type Error
#0 - c4-judge
2024-04-25T20:47:53Z
Picodes marked the issue as duplicate of #553
#1 - c4-judge
2024-04-25T20:48:31Z
Picodes marked the issue as not a duplicate
#2 - c4-judge
2024-04-25T20:48:34Z
Picodes marked the issue as primary issue
#3 - dyedm1
2024-04-29T14:07:33Z
actually is dup #553 , conf'd there
#4 - c4-judge
2024-04-29T21:38:02Z
Picodes marked the issue as duplicate of #553
#5 - c4-judge
2024-04-29T21:41:30Z
Picodes marked the issue as satisfactory
#6 - c4-judge
2024-05-09T19:15:20Z
Picodes changed the severity to QA (Quality Assurance)
#7 - c4-judge
2024-05-10T00:08:59Z
Picodes marked the issue as grade-b