Platform: Code4rena
Start Date: 12/08/2022
Pot Size: $50,000 USDC
Total HM: 15
Participants: 120
Period: 5 days
Judge: Justin Goro
Total Solo HM: 6
Id: 153
League: ETH
Rank: 6/120
Findings: 2
Award: $2,581.49
🌟 Selected for report: 1
🚀 Solo Findings: 1
🌟 Selected for report: CertoraInc
2535.6587 USDC - $2,535.66
https://github.com/code-423n4/2022-08-frax/blob/main/src/contracts/FraxlendPairCore.sol#L539
Decimals limitation limits the tokens that can be used.
Let's give some name to the decimals of certain numbers: n = decimals of numerator oracle. d = decimals denominator oracle. a = decimals of the asset. c= decimals of the collateral.
now, the oracleNormalization = 10 ^(18 + n - d + a - c).
And here: https://github.com/code-423n4/2022-08-frax/blob/main/src/contracts/FraxlendPairCore.sol#L536 , price has decimals of 36 + n -d, so here() when we calculate _exchangeRate = _price / oracleNormalization; it would underflow and revert if a >18 +c.
And that's a pretty big limitation on the tokens options. We have USDC which have 6 decimals so all the tokens the their decimals < 24 are not possible to use in this system (with USDC together).
#0 - DrakeEvans
2022-09-06T12:23:51Z
Known issue, prevents certain combinations of tokens from being deployed. No high risk as no deployment will occur. No funds at risk, no incorrect functionality. Low at best.
#1 - gititGoro
2022-10-03T23:07:02Z
This hasn't been listed as a known issue so it can't be marked invalid but since deployments can't occur, it's a medium severity.
🌟 Selected for report: 0x1f8b
Also found by: 0x52, 0xA5DF, 0xDjango, 0xNazgul, 0xNineDec, 0xSmartContract, 0xmatt, 0xsolstars, Aymen0909, Bnke0x0, CertoraInc, Chom, CodingNameKiki, Deivitto, Dravee, ElKu, EthLedger, Funen, IllIllI, JC, Junnon, Lambda, LeoS, MiloTruck, Noah3o6, PaludoX0, ReyAdmirado, Rohan16, RoiEvenHaim, Rolezn, SaharAP, Sm4rty, SooYa, The_GUILD, TomJ, Waze, Yiko, _Adam, __141345__, a12jmx, ak1, asutorufos, auditor0517, ayeslick, ballx, beelzebufo, berndartmueller, bin2chen, brgltd, c3phas, cRat1st0s, cccz, cryptonue, cryptphi, d3e4, delfin454000, dipp, djxploit, durianSausage, dy, erictee, fatherOfBlocks, gogo, gzeon, hyh, ignacio, kyteg, ladboy233, medikko, mics, minhquanym, oyc_109, pfapostol, rbserver, reassor, ret2basic, robee, sach1r0, simon135, sryysryy, tabish, yac, yash90, zzzitron
45.8342 USDC - $45.83
https://github.com/code-423n4/2022-08-frax/blob/main/src/contracts/FraxlendPairCore.sol#L748
Put users at a risk of liquidation because they can take loans that very close or even on the max_ltv.
It is very important to differ between the maxium_ltv to the liquidation threshold since otherwise users would be able to take loan that on this threshold and every minor change on the assets price would put them expose for liquidation.
On Compound and AAVE there is a a clear different between the max_ltv and the liquidation_threshold, so users can't take those un safe loans.
You can read in this technical paper: https://github.com/aave/aave-v3-core/blob/master/techpaper/Aave_V3_Technical_Paper.pdf
At the difference between them in aave
Create a liquidation threshold > max ltv and configure them as you want. Let the users take loans up to the max ltv and let users liquidate them when the loan gets to the liquidation threshold.
#0 - DrakeEvans
2022-09-06T14:05:24Z
As intended, protections happen at UI level not primitive level.
#1 - gititGoro
2022-10-02T05:04:53Z
Downgrading to QA as this suggestion would facilitate a less jarring experience but is not necessary.