CertiK reviewed DeepLink on 26 Sep 2024: 6 findings, 0 critical; none marked fixed.
Report hosted on skynet.certik.com.
Trustblock does not review code.
Statuses are the security firm’s own, from its report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 2 | 0 | 0 |
| Medium | 0 | 0 | 0 |
| Low | 4 | 0 | 0 |
**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 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()`.
The linked variable assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.
| Address | Chain | Source code |
|---|---|---|
| 0x0e93…fdcf0x0e933b304c9585b35546fe0ae6d0b01a72f0fdcf | Chain: Ethereum | Source code: Verified source |
| 0xd610…edcc0xd610be30b06a3828a27d608a38f1e85faafdedcc | Chain: BNB Chain | Source code: Verified source |
1,044 projects reviewed · 1,375 reports · latest May 2025
See CertiK’s auditsSomething wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us