Platform: Code4rena
Start Date: 21/06/2022
Pot Size: $30,000 USDC
Total HM: 12
Participants: 96
Period: 3 days
Judge: HardlyDifficult
Total Solo HM: 5
Id: 140
League: ETH
Rank: 71/96
Findings: 1
Award: $28.35
🌟 Selected for report: 0
🚀 Solo Findings: 0
🌟 Selected for report: IllIllI
Also found by: 0x1f8b, 0x29A, 0x52, 0xNazgul, 0xNineDec, 0xc0ffEE, 0xf15ers, 0xkatana, BowTiedWardens, Chom, ElKu, Funen, GalloDaSballo, JC, JMukesh, JohnSmith, Lambda, Limbooo, MadWookie, MiloTruck, Nethermind, Noah3o6, Nyamcil, Picodes, PwnedNoMore, Randyyy, RoiEvenHaim, SmartSek, StErMi, Tadashi, TerrierLover, TomJ, Tomio, Treasure-Seeker, UnusualTurtle, Varun_Verma, Wayne, Waze, _Adam, apostle0x01, asutorufos, berndartmueller, c3phas, catchup, cccz, cloudjunky, codexploder, cryptphi, defsec, delfin454000, dipp, ellahi, exd0tpy, fatherOfBlocks, hansfriese, hyh, joestakey, kebabsec, kenta, masterchief, minhquanym, naps62, oyc_109, pashov, peritoflores, reassor, rfa, robee, sach1r0, saian, sashik_eth, shenwilly, simon135, slywaters, sorrynotsorry, sseefried, unforgiven, xiaoming90, ych18, zuhaibmohd, zzzitron
28.3482 USDC - $28.35
Details: In Basket.sol the initializer function is spelt as initialise, but the other contracts use the variant initialize. Consider renaming initialise to initialize to avoid confusion in the future.
Mitigation: Rename initialise to initialize in Basket.sol and corresponding test files.
Impact: Code QA
Details: Not initializing a contract after deployment could result in exploits, e.g. GHSA-5vp3-v4hc-gx76 (more details here). While the contracts use a recent version of OpenZeppelin that mitigates this particular issue, it is still recommend to ensure that (even implementation) contracts cannot be initialized after deployment.
Mitigation: Following OpenZeppelin docs, add the following function to the implementation contracts:
/// @custom:oz-upgrades-unsafe-allow constructor constructor() { _disableInitializers(); }
Impact: Code QA
lock
should come before other modifiersDetails: At L300 of NibblVault.sol the modifier lock
should be the first modifier in order to prevent execution of the other modifiers in case of reentrancy. While currently there is no obvious vulnerability, it is a good practice to place it in the first position.
Mitigation: Change L300 to
function buy(uint256 _minAmtOut, address _to) external override payable lock notBoughtOut whenNotPaused returns(uint256 _purchaseReturn) {
Impact: Code QA
#0 - HardlyDifficult
2022-07-04T19:19:12Z
Couple good best practices to include, and a couple typos.