Iskra - Audit for Token (Part 1)

In the contract `MultiToken` 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 and: - transfer the ownership to an address they control; - change the URI; - pause or unpause the contract (if `MultiToken` is deployed as pausable); - grant or revoke the capacity to mint tokens from any address; - grant or revoke the capacity to burn tokens from any address (if `MultiToken` is deployed as pausable);  ----- ----- In the contract `UtilityToken` 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 and: - transfer ownership to an address they control; - grant or revoke the minter role from any address.  ---- In the contract `UtilityToken` the role `minters` has authority over the functions shown in the diagram below. Any compromise to the `minters` account may allow the hacker to take advantage of this authority and : - mint any amount of tokens to any address; - burn tokens they own or are approved to handle.  ----- ----- In the contract `ItemNFT` 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 and : - grant or revoke the capacity to mint tokens to any address; - grant or revoke the capacity to burn tokens to any address (if the contract has been deployed as burnable); - change the URI;  ----- ----- In the contract `Vesting` 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 and: - transfer the ownership to an address they control; - prepare a new vesting; - set the start of a vesting; - revoke the vesting and send the tokens to an address they control.  ---- In the contract `Vesting` the role `beneficiary` has authority over the functions shown in the diagram below. Any compromise to the `beneficiary` account may allow the hacker to take advantage of this authority and: - change the beneficiary address to an address they control; - claim tokens vested; 

`Vesting` is an upgradeable contract, the owner can upgrade the contract without the community's commitment. If an attacker compromises the account, he can change the implementation of the contract and drain tokens from the contract.

All tokens are sent to the contract deployer when deploying the contract. This is a potential centralization risk as the deployer can distribute tokens without the consensus of the community.

The function `ERC721._mint()` updates the receiver balance as follows: ```solidity unchecked { // Will not overflow unless all 2**256 token ids are minted to the same owner. // Given that tokens are minted one by one, it is impossible in practice that // this ever happens. Might change if we allow batch minting. // The ERC fails to describe this case. _balances[to] += 1; } ``` In theory, the function `safeMintBatch()` could cause an overflow.

A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects. *This finding is considered minor because the reentrancy only causes out-of-order events.*

In `Vesting.sol`, the functions `prepare()` and `claim()` transfer specific amounts of tokens. However, in the linked locations the amount is multiplied by 1e18 in the transfer functions. The functions `transfer()` and `transferFrom()` from an ERC20 are already supposed to work without multiplying the amount by the decimals.

The contract is serving as the underlying entity to interact with one third-party protocol. 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=34 IERC20 public token; ``` - The contract `Vesting` interacts with a third-party contract with `IERC20` interface via `token`.