Is Cronos (CRO) Safe? Smart Contract Security Analysis

Security Findings

2 High2 Med1 Low

High

Centralized and Uncapped Minting Authority

H-01The `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.

IssueThe `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.

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

StatusUnresolved

High

Outdated Solidity Compiler Version

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

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

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

StatusUnresolved

Medium

ERC-20 `approve` Race Condition Vulnerability

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

IssueThe `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.

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

StatusUnresolved

Medium

Owner Renouncement Operational Risk

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

IssueThe `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.

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

StatusUnresolved

Low

Lack of Emergency Pausability

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

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

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

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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.

GovernanceHigh1/10

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.

UpgradesMedium4/10

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.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Holder Composition

96.3% in top 10

94.5% in wallets1.8% in contracts

Effective Concentration95.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

$1.05M across 15 pairs

Uniswap v4ETHanalysed$490.8K DefiswapWETH$254.8K Uniswap v3WETH$167.0K DefiswapUSDC$88.2K Uniswap v4USDC$25.3K DefiswapUSDT$6.0K

Show 4 more pairsShow less

DefiswapLINK$6.0K Uniswap v4ZIK$4.7K Uniswap v2WETH$3.0K DefiswapUNI$2.0K

The 5 remaining pairs hold $3.0K between them and are not listed.

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 Holder43.0%

Top-3 Unlocked70.3%

Key Addresses

11 addresses

Deployer

0x494a…07e7

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.

What Raised This Score

7 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

Is Cronos Safe?

Security Findings

Centralized and Uncapped Minting Authority

Outdated Solidity Compiler Version

ERC-20 `approve` Race Condition Vulnerability

Owner Renouncement Operational Risk

Lack of Emergency Pausability

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Cronos?