Quantum Audit Logo
Launch App

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

Is ICP Safe?

Ethereum
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades3/10Checks passed2 of 5Findings1 High · 2 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The Token contract implements a standard ERC20 token with Ownable and ERC20Permit extensions.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
27.9%Contracts31.1%Wallets41.0%Everyone else
27.9%Contracts31.1%Wallets41.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
59.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking27.9%
  • Walletsanonymous holders, free to sell31.1%
  • Everyone elsethe rest of the supply41.0%
Effective concentrationwhat the score reads42.2%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$498.0K across 2 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$493.9KShare of depth99.2%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x0d56…4c11

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

Security Findings

1 High2 Medium1 Low1 Info
High

Incorrect withdrawEth Logic Leads to Locked Funds

The 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…H-01

Issue

The 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…

Fix

Correct 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.

Status

Unresolved

Medium

Unchecked call Return Values and Low Gas Limit in Mint Functions

The 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.M-01

Issue

The 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.

Fix

Always 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');`

Status

Unresolved

Medium

Inconsistent ETH Handling in batchMint Function

The 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.M-02

Issue

The 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.

Fix

Implement 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).

Status

Unresolved

Low

High Centralization of Owner Privileges

The 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.L-01

Issue

The 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.

Fix

Consider 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.

Status

Unresolved

Info

Redundant Burn Functions

The 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).I-01

Issue

The 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).

Fix

Consolidate 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.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical6/10Medium risk

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).

Governance1/10High risk

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.

Upgrades3/10High risk

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.

Final RecommendationWhat to do about this score

It is crucial to immediately address the withdrawEth function's logic to prevent funds from being permanently locked.

Implement robust error handling for all external calls, specifically checking the success boolean and considering higher gas limits where appropriate. Review the batchMint function's ETH handling to ensure consistency and prevent stuck funds. Consider the implications of centralized owner control and explore options for multi-signature ownership or time-locks for critical operations if decentralization is a future goal.

Contract & Record

1 audit on record
TypeToken
NetworkEthereum
Token age1y
Contract0x00f3…8917
Deployer0xb5b0…8fd8
Badge for your website
ICP security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202671High
  2. Aug 11, 202659Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
DAPPOSDOS · Ethereum71HighPancakeSwapCAKE · Ethereum71HighEveripedia IQIQ · Ethereum71HighThreshold Network TokenT · Ethereum71HighFARM Reward TokenFARM · Ethereum71HighMotoswapMOTO · Ethereum71High

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 Is this your token? Publish your own audit on this page