DeepLink security record

In the contract `MultiSigTimeLock`, the role `_signer` has authority over the functions shown in the diagram below. Any compromise to the `_signer` account may allow the hacker to take advantage of this authority and remove a signer from the signers list, create a new proposal with execution delay, approve a proposal, revoke approval for a proposal, update required approval count, add a new signer, authorize upgrade for a new implementation address, and update the minimum delay seconds.  ---- In the contract `Token`, the role `timeLock` has authority over the functions shown in the diagram below. Any compromise to the `_multisigtimelockcontract` account may allow the hacker to take advantage of this authority and disable lock permanently, set the mint amount for a minter, remove lock transfer admin status, update lock duration for a wallet address, add transfer lock admin address, and enable lock permanently.  In the contract `Token`, the role `lockTransferAdmins` has authority over the functions shown in the diagram below. Any compromise to the `lockTransferAdmins` account may allow the hacker to take advantage of this authority and transfer and lock tokens for a specified duration.  In the contract `Token`, the role `minter` has authority over the function below. Any compromise to the `minter` account may allow the hacker to take advantage of this authority and mint tokens to any accounts. - `mint()`

In the contracts `Token` and `MultiSigTimeLock`, the role `canUpgradeAddress` of the `Token` contract and the role `canUpgradeAddress` of the `MultiSigTimeLock` contract have the authority to update the implementation contract behind the `Token` and `MultiSigTimeLock` contracts. Any compromise to these accounts may allow a hacker to take advantage of this authority and change the implementation contract, which is pointed by proxy, and therefore execute potential malicious functionality in the implementation contract.

All of the **DLC** tokens are sent to the contract deployer or one or several externally-owned account (EOA) addresses. This is a centralization risk because the deployer or the owner(s) of the EOAs can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.

**Address 0xD610Be30b06A3828A27D608a38F1E85faAFdEDcC:** In the contract `DeepLink`, 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 claim stuck tokens to owner, update wallet lock block, disable the lock permanently, transfer and lock tokens.  In the contract `Ownable`, 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, renounce ownership.  ----- **Address 0x0e933b304C9585B35546FE0aE6D0B01A72f0FdCF:** In the contract `DeepLink` 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 enable trading, enable/disable addresses from transferring tokens before trading enabled.  In the contract `Ownable` 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, renounce ownership. 

All of the DLC tokens are sent to the corresponding contract owner. This is a centralization risk because the owners can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.

The `transferAndLock` function adds a lock entry for each user, ensuring that the total number of entries does not exceed 100 to avoid potential DoS on gas: ```solidity require(infos.length < 100, "Too many lock entries"); // Limit lock entries ``` However, assigning this role to non-admin users could pose a risk of a Denial-of-Service (DoS) attack on the lock mechanism that occupies all entries with redundant entries if a user becomes malicious.

The `Token` contract inherits from `ERC20BurnableUpgradeable`, allowing users to burn tokens through the `burn` and `burnFrom` functions. As a result of token burning, the actual token supply can decrease below the `maxSupply`. Similarly, the user may burn extra tokens compared with the available amount at the time.

The contract has a `receive()` function or payable functions, making it able to receive native tokens. However, it does not have a function to withdraw the funds, which can lead to permanently locked tokens within the contract. ```solidity=675 receive() external payable {} ```

State variables that never change should be declared as `constant` to save gas. ```solidity=640 address private DEAD = 0x000000000000000000000000000000000000dEaD; ``` - `DEAD` should be declared `constant`.

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=769 payable(msg.sender).transfer(address(this).balance); ``` - `DeepLink.claimStuckTokens` uses `transfer()`.