Velar security record

Avoid floating pragmas for non-library contracts.While floating pragmas make sense for libraries to allow them to be included with multiple different versions of applications, it may be a security risk for application implementations. A known vulnerable compiler version may accidentally be selected or security tools might fall back to an older compiler version, ending up checking a different EVM compilation that is ultimately deployed on the blockchain. It is recommended to pin to a concrete compiler version.

There is no check whether startTimestamp is greater than block.timestamp in the constructor. Therefore, it is possible for administrators to accidentally create a vesting schedule that starts in the past without noticing it. When this happens, the vesting amount can be withdrawn, and the time limit will not be enforced.

According to the protocol’s whitepaper, the Velar token is intended to be used in the entire velar ecosystem, including Governance, Staking, etc.In that case, integrating the Velar token might create much more redundant complexity in calculations in future smart contract developments. It will become more prone to rounding issues if not handled properly. Here 1 token would be 1*(10**6) = 1000000000 Wei. It may happen that any other smart contract uses/accepts this token for some reason. That smart contract calculates the token amount sent by the user assuming its 18 decimal token, which can result in unwanted outcomes. Eg:  care needs to be taken in this type of scenario. User sends 1 token (“1*(10**6)” in this case) to a smart contract. The smart contract which accepts this token checks the token amount sent by User which was 1*(10**8) = 100000000 While calculating amount sent by the User, smart contract uses 18 decimals and expects 1 token sent to be 1*(10**18) = 1000000000000000000 In this case this condition will fail since token amount sent by User is 1000000 i.e 1*(10**6) and not 1*(10**18)

Floating pragma should only be used when a contract is intended for consumption by other developers.Locking the pragma helps ensure that contracts are not accidentally deployed using, for example, the latest compiler, which may have higher risks of undiscovered bugs.

The contract uses literals with many digits, potentially leading to human error or misleading, particularly when the number of zeros is large. However, in the provided smart contract code, the _mint function is called with a clear multiplication of two numbers, '1000000000' and '10**decimals()'.  Since the decimals function overrides the standard 18 decimals with 6, the actual number minted is '1000000000 * 10**6', which is intentional and correct for the token's intended design. There is no inherent vulnerability in having a large number of tokens; it is a design decision that affects the granularity and distribution of the token.

The contract inherited a couple of Interfaces intended to aid achieve the safety creation of ERC20 token. However, there are some Interfaces that were left unused in the contract.