Welthee

In the contract `InsuredTokenSale` 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 withdraw all the tokens owned by the contract from any `ERC20` contract, then transfer these funds from the `_owner` account to their own account. 

The linked functions attempt to transfer `ERC20` tokens out of this contract to EOA's and vesting contracts. This contract never explicitly receives tokens and as a result, it will most likely revert during balance checks and token transfers.

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

Within the current contract, there is no distinction between the different blockchains supported by the `Welthee` project. If the signer signed a message on one chain (e.g. Ethereum), and accidentally leaks the message, the message would be valid for a similar transaction of a chain with the same encryption method (e.g. BSC). For example, if the signer signed a message using `encodeClaimHash(ClaimParam memory claimInfo)` on Ethereum and the same `claimInfo.investor` and `claimInfo.id` exists on BSC, the attacker can reuse this signed message to maliciously claim tokens with `claim()` on BSC.

Neither of the `if` statements in the function `isAvailableToClaim()` check whether `orders[investor][id].insuranceExpiryTime` is equal to `block.timestamp`. The order will have neither a claim type of `INSURANCE` nor `TOKEN` in this case even if the order has not been claimed before.

```solidity=4 library AddressesArray { ``` - The library `AddressesArray` is included in the audit scope but is never used by the other contracts.