Founders DAO security record

The `renewSubscriptionFor` function in the contract allows anyone to renew the subscription for any contributor with the fund from the `payer` by specifying a Non-zero payer address. The main concern, however, lies in the lack of adequate checks to validate if the payer address has authorized the payment in the first place or if the `msg.sender` indeed corresponds to the `payer`. This allows an unauthorized entity to pay for a subscription renewal without the consent of the intended payer. ```solidity=137 function renewSubscriptionFor( address contributor, address sponsor, address payer ) public { if (payer == address(0)) { _transferTokens(contributor); } else { _transferTokens(payer); } ... ```

In `DynamicICO` contract, user can buy tokens with `purchasePriceFor` and `purchaseAmountFor` functions. By allowing users to supply the recipient address, an attacker can manipulate other users into involuntarily purchasing FNDRTokens if they have approved the contract's address with a significant token allowance. This vulnerability compromises the integrity of the token purchase process and poses a substantial risk to users.

Performing integer division before multiplication truncates the low bits, losing the precision of calculation. ```solidity=93 uint availableAmount = (token.balanceOf(address(this)) * vesting_percentage) / 100; ``` ```solidity=102 token.transfer( contributorWallets[contributorId], (patrons[contributorId] * availableAmount) / totalPatrons ); ```

Some contracts import Hardhat debugging contracts. This is not necessary on deployment, and will add extra bytes to the total contract size.

Functions that update state variables should emit relevant events as notifications.

Addresses are not validated before assignment or external calls, potentially allowing the use of zero addresses and leading to unexpected behavior or vulnerabilities. For example, transferring tokens to a zero address can result in a permanent loss of those tokens. ```solidity=71 communityPoolAmbassadors_addr = _communityPoolAmbassadors_addr; ``` - `_communityPoolAmbassadors_addr` is not zero-checked before being used. --- ```solidity=72 communityPoolContributors_addr = _communityPoolContributors_addr; ``` - `_communityPoolContributors_addr` is not zero-checked before being used. --- ```solidity=73 daoWallet_addr = _daoWallet_addr; ``` - `_daoWallet_addr` is not zero-checked before being used. --- ```solidity=74 liquidityWallet_addr = _liquidityWallet_addr; ``` - `_liquidityWallet_addr` is not zero-checked before being used. --- ```solidity=43 daoWallet_addr = _daoWallet_addr; ``` - `_daoWallet_addr` is not zero-checked before being used. --- ```solidity=44 dao_reserve_addr = _dao_reserve; ``` - `_dao_reserve` is not zero-checked before being used. --- ```solidity=45 dynamic_ico_addr = _dynamic_ico; ``` - `_dynamic_ico` is not zero-checked before being used. --- ```solidity=46 community_pool_ambassadors_addr = _community_pool_ambassadors; ``` - `_community_pool_ambassadors` is not zero-checked before being used. --- ```solidity=47 community_pool_contributors_addr = _community_pool_contributors; ``` - `_community_pool_contributors` is not zero-checked before being used. --- ```solidity=48 team_addr = _team; ``` - `_team` is not zero-checked before being used.

There is no access control for the linked `initialize` functions. Malicious hackers may observe the pending transaction which will execute the `initialize` function, and launch a similar transaction but with the parameters picked by the hacker himself, and front-run the orininal transaction. ```solidity=29 function initialize( address _token, address _buyingToken, address _firstContributors, address _daoWallet_addr ) public { require(!initialized, "DynamicICO: contract is already initialized"); token = FNDRToken(_token); require(token.balanceOf(address(this)) > 0, "Initialize token first!"); buyingToken = IERC20Metadata(_buyingToken); tokenDecimals = token.decimals(); buyingTokenDecimals = buyingToken.decimals(); daoWallet_addr = _daoWallet_addr; initialized = true; initialValuation = 1 * (10 ** uint256(tokenDecimals - 2)); firstContributorsAllocation = 548583800; token.transfer(_firstContributors, firstContributorsAllocation); amountSold = firstContributorsAllocation * (10 ** uint256(tokenDecimals)); } ```

The return values of the `transferFrom()` calls in the smart contract are not checked. Some ERC-20 tokens' transfer functions return no values, while others return a bool value, they should be handled with care. If a function returns `false` instead of reverting upon failure, an unchecked failed transfer could be mistakenly considered successful in the contract. --- ```solidity=100 buyingToken.transferFrom(recipient, daoWallet_addr, buyingTokenAmount); ``` --- ```solidity=213 buyingToken.transferFrom(recipient, daoWallet_addr, buyingTokenAmount); ```

The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.