Platform: Code4rena
Start Date: 20/09/2022
Pot Size: $30,000 USDC
Total HM: 12
Participants: 198
Period: 3 days
Judge: 0xean
Total Solo HM: 2
Id: 164
League: ETH
Rank: 148/198
Findings: 1
Award: $18.86
🌟 Selected for report: 0
🚀 Solo Findings: 0
🌟 Selected for report: AkshaySrivastav
Also found by: 0v3rf10w, 0x040, 0x1f8b, 0x4non, 0x5rings, 0x85102, 0xA5DF, 0xDecorativePineapple, 0xNazgul, 0xSky, 0xSmartContract, 0xbepresent, 0xf15ers, 0xmatt, 2997ms, Aeros, Aymen0909, B2, Bahurum, Bnke0x0, CertoraInc, Chom, ChristianKuri, CodingNameKiki, Deivitto, Diana, Diraco, Dravee, ElKu, Funen, IllIllI, JC, JLevick, JohnSmith, JohnnyTime, KIntern_NA, Lambda, Margaret, MasterCookie, OptimismSec, RaymondFam, Respx, ReyAdmirado, RockingMiles, Rohan16, Rolezn, Ruhum, RustyRabbit, Sm4rty, SooYa, StevenL, TomJ, Tomo, V_B, Waze, Yiko, __141345__, a12jmx, ajtra, ak1, async, ayeslick, aysha, berndartmueller, bin2chen, bobirichman, brgltd, bulej93, c3phas, carrotsmuggler, cccz, ch13fd357r0y3r, chatch, cryptostellar5, cryptphi, csanuragjain, d3e4, datapunk, delfin454000, dic0de, djxploit, durianSausage, eighty, erictee, exd0tpy, fatherOfBlocks, gogo, got_targ, hansfriese, ignacio, ikbkln, indijanc, innertia, joestakey, karanctf, ladboy233, leosathya, lukris02, martin, medikko, millersplanet, nalus, natzuu, neko_nyaa, neumo, obront, oyc_109, pcarranzav, peanuts, pedr02b2, pedroais, peiw, peritoflores, prasantgupta52, rajatbeladiya, rbserver, reassor, ret2basic, rokinot, romand, rotcivegaf, rvierdiiev, sach1r0, seyni, sikorico, slowmoses, sorrynotsorry, supernova, tibthecat, tnevler, ubermensch, yongskiws, zzykxx, zzzitron
18.8574 USDC - $18.86
Remove these types devs comments after changes have been made or development decisions have been made to the code base as a standard practice (ideally these should have been removed before code audit) , or at a minimum remove said comments before deployment to mainnet to stop unsavoury characters from seeing these and potentially using these types of comments to find potential flaws in the project
line 256 // Actually only one of linearvested/cliff amount must be 0, not necessarily both line 258 // Do we need to check whether _startTimestamp is greater than the current block.timestamp? line 259 // Or do we allow schedules that started in the past? line 260 // -> Conclusion: we want to allow this, for founders that might have forgotten to add some users, or to avoid issues with transactions not going through because of discoordination between block.timestamp and sender's local time line 261 // require(_endTimestamp > 0, "_endTimestamp must be valid"); // not necessary because of the next condition (transitively) require(_startTimestamp < _endTimestamp, "INVALID_END_TIMESTAMP"); // _endTimestamp must be after _startTimestamp line 266 // Potential TODO: sanity check, if _linearVestAmount == 0, should we perhaps force that start and end ts are the same? line 268 // No point in allowing cliff TS without the cliff amount or vice versa. line 269 // Both or neither of _cliffReleaseTimestamp and _cliffAmount must be set. If cliff is set, _cliffReleaseTimestamp must be before or at the _startTimestamp
I was not sure what level to report this as I am still learning so I have left it to the judges to judge validity and threat level to the project
Only check _linerVestAmount is > 0, as your only returning a check on this value in the return statement, this does not return a check for _cliffAmount (this should return a value of INVALID_CLIFF_AMOUNT as well as INVALID_VESTED_AMOUNT for the return statement to be valid for both values) even though your asking for a check to be carried out on _linearVestAmount + _cliffAmount.
However I also noted that there is the possibilty for _cliffAmount to not be zero if there is vesting??? (_cliffReleaseTimestamp - The timestamp when the cliff is released (must be <= _startTimestamp, or 0 if no vesting)) Also noted by the dev //cliffAmount - The amount released at _cliffReleaseTimestamp. Can be 0 if _cliffReleaseTimestamp is also 0, if _cliffReleaseTimestamp is not 0 and there is vesting .. wouldnt it be safer to do a check on just _linearVestAmount as noted by the dev so that claim creation cannot be broken.
Also checking just the one value will make the contract slightly cheaper to deploy decreasing overall cost on the life cycle of the project.
line256 VTVLvesting.sol
require(_linearVestAmount + _cliffAmount > 0, "INVALID_VESTED_AMOUNT");
linearVestAmount - The total amount to be linearly vested between _startTimestamp and _endTimestamp cliffAmount - The amount released at _cliffReleaseTimestamp. Can be 0 if _cliffReleaseTimestamp is also 0.