Read the findings of the 2022 Web3 Security Report

In the contract `Airdrop` the role `_owner` has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/5995ac0a609742b188670680cc31783b/diagrams/centralization_Airdrop__owner.svg)

---

In the contract `DreamNFT` the role `_owner` has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/5995ac0a609742b188670680cc31783b/diagrams/centralization_DreamNFT__owner.svg)

---

In the contract `DreamToken` the role `_owner` has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/5995ac0a609742b188670680cc31783b/diagrams/centralization_DreamToken__owner.svg)

---

In the contract `IDO` the role `_owner` has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/5995ac0a609742b188670680cc31783b/diagrams/centralization_IDO__owner.svg)

---

In the contract `StakingLp` the role `_owner` has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/5995ac0a609742b188670680cc31783b/diagrams/centralization_StakingLp__owner.svg)

---

In the contract `StakingNft` the role `_owner` has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/5995ac0a609742b188670680cc31783b/diagrams/centralization_StakingNft__owner.svg)

---

In the contract `StakingToken` the role `_owner` has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/5995ac0a609742b188670680cc31783b/diagrams/centralization_StakingToken__owner.svg)

Centralization Related Risks

The **require** can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.

Missing Error Messages

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

Missing Emit Events

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.

Variables That Could Be Declared as Immutable

In the `StakingToken.redeem()` function, the user redeems their stake assets, but this protocol does not clear `user.stakes` and other related information. As a result, users can repeatedly call `redeem()` to redeem assets, causing the `stake` pool and the current contract's reward pool to be depleted.

There are similar issues in `StakingNft.redeemBy721()`, `StakingNft.redeemBy1155()` and `StakingLp.redeem()`.

Potential Financial Loss

All of the DreamToken tokens are sent to the contract deployer when deploying the contract. This could be a centralization risk as the deployer can distribute DreamToken tokens without obtaining the consensus of the community.

Initial Token Distribution

```solidity=127
function mint(address to, uint256 amount, uint256 blockNum, uint256 nonce, bytes memory signature) external {
  require(blockNum > _startM, 'Mining no start!');
  require(blockNum > _uM[to], 'This blocknum is already taked!'); 
  require(_mUsed.add(amount) <= _mTotalSupply,'MiningTotalSupply limit!');
  uint month = (blockNum - block.number) / (28800 * 30)  + 1;
  require(_mUsed.add(amount) <= _mLimit[month] ,'Month mining limit!');             
  _verify(nonce,signature,abi.encodePacked(to, amount,blockNum, nonce)); 
  _mSurplus = _mSurplus.sub(amount);
  _mUsed = _mUsed.add(amount);
  uint256 fee = amount / 10;
  _mint(to,amount.sub(fee));
  _mint(_taxer,fee);
  emit Mining(to, amount, fee, nonce);
}
```

What is the use of variable `_mLimit` in method `mint()`?

We guess that it is used to limit the number of tokens minted per month. And there are two questions.

1. `(_mLimit[month+1] - _mLimit[month]) * 10**18 / 30`. - The result of this formula is the daily increment, and it will be multiplied with a `block` number `p`. Please double-check this logic.

2. In the next `require(mUsed.add(amount)<= limit)`, it seems that `limit` should be the daily `amount` limit, but `mUsed.add(amount)` is the cumulative `amount` for several months, is this comparison in `require` correct? My understanding is that here it may be `require(mUsed.add(amount)<= _mLimit[month] + limit)'?

Logic issue in `mint()` function

In the `idoLimit( )` code, the `joiners` variable does not count users who have only participated in `round=1`; only users who have participated in both `round=1` and `round=2` are recorded as `joiners`.

```solidity=112
if (_limit[msg.sender][1]) {
    _joiners ++;
}
_limit[msg.sender][_currRound] = true; 
```

In `ido()`, joiners count users who have only participated in `round=3`.
```solidity=89
if (!_limit[msg.sender][1]&&!_limit[msg.sender][2]){
    _joiners ++;
} 
```

Is this consistent with the design intent?

Logic issue in `idoLimit()` function

```solidity=176
User storage user = _users[nftToken][msg.sender];
```

```solidity=196
for (uint i = 0; i < user.tokenIds.length; i++){
  delete user.tokenIds[i];
  IERC721(nftToken).transferFrom(address(this),msg.sender,user.tokenIds[i]);
  emit Redeem(msg.sender,nftToken,user.tokenIds[i],_award,amount,721);
}
```

1. In the function `redeemBy721()`, after line 197 `delete user.tokenIds[i]`, the items in the array indexed by `i` will be zero. Therefore, line 198 `IERC721.transferFrom()` will get a zero token ID as an input parameter. This call may be broke.

2. `delete array.itme` will clear the item value instead of removing this item from the array. As a result, this array will get longer and longer, and will consume a little more gas after each user redeems once. This could be a potentially critical issue, especially for committed users.

Logic Issue In `redeemBy721()`

Example code from `openzeppelin.ERC1155`:
```solidity
function balanceOf(address account, uint256 id) public view virtual override returns (uint256) {
  require(account != address(0), "ERC1155: address zero is not a valid owner");
  return _balances[id][account];
}
```

Please refer to the `openzeppelin` library for sample code.

Each user may provide the `ERC1155` token with the same `tokenId` to the protocol multiple times. Based on the current logic, there may be many same `tokenId` items in the `user.tokenIds` array. This may waste gas when looping through all id items.

The `stakeBy1155()` function wastes gas

Dreamer Finance

Airdrop.sol

Dreamer Finance

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

10

0

6

0

4