Diamante security record

The `mint()` function in the `Diam` contract does not fully utilize the EIP712 standard and the ECDSA library already imported through the `ERC20Permit` inheritance, leading to potential signature malleability issues and a lack of distinction between signatures provided for the `mint()` and `permit()` functions. The `mint()` function should construct a structhash for the `mint()` function and use `ECDSA.recover()` for signature verification, similar to the methods used in `permit()` within `ERC20Permit`. An attacker could exploit the lack of signature malleability checks to forge signatures and mint tokens without authorization. The current implementation of the `mint()` function uses a manual construction of the message digest and `ecrecover` for signature verification. This approach lacks the security checks provided by `ECDSA.recover()` and does not fully employ methods recommended in [EIP-712](https://eips.ethereum.org/EIPS/eip-712).

The function `ecrecover()` can return zero, and this can lead to a vulnerability as the address of the signer is not checked properly. By default, this issue is impossible to happen because of the below validation, and the `owner()` will not be `address(0)` in the known blockchains. ```solidity=60 require(signer == owner(), "DW02"); ``` This finding is to remind that the team should check if `address(0)` account of the blockchain, on which the `Diam` contract will be deployed, is held by any user on that blockchain. If ownership is ever renounced however, minting is immediately vulnerable to anyone minting any value. This is not ideal because the likely intention behind renouncing ownership would be to make it impossible to mint more tokens.

The `SafeMath` library is used unnecessarily. With Solidity compiler versions 0.8.0 or newer, arithmetic operations will automatically revert in case of integer overflow or underflow. ```solidity=9 using SafeMath for uint256; ``` - `SafeMath` library is used for `uint256` type in `Diam` contract.

As a general practice, use of `abi.encodePacked` is discouraged, since it is susceptible to hash collisions in some instances where dynamically-sized inputs are used consecutively.