Sign Up for a Code Audit Today and Get 3 Months of Skynet for Free

In the contract `AITECH`, the role `MINTER` has authority over the following functions:
- function mint()

In the contract `AITECH`, the role `BURNER` has authority over the following functions:
- function burn()
- function burnFrom()

Any compromise to the `MINTER/BURNER` accounts may allow a hacker to take advantage of this authority.

Centralization Related Risks

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.

Unlocked Compiler Version

Ai-Tech - Revised

AITECH.sol

In the contract `GrantorRole`, the role `owner` has authority over the following functions:
- function addGrantor()
- function removeGrantor()
- function transferOwnership()

In the contract `Whitelisted`, the role `grantor` and `owner` has authority over the following functions:
- function addWhitelisted()
- function removeWhitelisted()

In the contract `ERC20Vestable`, the role `grantor` has authority over the following functions:
- function getIntrinsicVestingSchedule()
- function grantVestingTokens()
- function safeGrantVestingTokens()
- function vestingForAccountAsOf()
- function revokeGrant()

In the contract `UniformTokenGrantor`, the role `owner` has authority over the following functions:
- function setRestrictions()
- function setGrantorVestingSchedule()

the role `UniformGrantor` with vesting schedule has authority over the following functions:
- function grantUniformVestingTokens()
- function safeGrantUniformVestingTokens()

In the contract `AITECHToken`, the role `owner` has authority over the following functions:
- function mint()
- function pause()
- function unPause()

In the contract `Migrations`, the role `owner` has authority over the following functions:
- function setCompleted()

Any compromise to these accounts may allow a hacker to take advantage of this authority.

The contract is serving as the underlying entity to interact with third party 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 `ERC20Vestable`, the role `grantor` has authority to grant tokens over the functions `grantVestingTokens` and `safeGrantVestingTokens`.

In the contract `UniformTokenGrantor`, the role `UniformGrantor` with vesting schedule set by owner has authority to grant tokens over the functions `grantUniformVestingTokens` and `safeGrantUniformVestingTokens`. 

However, the contract `UniformTokenGrantor` extends from `ERC20Vestable` and the `UniformGrantor` is also the role `grantor`, which means `UniformGrantor` also can grant tokens without limit of modifier `whenGrantorRestrictionsMet` by function `grantVestingTokens` and `safeGrantVestingTokens`.

Please make sure this situation is allowed to happen.

Discussion about `grantUniformVestingTokens`

The initial supply that are minted to the centralized address `_initialAccount`,  may raise the community's concerns about the centralization issue.

Token Minted To Centralized Address

The contract `ERC20Burnable` of `openzeppelin` is out of our audit scope. However, the contract `AITECHToken` extends from `ERC20Burnable`  and only override the function `burn`. The `burn` is limited by modifier `onlyIfFundsAvailableNow`. Usually, the contract `ERC20Burnable` also has the public function `burnFrom`. If the `burnFrom` is not limited, users still can burn without restriction by following ways:
- one user can call `increaseAllowance` to increase allowance without calling `approve`
- one user can call `approve` many times to allow many other users to burn from his wallet

BurnFrom Without Restriction

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

The `effectiveDaysVested` is miscalculated as it is meaningless to multiply before divide. The `effectiveDaysVested` is still `daysVested`.
```solidity=318
uint32 effectiveDaysVested = ((daysVested * vesting.interval) / vesting.interval);
```

Miscalculation of `effectiveDaysVested`

The contract `ERC20` of `openzeppelin` is out of our audit scope. However, the contract `ERC20Vestable` extends from `ERC20` and only override the function `transfer` and `approve`. The `transfer` is limited by modifier `onlyIfFundsAvailableNow`. Usually, the contract `ERC20` also has the public function `transferFrom` , `increaseAllowance` and `decreaseAllowance`. If these three function are not limited, users still can transfer without restriction by following ways:
- one user can call `increaseAllowance` to increase allowance without calling `approve`
- one user can call `approve` many times to allow many other users to transfer from his wallet

TransferFrom Without Restriction

The `!grant.isActive` not only represents there's no schedule, but also represents the situation that one's `grant` is revoked. As a result, the `amountNotVested` of the revoked account is miscalculated.
```solidity=300
// If there's no schedule, or before the vesting cliff, then the full amount is not vested.
if (!grant.isActive || onDay < grant.startDay + vesting.cliffDuration)
{
    // None are vested (all are not vested)
    return grant.amount;
}
```

Miscalculation of `amountNotVested`

The `NO_WHITLISTED_ROLE` should be `NO_WHITELISTED_ROLE`.
```solidity=18
require(isWhitelisted(account), "WhitelistedRole: NO_WHITLISTED_ROLE ");
```
The `getNumberOfWhitelistedAccont` should be `getNumberOfWhitelistedAccount`.
```solidity=55
function getNumberOfWhitelistedAccont() external view returns (uint256) {
```

Solidus Ai Tech

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

2

0

2

0

0