Dora Grant DAO V4

According to the design, the contract regards 32 native tokens as one unit. Users can withdraw an integer number of units of native tokens through the `unstake()` function. ```solidity uint256 public constant DEPOSIT_SIZE = 32 ether; function unstake(uint256 _count) external { require(_count < 1 ether, "too large"); uint256 unstakeAmount = _count * DEPOSIT_SIZE; ... } ``` However, the verification condition of the `count` is too broad. One unit represents 32 native tokens with precision (32 * 10**18), so the function allows users to withdraw less than `1 * 10**18 * 32 * 10**18` native tokens at a time. It is unlikely that someone will hold so many native tokens, so the verification condition is meaningless.

According to the logic, if the user stakes more than 32 native tokens, tokens will be deposited into the `Deposit` contract through the `stake()` function. However, if the user calls `unstake()` function, the contract will not transfer the staked tokens from the `Deposit` contract to the user.

When transferring deflationary ERC20 tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee), only 90 tokens actually arrived to the contract. However, a failure to discount such fees may allow the same user to withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction. Reference: https://thoreum-finance.medium.com/what-exploit-happened-today-for-gocerberus-and-garuda-also-for-lokum-ybear-piggy-caramelswap-3943ee23a39f ```solidity=143 require(token.transferFrom(msg.sender, address(this), _amount)); ``` - Transferring tokens by `_amount`. ```solidity=154 user.activeDonation += _amount; ``` - The `_amount` appears to be used for bookkeeping purposes without compensating the potential transfer fees. --- ```solidity=77 require(token.transferFrom(msg.sender, address(this), _amount)); ``` - Transferring tokens by `_amount`. ```solidity=79 u.stakingAmount += _amount; ``` - The `_amount` appears to be used for bookkeeping purposes without compensating the potential transfer fees.

OpenZeppelin's `SafeMath` library is not used in the above contracts, making it possible for overflow/underflow to occur and lead to inaccurate calculations.

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 assume 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=15 IERC20 public token; ``` - The contract `BuidlDonation` interacts with third party contract with `IERC20` interface via `token`. --- ```solidity=11 IERC20 public token; ``` - The contract `DoraChecker` interacts with third party contract with `IERC20` interface via `token`.

According to the logic, the user who called the `init()` function will be set as the owner of the contract. ```solidity=66 function init(IERC20 _token, DoraChecker _checker) external { require(owner == address(0)); owner = msg.sender; token = _token; checker = _checker; } ``` However, after the `owner` is set, it is not used at all.