Quantum Audit Logo
Launch App

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

Is 01 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
SummaryAI Copilot

The Coin01 token contract is a standard ERC20 implementation with a fixed maximum supply and centralized minting/burning capabilities controlled by an immutable 'curve' address.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 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
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
14.0%Contracts5.7%Wallets80.3%Everyone else
14.0%Contracts5.7%80.3%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
19.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking14.0%
  • Walletsanonymous holders, free to sell5.7%
  • Everyone elsethe rest of the supply80.3%
Effective concentrationwhat the score reads11.3%
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$1.72M 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$1.72MShare of depth100.0%
Top-1 Unlocked Holder24.3%
Top-3 Unlocked32.4%
Unlocked LP held by
0xedcd…102d0x946e…c48e0xbb15…56670x7a52…459a0x29de…147f0x6bf8…ddc30x73e1…50bf0x8651…9a9c0x9bbb…006d0x6794…980f

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

Security Findings

1 Medium1 Low2 Info
Medium

Centralized Mint/Burn Control

The curve address has exclusive control over minting new tokens up to MAX_SUPPLY and burning existing tokens. This grants significant power over the token's supply, making the security of the curve address paramount. While a common design for protocol-controlled tokens, a compromise of this address could lead to arbitrary token minting (up to cap) or burning, severely impacting token value and user trust.M-01

Issue

The curve address has exclusive control over minting new tokens up to MAX_SUPPLY and burning existing tokens. This grants significant power over the token's supply, making the security of the curve address paramount. While a common design for protocol-controlled tokens, a compromise of this address could lead to arbitrary token minting (up to cap) or burning, severely impacting token value and user trust.

Fix

Implement robust security measures for the curve address, such as a multi-signature wallet, a time-locked contract, or a well-audited governance mechanism. Ensure that the operational security surrounding the curve address is of the highest standard to prevent unauthorized access or malicious actions.

Status

Unresolved

Low

Immutability of curve Address

The curve address is set in the constructor and declared immutable. This design choice means the curve controller cannot be updated or replaced without deploying a new token contract. While preventing unauthorized changes, it introduces inflexibility and a single point of failure if the curve contract itself needs upgrades or if its private keys are compromised, requiring a full token migration.L-01

Issue

The curve address is set in the constructor and declared immutable. This design choice means the curve controller cannot be updated or replaced without deploying a new token contract. While preventing unauthorized changes, it introduces inflexibility and a single point of failure if the curve contract itself needs upgrades or if its private keys are compromised, requiring a full token migration.

Fix

Acknowledge this design constraint. If future flexibility is desired for the curve controller, consider a design pattern where the controller address can be updated by a trusted entity (e.g., a governance contract or a multi-sig) through a controlled mechanism. For the current design, ensure the curve address is extremely stable and secure.

Status

Unresolved

Info

Dependency on OpenZeppelin Contracts

The contract relies heavily on OpenZeppelin's ERC20 implementation (v5.5.0). While OpenZeppelin contracts are well-audited and a standard for secure development, any future vulnerabilities discovered in the specific version used could indirectly affect this contract.I-01

Issue

The contract relies heavily on OpenZeppelin's ERC20 implementation (v5.5.0). While OpenZeppelin contracts are well-audited and a standard for secure development, any future vulnerabilities discovered in the specific version used could indirectly affect this contract.

Fix

Regularly monitor OpenZeppelin's security advisories and updates. While direct action on this contract may not be possible if it's not upgradeable, awareness is key for future deployments or if a token migration becomes necessary due to a critical vulnerability in the underlying library.

Status

Unresolved

Info

Lack of Emergency Pause Mechanism

The contract does not include a mechanism to pause token transfers or minting/burning operations in an emergency. In scenarios like critical vulnerabilities in integrated protocols or market manipulation, the absence of a pause function limits the ability to react and mitigate potential damage.I-02

Issue

The contract does not include a mechanism to pause token transfers or minting/burning operations in an emergency. In scenarios like critical vulnerabilities in integrated protocols or market manipulation, the absence of a pause function limits the ability to react and mitigate potential damage.

Fix

For tokens intended for complex DeFi ecosystems, consider adding a pause mechanism (e.g., using OpenZeppelin's Pausable module) controlled by a trusted entity (e.g., governance or multi-sig). This provides a crucial failsafe for unforeseen circumstances.

Status

Unresolved

Analysis

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

The Coin01 token contract is a standard ERC20 implementation with a fixed maximum supply and centralized minting/burning capabilities controlled by an immutable 'curve' address. The code is simple, leverages OpenZeppelin's audited libraries, and demonstrates good security practices for its scope. The primary risk stems from the centralized control over token supply and the immutability of the controlling address, which requires robust security measures for the 'curve' address itself.

Technical8/10Low risk

The technical architecture of Coin01 is straightforward, implementing a standard ERC20 token (7.1 Architecture). It utilizes OpenZeppelin's battle-tested ERC20 library, which significantly enhances code security and reduces the likelihood of common vulnerabilities like reentrancy or integer overflows (7.2 Code Security). Access control for minting and burning is strictly enforced via an onlyCurve modifier, ensuring only the designated curve address can perform these operations (7.3 Access Control). The contract's simplicity and reliance on audited components contribute to a low technical risk profile.

Governance5/10Medium risk

The economic model of Coin01 features a hard-capped maximum supply, preventing inflationary attacks beyond the defined limit (7.4 Economic). However, the curve address holds exclusive power to mint tokens up to this cap and burn tokens, representing a significant centralization of control over the token's supply dynamics (7.5 Governance). The security and governance of this curve address are paramount, as its compromise could lead to severe economic consequences for the token. There are no external dependencies that introduce oracle manipulation risks (7.6 External).

Upgrades3/10High risk

The Coin01 contract is not designed to be upgradeable (7.7 Upgrades). The curve address, which controls minting and burning, is set as immutable in the constructor. This design choice eliminates upgrade-related risks for the token contract itself but introduces inflexibility, as the curve controller cannot be changed without deploying an entirely new token. There are no specific operational risks identified beyond the general security of the curve address (7.8 Operations).

Final RecommendationWhat to do about this score

It is recommended to ensure the curve address is secured with robust multi-signature governance or a well-audited protocol contract to mitigate the risks associated with centralized control over token supply.

Consider implementing an emergency pause mechanism in future iterations if the token is intended for integration into complex DeFi ecosystems, to provide a failsafe in critical situations.

Contract & Record

1 audit on record
TypeToken
NetworkEthereum
Token age1mo
Contract0x3270…a4ca
Deployer0x9ef1…9c9e
Badge for your website
01 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, 202629Low
  2. Jul 24, 202611Low

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

Would You Like a More Detailed Audit of 01?

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