CertiK reviewed Ice Coin (Ice Coin (ICE)) on 11 Jun 2024: 5 findings, 0 critical; none marked fixed.
The original report was removed from its address (seen 19 Oct 2026).
Trustblock does not review code.
Statuses are the security firm’s own, from its report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 1 | 0 | 0 |
| Medium | 0 | 0 | 0 |
| Low | 4 | 0 | 0 |
5% of the ICE tokens are sent to the contract owner. 80% of the ICE tokens are used for pool liquidity, and LP tokens are sent to the contract owner after `enableTrading()`. This is a centralization risk because the owner can distribute tokens or remove liquidity 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 `disableClaim()` function transfers the entire balance of tokens held by the `address(NFT)` to a burn address (`address(0xdead)`): ```solidity=1158 _transfer(address(NFT), address(0xdead), balanceOf(address(NFT))); ``` This action is intended to prevent further token claims by NFT holders. However, the implemented `_transfer()` function used for this purpose does not reduce the total supply of the ICE tokens, as it merely transfers the tokens to the burn address without decrementing the total supply counter. This can lead to a discrepancy between the actual circulating supply and the reported total supply.
The transaction may be charged fees, so the max holding of the receiver should be the sum of the tokens held and the amount received from the transfer. The fees should not be included in the max holding. ```solidity=1250 require( amount + balanceOf(to) <= maxWallet, "Max wallet exceeded" ); ``` - Max holding is checked. ```solidity=1295 amount -= fees; ``` - Receiving amount is adjusted. ```solidity=487 _balances[recipient] = _balances[recipient].add(amount); ``` - Balance is increased by the adjusted amount.
The allowance is approved to the router based on the token swapping amount in the swapTokensForEth function. Therefore, approving the maximum allowance to the router is redundant and unnecessary.
The contract constructor excludes the DEX router from the maximum wallet holding restriction: ```solidity=1103 excludeFromMaxWallet(address(_uniswapV2Router), true); ``` This exclusion is unnecessary as the DEX router is responsible for transferring tokens from traders directly to the DEX pair, and does not hold tokens itself. The exclusion should be applied to the DEX pair instead, which is the entity that actually holds the tokens after trades.
| Address | Chain | Source code |
|---|---|---|
| 0x4b4c…cb2c0x4b4c8abe2dc873f04068075908f4719554b2cb2c | Chain: Ethereum | 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