Read the findings of the 2022 Web3 Security Report

The contract has unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers. This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

---

`pragma solidity ^0.8.0;` will allow the version `solc-0.8.11` which is too recent to be recommended for deployment.

Unlocked Compiler Version | Incorrect Versions Of Solidity

The contract is serving as the underlying entity to interact with third party `Settings` protocols. The scope of the audit treats 3rd party entities as black boxes and assume their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, migrating to new LP pools, etc.

Third Party Dependencies

In the contract, `AMT`, 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/c6f50c559a9c4651b7b8b277f7c0a38b/diagrams/centralization-AMT-_owner.svg)

In the contract, `Operator`, 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/c6f50c559a9c4651b7b8b277f7c0a38b/diagrams/centralization-Operator-_owner.svg)

In the contract, `Ownable`, 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/c6f50c559a9c4651b7b8b277f7c0a38b/diagrams/centralization-Ownable-_owner.svg)

---

In the contract, `AMT`, 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/1a353b98e312404fa17dbb1377c3ad92/diagrams/centralization-AMT-_owner.svg)

---

In the contract, `AMT`, 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/1a353b98e312404fa17dbb1377c3ad92/diagrams/centralization-AMT-_owner.svg)

Centralization Related Risks in Pools

Ether and gas is specified using following syntax since version 0.7.0: 

 - x.f{gas: 10000, value: 2 ether}(arg1, arg2). 

Because the version `^0.6.0` is specified in this contract, it will be better to use old syntax here :

 - x.f.gas(10000).value(2 ether)(arg1, arg2)

The team can confirm this in the official documentation : [Solidity v0.7.0 Breaking Changes](https://docs.soliditylang.org/en/v0.8.11/070-breaking-changes.html#changes-to-the-syntax)

Potential Compiler Error

State variables are inline initialized using either non-constant state variables or function calls that are not pure/constant. Since inline initialization occurs before constructor call, some non-constant state variables may not be initialized and non-constant functions may behave in an unexpected way.

#### `Farm/AMT-BNB-LP.sol` And `Farm/AMT-BUSD-LP.sol`
```solidity=791
uint256 public rewardRate = 878 * 1e18 / daySeconds;  // ≈ 81018518518518512
```

#### `NFT/StakingJoinFull.sol`
```solidity=979
uint256 public rewardRate = 14058 * 1e18 / daySeconds;  // ≈ 81018518518518512
```

#### `Pool/AMT-Pool.sol`
```solidity=790
uint256 public rewardRate = 1757 * 1e18 / daySeconds;  // ≈ 81018518518518512
```

#### `Pool/BNB-Pool.sol`
```solidity=790
uint256 public rewardRate = 2250 * 1e18 / daySeconds;  // ≈ 81018518518518512
```

Function Initializing State

### `Farm/AMY-BNB-LP.sol`
The result of formula will be about **10162037037037037**, but " ≈ 81018518518518512" is described in comment.
```solidity=791
uint256 public rewardRate = 878 * 1e18 / daySeconds;  // ≈ 81018518518518512
```

### `Farm/AMY-BUSD-LP.sol`
The result of formula will be about **10162037037037037**, but " ≈ 81018518518518512" is described in comment.
```solidity=791
uint256 public rewardRate = 878 * 1e18 / daySeconds;  // ≈ 81018518518518512
```

### `NFT/Exchange.sol`
The struct is named **`Order`** but "auction" is described in comment.
```solidity=793
// auction
  struct Order {
    address seller;
    uint256 tokenId;
    uint8 tokenKey;
    uint256 price;
    uint256 startTime;
  }
```

### `Pool/AMT-Pool.sol`
The result of formula will be about **20335648148148148**, but " ≈ 81018518518518512" is described in comment.
```solidity=791
uint256 public rewardRate = 1757 * 1e18 / daySeconds;  // ≈ 81018518518518512
```

### `Pool/BNB-Pool.sol`
The result of formula will be about **26041666666666666**, but " ≈ 81018518518518512" is described in comment.
```solidity=793
uint256 public rewardRate = 2250 * 1e18 / daySeconds;  // ≈ 81018518518518512
```

### `swap/AmaterasFactory.sol`
According to the code, **1/4th** of the growth in sqrt(k) will mint liquidity equivalent to `feeTo`, but "1/6th" is described in comment.
```solidity=339
// if fee is on, mint liquidity equivalent to 1/6th of the growth in sqrt(k)
```
```solidity=350
  uint denominator = rootK.mul(3).add(rootKLast);
```

Inconsistent Comments and Code

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

Missing emit events

The linked variables could be declared as `constant` since these state variables are never modified.

Variables that could be declared as `constant`

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`

The return value of pure function `TZLibrary.pairFor()` is never used. 

Redundant code in `swap/AmaterasRouter.sol`

DividendsPool.distributionIncome(uint256) (Dividends.sol#2662-2703) performs a multiplication on the result of a division:

### `lastReward`
 - uint256 lastReward = comingAmount * 2 / 100; (Dividends.sol#2668)

 - uint256 perShare = lastReward * (10 ** 18) / pool.totalPower; (Dividends.sol#2674)

### `currentReward`

 - uint256 currentReward = amount * 2 / 100; (Dividends.sol#2688)

 - uint256 perShare = currentReward * (10 ** 18) / pool.totalPower; (Dividends.sol#2694)

Divide Before Multiply

Function state mutability can be restricted to pure in which case they promise not to read from or modify the state.

Proper Usage of `pure` And `view`

The parameters `_period` in Function `DividendsPool.setPeriod()` will change the value of state variables which are used as divisor in calculation. It should be verified as non-zero-value to prevent reverting :

```solidity=2852
function setPeriod(uint256 _period) onlyOwner public {
  period = _period;
  comingDay = block.timestamp / period;
}
```

Lack of Sanity Check in `NFT/Dividends.sol`

```solidity=2744
function _getTokensPower(uint256 tokenId) private returns (uint256){

  return 1;
}
```

The function `_getTokensPower()` always returns constant value one.

Empty function

In contract, users are able to bid an auction by executing function `Exchange.bid()`, and they will send their fund to contract `Exchange`:

```solidity=1029
IERC20 token_ = IERC20(token.token);
uint256 before_ = token_.balanceOf(address(this));
token_.safeTransferFrom(msg.sender, address(this), price);
uint256 after_ = token_.balanceOf(address(this));
uint256 diff = after_ - before_;
require(diff > auction.addLimit, 'bid:diff error!');
if (auction.winner != address(0)) {
  token_.safeTransfer(auction.winner, auction.price);
}
auction.price = price;
auction.winner = msg.sender;
```

When auction ends, users could execute function `Exchange.end()` to withdraw the NFT they win. But according to the following code, users have to pay twice for their bid:

```solidity=1063
uint256 userPrice = auction.price - ((auction.price * feeRate) / feeTotal);
uint256 feePrice = auction.price - userPrice;
require((feePrice + userPrice) == auction.price, 'token: order Amt error');
// transfer erc721 to winner
TokenInfo storage token = tokens[auction.tokenKey];
require(token.available, 'token: token not available');
IERC20 token_ = IERC20(token.token);
token_.safeTransferFrom(msg.sender, auction.seller, userPrice);
token_.safeTransferFrom(msg.sender, feeAddress, feePrice);
nft.safeTransferFrom(address(this), auction.winner, auction.tokenId);
auction.auctionState = State.ended;
```

Financial Models in `NFT/Exchange.sol`

In the current implementation, there is no upper limit for the fee rate. Misuse of these fee setting functions could damage the whole tokenomics. For example, the owner can set the fee rate to more than 100% to cause all transactions to revert.

```solidity=845
function setFeeRate(uint16 _feeRate) public onlyOwner{
  feeRate = _feeRate;
}
```

No Upper Limit for FeeRate

The following parameters should be verified as non-zero-value to prevent reverting :

1. The parameters `_shift` in Function `Exchange.setToken()` will change the value of state variables that are used as divisors in the calculation.
```solidity=837
function setToken(uint8 tokenKey, address _token, bool _available, uint8 _shift) public onlyOwner {
  tokens[tokenKey] = TokenInfo({
  token: _token,
  shift : _shift,
  available : _available
  });
}
```
```solidity=1040
uint256 history = (uint256(uint160(msg.sender)) << 96) | (price / tokens[auction.tokenKey].shift);
```

2. The parameters `_auctionLength` in Function `setAuctionLength.setToken()` will change the value of state variables which are used to control an auction transaction. 
```solidity=853
function setAuctionLength(uint256 _auctionLength) public onlyOwner {
  auctionLength = _auctionLength;
}
```
A new auction's end timestamp will be set as :
```solidity=966
    auctionEnd: block.timestamp + auctionLength,
```
If `auctionLength` is zero, This means that all newly launched auctions end when they start.

Lack of Sanity Check in `NFT/Exchange.sol`

### `Factory.beInviter()`
Only users who are not inviters need to pay for becoming inviters. There will be a risk that users may pay again even if they are already inviters.
```solidity=2631
function beInviter() onlyUser external {
  IERC20(settings.mat()).safeTransferFrom(msg.sender, settings.dev(), settings.beInviterAmt());
  canBeInviter[msg.sender] = true;
}
```

### Ur-Card's Stock
According to the function `Settings.getUrCard()` called in `Factory.buyUr()`, we could understand that maximum amount of each UR-Level card is 100, But this maximum amount is not checked in Function `Factory.gainUr()` , `Factory.gainAny()` and `Factory._openOneBox()`.

Lack of Sanity Check in `NFT/Factory.sol`

There is possibility that users buy a Gatcha-Box but get nothing.

Risk Needs to Be Disclosed to Users

If statement `settings.getUrCard(index);` fails, the gas used for `safeTransferFrom` will be wasted.
```solidity=2636
function buyUr(uint256 index) onlyUser external {
  IERC20(settings.usdt()).safeTransferFrom(msg.sender, settings.dev(), settings.urPrice());
  settings.getUrCard(index);
  mint(uint8(5), uint8(index));
}
```
```solidity=324
function getUrCard(uint256 index) public override onlyFactory {
  require(urCount[index] < maxUrCount, 'no left');
  urCount[index]++;
}
```

Improper Sequence of Code

The owner of contract `DividendsPool`, `Exchange`, `Factory` has the permission to do following without obtaining the consensus of the community :

  1. send ERC20 tokens to specified address `to_` from this contract
  2. send NFTs to specified address `to_` from this contract

The owner of contract `Factory` has the permission to mint any NFT-card without obtaining the consensus of the community.

Over Privileged Ownerships

In the contract, `DividendsPool`, 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/c6f50c559a9c4651b7b8b277f7c0a38b/diagrams/centralization-DividendsPool-_owner.svg)

---

In the contract, `Exchange`, 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/c6f50c559a9c4651b7b8b277f7c0a38b/diagrams/centralization-Exchange-_owner.svg)

---

In the contract, `Factory`, 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/c6f50c559a9c4651b7b8b277f7c0a38b/diagrams/centralization-Factory-_owner.svg)

---

In the contract, `Settings`, 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/c6f50c559a9c4651b7b8b277f7c0a38b/diagrams/centralization-Settings-_owner.svg)

---

In the contract, `StakingPool`, 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/c6f50c559a9c4651b7b8b277f7c0a38b/diagrams/centralization-StakingPool-_owner.svg)

Centralization Related Risks

The return value of `IERC20.transfer` call is not checked

Unchecked Transfer

Address should be checked before assignment to make sure it is not zero addresses.

Missing Zero Address Validation


### `NFT/Dividends.sol`
The parameter `tokenId` in function `_getTokensPower()` is not used within the function.

-----

### `NFT/Exchange.sol`
The parameter `history` in `Exchange.bid()` is not used within the function.


Unused Parameter

The reported state variables are used in the aforementioned functions but are never initialized in the constructor.

StakingPool.starttime (NFT/StakingJoinFull.sol#977) is never initialized. It is used in:

```solidity=1028
modifier checkStart() {
  require(block.timestamp >= starttime, 'AMT: not start');
  _;
}
```

Uninitialized State Variable

Accessing storage variables in a loop can be costly in terms of gas consumption.

StakingPool.deposit(uint256[]) (NFT/StakingJoinFull.sol#1064-1069) has costly operations inside a loop:
  - totalStake = totalStake + 1 (NFT/StakingJoinFull.sol#1067)

StakingPool.withdraw(uint256[]) (NFT/StakingJoinFull.sol#1089-1094) has costly operations inside a loop:
  - totalStake = totalStake - 1 (NFT/StakingJoinFull.sol#1092)

StakingPool.stakeBurnTokens(uint256[]) (NFT/StakingJoinFull.sol#1112-1117) has costly operations inside a loop:
  - totalStake = totalStake - 1 (NFT/StakingJoinFull.sol#1115)

Costly Operation Inside Loop

It is now well understood that the difficulty or timestamp is not a source of randomness. They can be manipulated if the attacker is also a miner. For EVM compatible blockchains such as Binance smart chain and Polygon, the `block.difficulty` can be the same value across multiple blocks, making the situation even worse. 

Amateras

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

28

0

28

0

0