Fandomdao security record

One or more parameters with `memory` data location are never modified in their functions and those functions are never called internally within the contract. Thus, their data location can be changed to `calldata` to avoid the gas consumption copying from calldata to memory. ```solidity=16 function createContract( ``` `createContract` has memory location parameters: `initData`. --- ```solidity=28 function upgradeContract( ``` `upgradeContract` has memory location parameters: `initData`.

The `TokenWrapper` contract contains two critical functions, `withdrawAccount()` and `withdrawExcessByAdmin()`, which are currently accessible by any external caller. This poses a significant security risk as it allows unauthorized users to withdraw tokens from any account and withdraw excess tokens from the contract.

When a loop allows an arbitrary number of iterations or accesses state variables in its body, the function may run out of gas and revert the transaction. ```solidity=145 for (uint256 i = startIndex; i < endIndex; i++) { ``` Function `DpPool.getStakeholders` contains a loop and its loop condition depends on parameters: `endIndex`, `startIndex`. --- ```solidity=163 for (uint256 i = startIndex; i < endIndex; i++) { ``` Function `DpPool.getStakeholderDetails` contains a loop and its loop condition depends on parameters: `endIndex`, `startIndex`.

The contract is serving as the underlying entity to interact with one or more third party protocols. The scope of the audit treats third party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity=17 IERC20 public stakeToken; ``` - The contract `TokenWrapper` interacts with third party contract with `IERC20` interface via `stakeToken`.