DIGIKA security record

As per the design, there's a cooldown period for transferring tokens from an account, initially set at 15 seconds. This prevents the sender from making continuous transfers, which could cause unexpected issues. For instance, if the token is listed on an exchange like `Uniswap`, transferring tokens from the pool to a target address requires a 15-second wait when users purchase tokens or remove liquidity. Frequent transactions could result in failures due to this delay. ```solidity function _transfer(address sender, address recipient, uint256 amount) internal virtual override { ... // Anti-MEV : impose un cooldown entre les transactions de la même adresse. require( block.timestamp >= lastTransactionTime[sender] + transactionCooldown, "Anti-MEV cooldown" ); lastTransactionTime[sender] = block.timestamp; ... } ```

According to the design, when an account does not meet specific conditions and the fee is non-zero, a transaction fee is applied. ```solidity bool skipFee = (sender == address(this) || recipient == address(this) || isFeeExempt[sender] || isFeeExempt[recipient]); ```

The `ERC20Mock` and `Lock` contracts appear to lack meaningful functionality, as they do not offer any significant features.

The codebase contains multiple Solidity versions, which can lead to unexpected behavior, potential vulnerabilities, difficulties in maintaining the code, and inconsistencies in the execution of the smart contract. Using different versions may also result in increased complexity during code auditing, as different security features and bug fixes are present in different versions of the compiler. Versions used: `^0.8.0`, `^0.8.1`, `^0.8.18` ```solidity=1093 pragma solidity ^0.8.0; ``` `^0.8.0` is used in DGKToken.sol file. ```solidity=1093 pragma solidity ^0.8.0; ``` ```solidity=700 pragma solidity ^0.8.1; ``` `^0.8.1` is used in DGKToken.sol file. ```solidity=700 pragma solidity ^0.8.1; ``` ```solidity=1331 pragma solidity ^0.8.18; ``` `^0.8.18` is used in DGKToken.sol file. ```solidity=1331 pragma solidity ^0.8.18; ```

According to the design, blacklisted addresses cannot receive or send tokens. ```solidity function _transfer(address sender, address recipient, uint256 amount) internal virtual override { require(!paused, "Token is paused"); require(!blacklisted[sender], "Sender blacklisted"); require(!blacklisted[recipient], "Recipient blacklisted"); ... } ``` However, there is no blacklist check for the target address when minting tokens, which may result in these minted tokens being non-transferable.

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

It is not recommended to use Solidity's `transfer()` and `send()` functions for transferring native tokens, since some contracts may not be able to receive the funds. Those functions forward only a fixed amount of gas (2300 specifically) and the receiving contracts may run out of gas before finishing the transfer. Also, EVM instructions' gas costs may increase in the future. Thus, some contracts that can receive now may stop working in the future due to the gas limitation. ```solidity=1361 owner.transfer(address(this).balance); ``` - `Lock.withdraw` uses `transfer()`.