Quantum Audit Logo

Is ICP Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

ICP ICP
0x00f3…8917
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The Token contract implements a standard ERC20 token with Ownable and ERC20Permit extensions. It includes custom burn and mint functionalities. The audit identified a High severity issue related to incorrect ETH withdrawal logic, and several Medium severity issues concerning unchecked external calls and inconsistent ETH handling in batch minting. Owner privileges are significant, allowing for centralized control over token supply and contract funds.

1 High2 Medium1 Low1 Informational
Volume 24h
$137.7K
Liquidity
$493.9K
Price
$2.5500
Token Age
1y
Top 10 Holders
59.0%

Security Findings

1 High2 Med1 Low1 Info
High

Incorrect `withdrawEth` Logic Leads to Locked Funds

H-01The `withdrawEth` function contains an inverted `require` condition: `require(amount >= address(this).balance, "Balance too low");`. This condition incorrectly checks if the requested `amount` is greater than or equal to the contract's balance. As a result, the function will only succeed if `amount` is exactly equal to `address(this).balance`, or it will revert if `amount` is less than the balance. If `amount` is greater than the balance, the `require` passes, but the subsequent `transfer` call will revert due to insufficient funds. This effectively prevents the owner from withdrawing partial amounts of ETH and can lead to funds being locked in the contract if the owner attempts to withdraw…
IssueThe `withdrawEth` function contains an inverted `require` condition: `require(amount >= address(this).balance, "Balance too low");`. This condition incorrectly checks if the requested `amount` is greater than or equal to the contract's balance. As a result, the function will only succeed if `amount` is exactly equal to `address(this).balance`, or it will revert if `amount` is less than the balance. If `amount` is greater than the balance, the `require` passes, but the subsequent `transfer` call will revert due to insufficient funds. This effectively prevents the owner from withdrawing partial amounts of ETH and can lead to funds being locked in the contract if the owner attempts to withdraw…
FixCorrect the `require` condition to `require(amount <= address(this).balance, "Amount exceeds contract balance");` to allow the owner to withdraw any amount up to the contract's current ETH balance.
StatusUnresolved
Medium

Unchecked `call` Return Values and Low Gas Limit in Mint Functions

M-01The `mint` and `batchMint` functions perform external ETH transfers using `to.call{value: msg.value, gas: 2300}("")` and `recipients[i].call{value: ethAmounts[i], gas: 2300}("")` respectively. The `success` boolean returned by these `call` operations is not checked. If an external call fails (e.g., due to the recipient being a contract that reverts, or running out of gas), the transaction will still proceed, leading to a situation where the ETH was not transferred but the caller believes it was. Additionally, the fixed gas limit of 2300 is very low and might be insufficient for complex recipient contracts, causing legitimate transfers to fail.
IssueThe `mint` and `batchMint` functions perform external ETH transfers using `to.call{value: msg.value, gas: 2300}("")` and `recipients[i].call{value: ethAmounts[i], gas: 2300}("")` respectively. The `success` boolean returned by these `call` operations is not checked. If an external call fails (e.g., due to the recipient being a contract that reverts, or running out of gas), the transaction will still proceed, leading to a situation where the ETH was not transferred but the caller believes it was. Additionally, the fixed gas limit of 2300 is very low and might be insufficient for complex recipient contracts, causing legitimate transfers to fail.
FixAlways check the `success` boolean returned by external `call` operations and revert if `success` is false. Consider increasing the gas limit for external calls if the recipient is expected to be a contract with complex fallback logic, or remove the gas limit entirely if reentrancy is not a concern (which it is not here, as ETH is sent out after internal state changes). For example: `(bool success,) = to.call{value: msg.value}(''); require(success, 'ETH transfer failed');`
StatusUnresolved
Medium

Inconsistent ETH Handling in `batchMint` Function

M-02The `batchMint` function's logic for handling `msg.value` and `ethAmounts` is inconsistent. If `msg.value > 0`, the function iterates through `ethAmounts` to transfer ETH to recipients. However, there is no check to ensure that `msg.value` matches the sum of `ethAmounts`. If `msg.value` is greater than the sum of `ethAmounts`, the excess ETH will remain stuck in the contract. If `msg.value` is less than the sum of `ethAmounts`, some `call` operations will revert due to insufficient balance, leading to partial failures and an inconsistent state where some recipients receive ETH and others do not, while all tokens might still be minted.
IssueThe `batchMint` function's logic for handling `msg.value` and `ethAmounts` is inconsistent. If `msg.value > 0`, the function iterates through `ethAmounts` to transfer ETH to recipients. However, there is no check to ensure that `msg.value` matches the sum of `ethAmounts`. If `msg.value` is greater than the sum of `ethAmounts`, the excess ETH will remain stuck in the contract. If `msg.value` is less than the sum of `ethAmounts`, some `call` operations will revert due to insufficient balance, leading to partial failures and an inconsistent state where some recipients receive ETH and others do not, while all tokens might still be minted.
FixImplement a clear strategy for `msg.value` in `batchMint`. Either require `msg.value` to be exactly equal to the sum of `ethAmounts` (e.g., by calculating the sum and comparing), or explicitly define how excess or insufficient `msg.value` should be handled (e.g., refund excess, revert on insufficient).
StatusUnresolved
Low

High Centralization of Owner Privileges

L-01The contract grants significant power to the `owner` address, including the ability to mint an unlimited supply of tokens to any address, update the `minAmount` for burning, and withdraw all ETH from the contract. While this is a common pattern for `Ownable` contracts, it introduces a high degree of centralization and reliance on the owner's integrity. A compromised owner key could lead to severe consequences, such as arbitrary token minting or draining of contract funds.
IssueThe contract grants significant power to the `owner` address, including the ability to mint an unlimited supply of tokens to any address, update the `minAmount` for burning, and withdraw all ETH from the contract. While this is a common pattern for `Ownable` contracts, it introduces a high degree of centralization and reliance on the owner's integrity. A compromised owner key could lead to severe consequences, such as arbitrary token minting or draining of contract funds.
FixConsider implementing a multi-signature wallet for the owner address to reduce the risk of a single point of failure. For critical operations like minting or updating core parameters, explore adding time-locks or a governance mechanism to introduce delays and community oversight.
StatusUnresolved
Info

Redundant Burn Functions

I-01The contract defines four separate `burn` functions (`burn1`, `burn2`, `burn3`, `burn4`) that are identical in functionality except for the number of `bytes32` data parameters they accept. This design choice leads to code duplication and unnecessary complexity without providing distinct functional benefits that couldn't be achieved with a single, more flexible `burn` function (e.g., accepting a `bytes` array or a single `bytes` parameter).
IssueThe contract defines four separate `burn` functions (`burn1`, `burn2`, `burn3`, `burn4`) that are identical in functionality except for the number of `bytes32` data parameters they accept. This design choice leads to code duplication and unnecessary complexity without providing distinct functional benefits that couldn't be achieved with a single, more flexible `burn` function (e.g., accepting a `bytes` array or a single `bytes` parameter).
FixConsolidate the multiple `burn` functions into a single function that accepts a dynamic `bytes` array or a single `bytes` parameter for arbitrary data. This would reduce code duplication, improve readability, and simplify maintenance.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract leverages well-audited OpenZeppelin libraries for ERC20, Ownable, and ERC20Permit functionalities (7.2 Code Security). However, a critical flaw exists in the `withdrawEth` function, which prevents proper withdrawal of contract ETH due to an inverted `require` condition (7.8 Operations). Additionally, the `mint` and `batchMint` functions perform external ETH transfers without checking the success status of the `call` and use a low gas limit, potentially leading to failed transfers or stuck funds (7.2 Code Security).

GovernanceHigh1/10

The contract utilizes the Ownable pattern, granting the deployer significant control over key functions such as minting, updating `minAmount`, and withdrawing ETH (7.3 Access Control). This centralization of power means the owner can mint an unlimited supply of tokens and manage all ETH held by the contract (7.4 Economic). While this is a common design for initial token deployments, it introduces a single point of failure and reliance on the owner's integrity.

UpgradesHigh3/10

The contract is not designed with an upgrade mechanism (e.g., proxy pattern), which inherently avoids the complexities and potential security risks associated with upgradeable contracts (7.7 Upgrades). This fixed architecture ensures immutability post-deployment. However, any future bug fixes or feature enhancements would necessitate a new contract deployment and a migration process.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

59.0% in top 10
31.1% in wallets27.9% in contracts
Effective Concentration42.2%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$498.0K across 2 pairs
Uniswap v3WETHanalysed$493.9K99.2%Uniswap v3WETH$4.1K0.8%

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0xb5b0…8fd8
Unlocked LP Held By
0x0d56…4c11

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

9 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (59.0% total → 42.2% effective; 31.1% in EOAs, 27.9% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Related Audits

6 more on the record
DAPPOS (DOS)Critical RiskPancakeSwap (CAKE)Critical RiskEveripedia IQ (IQ)Critical RiskThreshold Network Token (T)Critical RiskPayPal USD (PYUSD)Critical RiskOpenServ (SERV)High Risk

Would You Like a More Detailed Audit of ICP?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit