Quantum Audit Logo
Launch App

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

Is ICP Safe?

Base
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 · 1 Medium · 1 Low · 2 Info5
SummaryAI Copilot

The Token contract implements an ERC20 token with custom burning, minting, and ETH withdrawal functionalities, leveraging OpenZeppelin's ERC20, Ownable, and ERC20Permit standards.

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 = 99.1%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 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% (73.2% total → 34.1% effective; 8.1% in EOAs, 65.1% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.1% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 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
65.1%Contracts8.1%Wallets26.8%Everyone else
65.1%Contracts8.1%26.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
73.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking65.1%
  • Walletsanonymous holders, free to sell8.1%
  • Everyone elsethe rest of the supply26.8%
Effective concentrationwhat the score reads34.1%
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$621.1K across 4 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$594.9KShare of depth95.8%
Top-1 Unlocked Holder99.1%
Top-3 Unlocked100.0%
Unlocked LP held by
0x7d27…fd550x7a0c…6154

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

Security Findings

1 High1 Medium1 Low2 Info
High

Critical Logic Error in withdrawEth Function

The withdrawEth function contains a logical error in its require statement: 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 total ETH balance. As a result, the owner can only successfully withdraw the *exact total balance* of the contract, or attempts to withdraw more will revert due to insufficient funds during the transfer call. This prevents the owner from withdrawing partial amounts of ETH, severely hindering fund management.H-01

Issue

The withdrawEth function contains a logical error in its require statement: 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 total ETH balance. As a result, the owner can only successfully withdraw the *exact total balance* of the contract, or attempts to withdraw more will revert due to insufficient funds during the transfer call. This prevents the owner from withdrawing partial amounts of ETH, severely hindering fund management.

Fix

Change the require statement 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 Return Value from External Calls

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. While the success boolean is assigned, it is not checked (success;). If the external call fails (e.g., the recipient contract reverts or runs out of the provided gas), the transaction will continue without reverting, potentially leading to a loss of ETH or an inconsistent state where tokens are minted but ETH is not transferred.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. While the success boolean is assigned, it is not checked (success;). If the external call fails (e.g., the recipient contract reverts or runs out of the provided gas), the transaction will continue without reverting, potentially leading to a loss of ETH or an inconsistent state where tokens are minted but ETH is not transferred.

Fix

Always check the success boolean returned by low-level call functions and revert if the call was unsuccessful. For example: `(bool success,) = to.call{value: msg.value, gas: 2300}(""); require(success, "ETH transfer failed");`

Status

Unresolved

Low

Redundant burn Functions

The contract includes four separate burn functions (burn1, burn2, burn3, burn4) that differ only by the number of bytes32 data parameters they accept. The core logic within each function (checking minAmount, calling _burn, and emitting an event) is identical. This redundancy increases contract size, deployment costs, and reduces code maintainability without adding unique functionality.L-01

Issue

The contract includes four separate burn functions (burn1, burn2, burn3, burn4) that differ only by the number of bytes32 data parameters they accept. The core logic within each function (checking minAmount, calling _burn, and emitting an event) is identical. This redundancy increases contract size, deployment costs, and reduces code maintainability without adding unique functionality.

Fix

Consolidate these functions into a single burn function that accepts a dynamic array of bytes32 or a single bytes parameter for the data, allowing for more flexible and efficient burning operations. For example: `function burn(uint256 amount, bytes calldata data) public { ... emit Burn(msg.sender, amount, data); }`

Status

Unresolved

Info

Low Gas Limit for External ETH Transfers

The mint and batchMint functions use a fixed gas: 2300 limit for external ETH transfers via call. While this low gas limit helps prevent reentrancy attacks, it also severely restricts the amount of computation a recipient smart contract can perform in its receive or fallback function. If a recipient contract requires more than 2300 gas to process the incoming ETH, the transfer will fail.I-01

Issue

The mint and batchMint functions use a fixed gas: 2300 limit for external ETH transfers via call. While this low gas limit helps prevent reentrancy attacks, it also severely restricts the amount of computation a recipient smart contract can perform in its receive or fallback function. If a recipient contract requires more than 2300 gas to process the incoming ETH, the transfer will fail.

Fix

Ensure that all intended recipients of ETH transfers are either EOAs or simple smart contracts that can handle incoming ETH with minimal gas. If interaction with complex smart contracts is expected, consider increasing the gas limit or using a different transfer mechanism, while carefully mitigating reentrancy risks.

Status

Unresolved

Info

Redundant _decimals Storage Variable

The contract declares a uint8 _decimals; storage variable and sets it in the constructor. It then overrides the decimals() function to return this custom _decimals. While functional, the ERC20 base contract from OpenZeppelin already manages an internal _decimals variable (defaulting to 18 if not specified). This creates a slight redundancy where the base contract's _decimals might be initialized but then ignored in favor of the custom one.I-02

Issue

The contract declares a uint8 _decimals; storage variable and sets it in the constructor. It then overrides the decimals() function to return this custom _decimals. While functional, the ERC20 base contract from OpenZeppelin already manages an internal _decimals variable (defaulting to 18 if not specified). This creates a slight redundancy where the base contract's _decimals might be initialized but then ignored in favor of the custom one.

Fix

To avoid potential confusion or redundancy, consider if the custom _decimals variable is strictly necessary. If the intent is to simply set the decimals for the ERC20 token, it can often be done by passing the desired decimals to the ERC20 constructor directly if it supports it, or by ensuring the overridden decimals() function correctly interacts with the inherited _decimals if it's exposed or intended to be used.

Status

Unresolved

Analysis

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

The Token contract implements an ERC20 token with custom burning, minting, and ETH withdrawal functionalities, leveraging OpenZeppelin's ERC20, Ownable, and ERC20Permit standards. While the contract benefits from well-tested OpenZeppelin components and clear access control for critical operations, a significant logical error in the withdrawEth function severely restricts the owner's ability to manage contract ETH. Additionally, unchecked external call results in minting functions pose a risk of silent failures, and several code redundancies were identified.

Technical6/10Medium risk

The contract utilizes robust OpenZeppelin libraries for ERC20, Ownable, and ERC20Permit, providing a solid foundation for token functionality (7.2 Code Security). Access control for minting, ETH withdrawal, and ownership transfers is correctly implemented using onlyOwner (7.3 Access Control). However, a critical logical flaw in the withdrawEth function prevents the owner from withdrawing arbitrary amounts of ETH, only allowing withdrawal of the exact total balance (7.8 Operations). Furthermore, the mint and batchMint functions do not check the success of external ETH transfers, potentially leading to silent failures (7.2 Code Security). Redundant burn functions also increase contract size and complexity (7.1 Architecture).

Governance1/10High risk

The contract's economic model is straightforward, with an owner-controlled minAmount for burning and owner-only minting capabilities (7.4 Economic). The Ownable pattern provides clear administrative control over critical functions, including token supply management and ETH withdrawal (7.5 Governance). The owner can update the minAmount and transfer ownership, which are standard and expected privileges for an Ownable token (7.5 Governance).

Upgrades3/10High risk

The contract is not designed with an upgrade mechanism (e.g., proxy pattern), meaning its logic is immutable once deployed (7.7 Upgrades). This eliminates upgrade-specific risks such as proxy misconfigurations or logic bugs introduced during upgrades. Any future changes would require a new deployment and migration.

Final RecommendationWhat to do about this score

It is highly recommended to address the critical logical error in the withdrawEth function to ensure proper management of contract funds.

Implement robust error handling for all external calls, particularly for ETH transfers, to prevent silent failures and ensure transaction integrity. Review and refactor redundant code, such as the multiple burn functions, to improve efficiency and maintainability. Consider the implications of the low gas limit on external calls for potential future interactions with complex smart contract recipients.

Contract & Record

1 audit on record
TypeToken
NetworkBase
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 15, 202658Medium

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

Related Audits

6 more on the recordAll audits
XMAQUINADEUS · Base71HighTownsBase71HighGAME by VirtualsGAME · Base71HighMAGICBase71HighRecallBase72HighVANRYBase72High

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