Platform: Code4rena
Start Date: 04/11/2021
Pot Size: $50,000 USDC
Total HM: 20
Participants: 28
Period: 7 days
Judge: 0xean
Total Solo HM: 11
Id: 51
League: ETH
Rank: 11/28
Findings: 3
Award: $925.81
🌟 Selected for report: 4
🚀 Solo Findings: 0
🌟 Selected for report: gpersoon
Also found by: elprofesor, fr0zn, pauliax
529.9131 USDC - $529.91
fr0zn
On the AirdropDistribution.sol, inside the validate function (line 506) , the validated[msg.sender] is not checked and the validation for an already airdropped user is done using the airdrop[msg.sender].amount value.
Provide a detailed description of this particular bug/vulnerability.
From a theoretical perspective, with infinite time, the airdrop[msg.sender].amount could be zero, leading to any user to call validate and reclaim the airdrop again. Although this is highly unlikely, the impact of this could lead to any user to double claim and spend their tokens.
Manual code review
It is recommended to check for validated[msg.sender] == 1 instead of airdrop[msg.sender].amount == 0 on line 506.
#0 - CloudEllie
2022-01-04T17:05:56Z
Just noting here that #129 is currently open, so I'm assuming the sponsor intends for it to be selected as the primary issue (for inclusion in the report), unless the judge indicates otherwise.
130.8427 USDC - $130.84
fr0zn
On the AirdropDistribution.sol, the airdrop_supply (line 462) value is set to be 20160000. However, adding all the airdropBalances does show that the value should be 20159997 instead.
This does cause some operations on the contract to mislead in the results. This is more noticed on bigger airdropped accounts.
Adding all the airdropBalances values do show the difference.
Manual code review
The airdrop_supply should be reflecting the actual airdropped balance without misleading the total amount. Change the value to 20159997.
fr0zn
The claim (line 522) and the claimExact (line 551) functions, do contain almost the same code but with different require and assertions.
Having different asserts and requirements for the same or similar code could produce state inconsistency leading to a loss of funds.
Manual code review
It is recommended to be consistent with the code and to have the same assertion/require checks on both, claim and claimExact.
For example, the claimExact:
require(avail > 0, "Nothing claimable (yet?)"); check.assert(claimable > 0); check.#0 - chickenpie347
2022-01-03T21:05:40Z
Duplicate of #92
#1 - 0xean
2022-01-09T00:16:09Z
I think this is actually a dupe of #126
12.1196 USDC - $12.12
fr0zn
In the AidropDistribution.sol contract inside the _updateEmission function (line 579), the timestamp check is redundant since the public function (updateEmission), where the function is only used, does already perform the same check.
Gas optimization
Manual code review
The check could be removed for gas optimization.
#0 - 0xean
2022-01-08T22:52:29Z
dupe of #34
🌟 Selected for report: fr0zn
44.8876 USDC - $44.89
fr0zn
The InvestorDistribution (InvestorDistribution.sol) contract does contain some statements that could be removed to optimize the gas usage.
Gas optimization
Manual code review
12.1196 USDC - $12.12
fr0zn
The _available_supply and available_supply functions on the AirdropDistribution (lines 601 and 607) do contain the exact same code.
Furthermore, the assert check inside those functions should be changed to a require statement since the check is not an invariant and gas refund should take place if the check fails (SWC-110).
Gas optimization
Manual code review
The available_supply and _available_supply functions should be combined into a single public function (public functions can be used internally without any extra gas) or have the public function call the internal implementation and use the private implementation in the contract.
The assert check in the available_supply function should be changed to a require statement since the check is not an invariant.
🌟 Selected for report: fr0zn
44.8876 USDC - $44.89
fr0zn
On the claim function (line 524) of the AirdropDistribution.sol contract, the validated check is redundant. The flag is only set when the validate function is called. Once validated, the amount will always be different than zero, meaning that the check is not necessary.
Gas optimization
Manual code review
The check could be removed for gas optimization.
20.1994 USDC - $20.20
fr0zn
The Vesting (Vesting.sol) contract does contain some statements that could be removed to optimize the gas usage.
Gas optimization
Manual code review
vest function, on line 77, the variable _isRevocable is checked for being either 0 or 1. The variable could be changed to a boolean instead of a uint256. This will allow removing the statement on line 77 and lines from 83 to 89 (here), could be simplified to a single line benRevocable[_beneficiary] = [_isRevocable,false]; or to benRevocable[_beneficiary][0] = _isRevocable.#0 - 0xean
2022-01-08T22:50:10Z
duplicate of #112