IceBull Info
Bears chased him. Exchanges collapsed. Billions disappeared. IceBull just kept skiing. After surviving every crypto disaster the market could invent, there’s only one thing left to do… send it.
TrustNet Score
The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.
Real-Time Threat Detection
Real-time threat detection, powered by Cyvers.io,
is currently not
activated
for this project.
This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks.
For more information, click here.
Security Assessments
Summary and Final Words
No crucial issues found
The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.
Contract owner cannot mint
It is not possible to mint new tokens.
Contract owner cannot blacklist addresses.
It is not possible to lock user funds by blacklisting addresses.
Contract owner cannot set high fees
The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.
Token transfer can be locked
Owner can lock user funds with owner functions.
Token cannot be burned
There is no burning within the contract without any allowances
Ownership is not renounced
The owner retains significant control, which could potentially be used to modify key contract parameters.
Contract is not upgradeable
The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.
Scope of Work
This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.
The auditing process consists of the following systematic steps:
- Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
- Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
- Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
- Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
- Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
- Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
- Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.
A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.
Final Words
The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.
Smart Contract Analysis Statement
Contract Analysis
The IceBull contract implements an ERC20 token with a fixed supply that is minted once at deployment, a burn capability available to every holder, and a single one-way launch switch that keeps trading against registered liquidity pairs closed until the owner opens the market. There are no taxes, no fees, no reflection, no rebasing, no blacklist, and no upgrade mechanism. Ordinary wallet-to-wallet transfers are always allowed, and once trading is enabled the restriction is removed permanently. The version of the contract that is live on-chain was reproduced exactly from the reviewed source, and at the time of review trading had not yet been enabled.
Ownership Privileges
The ownership of the contract has been retained by a single externally owned account that, at the time of review, had not been renounced and was not a multi-signature wallet. The owner retains full privileges including:
- Enable public trading once, in a way that cannot be reversed
- Register or de-register the addresses that are treated as trading pairs
- Burn tokens from the owner's own balance
- Transfer ownership of the contract or give it up entirely
- The owner cannot create new tokens after deployment, because the supply is fixed
- The owner cannot charge any fee or tax on transfers
- The owner cannot freeze, seize, or blacklist the balances of other holders once the market is open
- The owner cannot change or upgrade the contract logic, which is immutable
The most important point for holders and prospective buyers is that the privileged powers are concentrated in the pre-launch phase. After trading is enabled the transfer gate no longer has any effect, and the remaining owner actions cannot touch other people's balances. The main consideration is therefore trust in the owner around launch timing and around the supply the owner already holds, since at deployment the owner holds the entire supply. Moving ownership to a multi-signature wallet and adding a delay before administrative changes take effect would reduce this concentration of control.
Security Features
The contract implements several positive security features:
- It is built on widely used, audited token and ownership components, and the deployed code matches the reviewed source exactly
- It relies on checked arithmetic and reverts on any overflow or underflow, and the supply can only ever decrease through burning
- It makes no external calls and exposes no token callbacks, which removes the usual reentrancy exposure
- Wallet-to-wallet transfers are always permitted and the trading restriction is lifted permanently once enabled, so holders cannot be locked in, and there is no fee, blacklist, or minting power that could be abused after launch
Note - This Audit report consists of a security analysis of the IceBull smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the IceBull team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.
Files and details
Findings and Audit result
medium Issues | 2 findings
Resolved
#1 medium Issue
Centralized control and single point of failure
The prior design concentrated all administrative power in a single externally owned account that decided launch timing, managed the trading-pair registry, and held the full supply at deployment. The new design has no owner and no administrative functions, so this concentration of power no longer exists.
Resolved
#2 medium Issue
Owner can selectively restrict arbitrary addresses before launch
Previously an address could be flagged so that, while trading was disabled, it could not send to or receive from ordinary holders, which behaved like a removable pre-launch blacklist. The new contract has no flagging mechanism and no transfer gate, so no address can be selectively restricted.
low Issues | 2 findings
Resolved
#1 low Issue
Ownership transfer is single-step
The earlier concern was that ownership changed hands in a single immediate step, so a mistaken transfer could not be undone. With no owner role in the new contract, this footgun no longer exists.
Resolved
#2 low Issue
Renouncing ownership before launch permanently disables trading
The earlier concern was that renouncing ownership while trading was disabled would permanently prevent enabling it. The new contract has neither an owner nor a trading gate, so this cannot happen.
optimization Issues | 4 findings
Resolved
#1 optimization Issue
Redundant storage read in the transfer hook
The earlier hook read a privileged address from storage on every pre-launch transfer, including paths where it was unused. The hook has been deleted entirely.
Resolved
#2 optimization Issue
Combined condition could be split for minor savings
The earlier note concerned a combined negated condition in the transfer hook that could be nested for a negligible saving. The hook and the condition no longer exist.
Resolved
#3 optimization Issue
Redundant timestamp in event payload
The earlier note concerned a launch event that stored the block timestamp already available from the containing block. That event no longer exists.
Acknowledged
#4 optimization Issue
Token name and symbol are stored on-chain but never read
The base token constructor is invoked with the name and symbol, which writes both strings to contract storage. The contract also overrides the name and symbol getters to return hard-coded string literals, so the stored values are never read. The result is deployment gas spent writing two strings that no code path uses, and two independent definitions of the same metadata that must be kept in agreement by hand.
informational Issues | 11 findings
Acknowledged
#1 informational Issue
Floating compiler version
The source still uses a floating compiler range that allows any recent minor release at or above the stated version. A future recompilation can therefore pick a different compiler and produce different bytecode. This item was not addressed in the rewrite and both static analyzers flagged it again.
Resolved
#2 informational Issue
Unreachable zero-address check in the constructor
In the prior contract an inherited initializer ran first with the same address and rejected the zero address, which made the constructor's own zero-address check unreachable dead code. In the new contract nothing runs before the check, so it is reachable, although it overlaps with the base mint routine which also rejects a zero receiver.
Acknowledged
#3 informational Issue
Maximum supply constant is really a fixed initial supply
The constant is still named and described as a maximum supply, but it is only the amount minted once in the constructor. Nothing enforces it as an ongoing ceiling, and because tokens can be burned the circulating amount can only fall below it. The naming may lead integrators to assume a minting capability up to this value exists, which it does not.
Resolved
#4 informational Issue
Duplicate burn interface and event
The prior contract had an owner-only burn helper that duplicated the inherited burn capability and emitted a custom event alongside the standard transfer-to-zero event, which could be double-counted by indexers. The helper and its event no longer exist.
Acknowledged
#5 informational Issue
Standard ERC20 approval race condition (standards caveat)
The approval method retains the standard overwrite behavior and therefore the well-known race in which a spender can use both the old and the new allowance if a change is front-run. This is inherent to the standard and not specific to this contract. It is unchanged by the rewrite.
Resolved
#6 informational Issue
Trading activation can be front-run by snipers
The prior contract exposed a public transaction that switched trading on, which automated buyers could observe in the mempool and act on. With trading always enabled from deployment, no such transaction exists.
Resolved
#7 informational Issue
Pre-launch gate is a soft control for the general population
The prior note described how the pre-launch restriction only applied to addresses the owner had registered, so unflagged holders could still transfer freely. With no gate at all, this soft-control behavior no longer applies.
Acknowledged
#8 informational Issue
Large numeric literal is a readability preference
The supply constant is written as a grouped integer multiplied by a power of ten. Whether it is written this way or in scientific notation, the compiler folds it to the same value, so there is no effect on behavior, bytecode, or gas. The point is purely about readability and is unchanged by the rewrite.
Acknowledged
#9 informational Issue
No recovery path for assets sent to the contract
The contract still has no function to move out assets that reach its own address and no way to accept or withdraw native currency. Tokens sent to the contract address, or native currency force-sent to it, are permanently stuck. This has no effect on normal balances and is now an intentional consequence of the permissionless, ownerless design rather than an oversight.
Acknowledged
#10 informational Issue
Forwarding-only overrides duplicate inherited behavior
Several functions are overridden only to forward to the inherited implementation with no added logic, including the supply, balance, transfer, transfer-from, allowance, approve, and decimals functions. They do not change behavior and are equivalent to inheriting the base functions directly, so they add bytecode and review surface without benefit.
Acknowledged
#11 informational Issue
Deployment target opcode support is left unpinned
With the compiler version and EVM target left unpinned, the generated bytecode uses the zero-push opcode introduced as the default in recent compilers. On chains that do not support that opcode the deployment would revert. This is a deployment-target consideration surfaced by static analysis and tied to the floating pragma.