Quantum Audit Logo
Launch App

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

Is Cronos Safe?

CROEthereum
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/10Upgrades4/10Checks passed2 of 5Findings2 High · 2 Medium · 1 Low5
SummaryAI Copilot

This audit covers a standard ERC-20 token implementation with minting capabilities, based on OpenZeppelin contracts from Solidity version 0.4.13. The contract utilizes SafeMath for arithmetic operations and an Ownable pattern for administrative control.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 70% (96.3% total → 95.2% effective; 94.5% in EOAs, 1.8% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 2 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
1.8%94.5%Wallets3.7%
94.5%Wallets3.7%
ContractsWalletsEveryone elseBubble area = share of supply
96.3%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking1.8%
  • Walletsanonymous holders, free to sell94.5%
  • Everyone elsethe rest of the supply3.7%
Effective concentrationwhat the score reads95.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$1.05M across 15 pairs
Show 4 more pairs

The 5 remaining pairs hold $3.0K between them and are not listed. 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$490.8KShare of depth46.7%
Top-1 Unlocked Holder43.0%
Top-3 Unlocked70.3%
Unlocked LP held by
0x3a21…a6d10xb713…11d10x7d42…53c90xd0b6…ab660xceff…cc6c0x7b4f…c6010xf1b8…8f160x2412…0c5e0x1731…94a80x47f3…149b

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

Security Findings

2 High2 Medium1 Low
High

Centralized and Uncapped Minting Authority

The MintableToken contract grants the owner the ability to mint an arbitrary amount of new tokens at any time until the finishMinting() function is called. There is no predefined maximum total supply for the token. This centralized control over supply, without a hard cap, poses a significant economic risk as the owner could inflate the token supply, devaluing existing tokens for holders.H-01

Issue

The MintableToken contract grants the owner the ability to mint an arbitrary amount of new tokens at any time until the finishMinting() function is called. There is no predefined maximum total supply for the token. This centralized control over supply, without a hard cap, poses a significant economic risk as the owner could inflate the token supply, devaluing existing tokens for holders.

Fix

Implement a hard cap on the total supply of tokens that can ever be minted. Consider decentralizing the minting process or introducing a multi-signature wallet for minting operations. Ensure the finishMinting() function is called promptly once the desired supply is reached, or integrate a time-locked mechanism for this action.

Status

Unresolved

High

Outdated Solidity Compiler Version

The contract is compiled with Solidity ^0.4.13. This version is significantly outdated and lacks numerous security enhancements, bug fixes, and gas optimizations introduced in later compiler versions (e.g., 0.6.x, 0.8.x). Notably, assert() statements, as used in SafeMath, consume all remaining gas on failure in 0.4.x, which is less efficient than require()/revert() introduced in 0.4.22 and later.H-02

Issue

The contract is compiled with Solidity ^0.4.13. This version is significantly outdated and lacks numerous security enhancements, bug fixes, and gas optimizations introduced in later compiler versions (e.g., 0.6.x, 0.8.x). Notably, assert() statements, as used in SafeMath, consume all remaining gas on failure in 0.4.x, which is less efficient than require()/revert() introduced in 0.4.22 and later.

Fix

Upgrade the contract to a recent and stable Solidity compiler version (e.g., 0.8.x). This would allow for the use of modern language features, improved security checks, and more gas-efficient error handling. Thoroughly test the contract after upgrading to ensure compatibility and correctness.

Status

Unresolved

Medium

ERC-20 approve Race Condition Vulnerability

The approve function in StandardToken is susceptible to a known ERC-20 race condition. If a user changes an allowance from a non-zero value to another non-zero value, a malicious spender could potentially spend both the old and new allowance amounts by front-running the transaction. While increaseApproval and decreaseApproval functions are provided to mitigate this, the base approve function remains vulnerable if used directly.M-01

Issue

The approve function in StandardToken is susceptible to a known ERC-20 race condition. If a user changes an allowance from a non-zero value to another non-zero value, a malicious spender could potentially spend both the old and new allowance amounts by front-running the transaction. While increaseApproval and decreaseApproval functions are provided to mitigate this, the base approve function remains vulnerable if used directly.

Fix

Educate users to exclusively use increaseApproval and decreaseApproval for modifying allowances. For the approve function itself, consider implementing the 'set to zero then set to new value' pattern, or clearly document the risk and the recommended alternative functions.

Status

Unresolved

Medium

Owner Renouncement Operational Risk

The renounceOwnership function allows the current owner to set the owner address to address(0). If this function is called without a subsequent transferOwnership to a new, valid owner, the contract will become permanently unowned. This would render all functions protected by the onlyOwner modifier, such as mint and finishMinting, inaccessible, leading to a loss of critical administrative control.M-02

Issue

The renounceOwnership function allows the current owner to set the owner address to address(0). If this function is called without a subsequent transferOwnership to a new, valid owner, the contract will become permanently unowned. This would render all functions protected by the onlyOwner modifier, such as mint and finishMinting, inaccessible, leading to a loss of critical administrative control.

Fix

Implement a multi-step process for renounceOwnership or transferOwnership to prevent accidental loss of control. For example, require the new owner to accept ownership before the transfer is finalized. If renouncement is intended, ensure all necessary administrative actions are completed beforehand.

Status

Unresolved

Low

Lack of Emergency Pausability

The contract lacks a mechanism to pause critical operations, such as token transfers or minting, in the event of an emergency. In scenarios like a discovered vulnerability, a major exploit, or extreme market volatility, the absence of an emergency stop can prevent a rapid response to mitigate potential damage.L-01

Issue

The contract lacks a mechanism to pause critical operations, such as token transfers or minting, in the event of an emergency. In scenarios like a discovered vulnerability, a major exploit, or extreme market volatility, the absence of an emergency stop can prevent a rapid response to mitigate potential damage.

Fix

Consider implementing a pausability mechanism (e.g., using OpenZeppelin's Pausable contract pattern) that allows the owner or a designated role to temporarily halt sensitive operations. This should be used as a last resort and ideally be time-limited or subject to governance control.

Status

Unresolved

Analysis

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

This audit covers a standard ERC-20 token implementation with minting capabilities, based on OpenZeppelin contracts from Solidity version 0.4.13. The contract utilizes SafeMath for arithmetic operations and an Ownable pattern for administrative control. Key findings include significant economic risks due to centralized and uncapped minting, and technical risks associated with an outdated Solidity compiler version and the known ERC-20 approve race condition. Operational risks related to owner renouncement and lack of emergency pausability are also noted.

Technical6/10Medium risk

The contract's architecture (7.1) is based on well-established OpenZeppelin patterns for ERC-20 and Ownable, which provides a solid foundation. SafeMath is correctly used throughout for arithmetic safety (7.2 Code Security). However, the use of Solidity ^0.4.13 introduces technical debt and potential inefficiencies, such as assert consuming all gas on failure. The approve function (7.2) is susceptible to a known ERC-20 race condition, despite the inclusion of increaseApproval and decreaseApproval functions.

Governance1/10High risk

The economic model (7.4) presents a high risk due to the centralized minting mechanism, which allows the contract owner to mint an unlimited supply of tokens until finishMinting is called. There is no explicit maximum total supply defined, leading to potential arbitrary inflation. Access control (7.3) is managed via the Ownable pattern, granting the owner significant power over token supply. The renounceOwnership function (7.5 Governance, 7.8 Operations) introduces a risk of rendering the contract unmanageable if administrative control is inadvertently relinquished.

Upgrades4/10Medium risk

The contract is not designed with an upgrade mechanism (7.7 Architecture), meaning its logic cannot be modified after deployment. This eliminates upgrade-related risks but also prevents future bug fixes or feature enhancements without a new deployment and migration.

Final RecommendationWhat to do about this score

It is strongly recommended to migrate to a modern Solidity compiler version (e.g., 0.8.x) to leverage improved security features, gas efficiency, and best practices.

Implement a clear, immutable total supply cap for the token to mitigate economic risks associated with centralized minting. Consider implementing a timelock for critical administrative actions and an emergency pause mechanism to provide a safety net against unforeseen vulnerabilities or market events.

Contract & Record

1 audit on record
TypeCroToken
NetworkEthereum
Token age1y
Contract0xa0b7…450b
Deployer0x494a…07e7
Badge for your website
Cronos 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, 202673High
  2. Jul 23, 202680High

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

Frequently Asked Questions

What is the CRO contract address?

The Cronos (CRO) contract on Ethereum is 0xa0b73e1ff0b80914ab6fe0444e65848c4c34450b. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Cronos a scam?

Quantum Audit's risk score for Cronos is 73/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is CRO liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $1.05M.

Who holds CRO?

As of Sep 4, 2026, the 10 largest holders own 96.3% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
NEXOEthereum73HighEpic ChainEPIC · Ethereum73HighAZTECEthereum73HighCoW Protocol TokenCOW · Ethereum73HighMetronome Synth ETHMSETH · Ethereum73HighMetronome Synth USDMSUSD · Ethereum73High

Would You Like a More Detailed Audit of Cronos?

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