Quantum Audit Logo
Launch App

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

Is FOX 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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades5/10Checks passed2 of 5Findings2 High · 1 Medium · 1 Low4
SummaryAI Copilot

The FOX token contract implements an ERC20 standard with mintable and capped features, utilizing SafeMath for arithmetic safety and a MinterRole for access control.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply, but capped at 0.0%/year
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 55.2%
  • LP top3 unlocked holders = 88.3%
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply, but capped at 0.0%/year
  • Top-10 concentration > 30% (75.8% total → 47.7% effective; 28.9% in EOAs, 46.8% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 55.2% (independent LP — depth risk)
  • LP top3 unlocked holders = 88.3% (independent LP — depth risk)
  • 2 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
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
46.8%Contracts28.9%Wallets24.2%Everyone else
46.8%Contracts28.9%Wallets24.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
75.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking46.8%
  • Walletsanonymous holders, free to sell28.9%
  • Everyone elsethe rest of the supply24.2%
Effective concentrationwhat the score reads47.7%
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.33M

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.33MShare of depth100.0%
Top-1 Unlocked Holder55.2%
Top-3 Unlocked88.3%
Unlocked LP held by
0x90a4…51be0xe7e1…27440xdd80…9e720xc54b…42a00xc14e…e5550x212e…932b0x75d7…9faa0x662d…8ac30x24fd…7fa00x7217…d3e5

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

Security Findings

2 High1 Medium1 Low
High

Ineffective Minter Role and Cap Enforcement

The FOX token's constructor mints the entire _cap (1,000,001,337 * 10^18) to the deployer (msg.sender). As a result, the _totalSupply immediately reaches the _cap. The _mint function in ERC20Capped includes a require(totalSupply().add(value) <= _cap); check. Since _totalSupply is already equal to _cap, any subsequent calls to the mint function (even by an authorized minter) will always fail, rendering the MinterRole and the mint functionality permanently ineffective for increasing token supply. This is a significant design flaw where a core feature is nullified by the initialization logic.H-01

Issue

The FOX token's constructor mints the entire _cap (1,000,001,337 * 10^18) to the deployer (msg.sender). As a result, the _totalSupply immediately reaches the _cap. The _mint function in ERC20Capped includes a require(totalSupply().add(value) <= _cap); check. Since _totalSupply is already equal to _cap, any subsequent calls to the mint function (even by an authorized minter) will always fail, rendering the MinterRole and the mint functionality permanently ineffective for increasing token supply. This is a significant design flaw where a core feature is nullified by the initialization logic.

Fix

Clarify the intended tokenomics. If the token is meant to have a fixed supply from the start, remove the MinterRole and mint functions entirely to avoid misleading functionality. If the token is intended to be mintable up to a cap, the initial mint in the constructor should be less than the _cap, allowing minters to mint additional tokens later.

Status

Unresolved

High

Centralized Token Supply

The FOX token's constructor mints 100% of the total capped supply to the contract deployer (msg.sender). This results in extreme centralization of the token supply, as a single address controls the entire initial token distribution. This poses significant risks, including potential for market manipulation, lack of decentralization, and a single point of failure if the deployer's private key is compromised.H-02

Issue

The FOX token's constructor mints 100% of the total capped supply to the contract deployer (msg.sender). This results in extreme centralization of the token supply, as a single address controls the entire initial token distribution. This poses significant risks, including potential for market manipulation, lack of decentralization, and a single point of failure if the deployer's private key is compromised.

Fix

Implement a more decentralized distribution strategy. Consider distributing tokens to multiple addresses, vesting contracts, or a community-controlled treasury rather than a single deployer address. This would reduce the risk associated with centralized control and promote a healthier token ecosystem.

Status

Unresolved

Medium

Outdated Solidity Compiler Version

The contract uses pragma solidity 0.5.4. This compiler version is significantly outdated. While SafeMath is used to mitigate integer overflow/underflow, newer compiler versions (e.g., 0.8.x) offer built-in overflow/underflow checks, improved optimizations, and address various known compiler bugs and security enhancements that were not present in older versions.M-01

Issue

The contract uses pragma solidity 0.5.4. This compiler version is significantly outdated. While SafeMath is used to mitigate integer overflow/underflow, newer compiler versions (e.g., 0.8.x) offer built-in overflow/underflow checks, improved optimizations, and address various known compiler bugs and security enhancements that were not present in older versions.

Fix

Consider upgrading the Solidity compiler version to a more recent and actively maintained release (e.g., 0.8.x). This would leverage modern compiler features, security improvements, and potentially more efficient bytecode. Ensure thorough testing if upgrading, as syntax and behavior might differ slightly.

Status

Unresolved

Low

Standard ERC20 approve Race Condition

The approve function, as implemented in the ERC20 standard, is susceptible to a known race condition. If a user approves an allowance for a spender and then attempts to change that allowance to a new value, a malicious spender could front-run the transaction. The spender could spend the original allowance, and then the new approval would go through, allowing the spender to spend the newly approved amount as well, effectively spending more than intended. While increaseAllowance and decreaseAllowance functions are provided to mitigate this specific scenario, the approve function itself remains vulnerable.L-01

Issue

The approve function, as implemented in the ERC20 standard, is susceptible to a known race condition. If a user approves an allowance for a spender and then attempts to change that allowance to a new value, a malicious spender could front-run the transaction. The spender could spend the original allowance, and then the new approval would go through, allowing the spender to spend the newly approved amount as well, effectively spending more than intended. While increaseAllowance and decreaseAllowance functions are provided to mitigate this specific scenario, the approve function itself remains vulnerable.

Fix

Educate users to use increaseAllowance and decreaseAllowance instead of directly calling approve when modifying an existing allowance. If approve must be used, advise users to first set the allowance to zero before setting a new non-zero value, although this still involves two transactions and potential front-running risks.

Status

Unresolved

Analysis

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

The FOX token contract implements an ERC20 standard with mintable and capped features, utilizing SafeMath for arithmetic safety and a MinterRole for access control. However, a critical design flaw renders the minting functionality permanently ineffective as the entire token supply is minted to the deployer during construction, immediately reaching the cap. This leads to extreme centralization of the token supply and makes the MinterRole redundant for its primary purpose. Additionally, the contract uses an outdated Solidity compiler version.

Technical6/10Medium risk

The contract utilizes the ERC20 standard, SafeMath for arithmetic safety, and a MinterRole for access control (7.2 Code Security). However, a significant design flaw exists where the entire token cap is minted to the deployer in the constructor, immediately disabling any further minting functionality (7.1 Architecture). This renders the MinterRole and its associated functions ineffective for their intended purpose. The contract also uses an outdated Solidity compiler version (7.2 Code Security). Standard ERC20 approve race conditions are present, though increaseAllowance and decreaseAllowance mitigate some risks (7.2 Code Security).

Governance1/10High risk

The economic model of the FOX token presents a high centralization risk (7.4 Economic). The entire token supply is minted to the contract deployer during construction, granting a single entity complete control over the initial distribution and potential market manipulation. While a MinterRole is defined, its functionality for increasing token supply is nullified by the initial minting, making any governance over minting irrelevant (7.5 Governance). There are no other explicit governance mechanisms or economic incentives beyond standard ERC20 transfers.

Upgrades5/10Medium risk

The FOX token contract is not designed with upgradeability in mind (7.7 Upgrades). It is a standard, non-proxy implementation, meaning its logic cannot be altered after deployment. This eliminates risks associated with upgrade mechanisms but also means any discovered vulnerabilities or desired feature changes would require a new contract deployment and token migration.

Final RecommendationWhat to do about this score

It is strongly recommended to address the fundamental design flaw where the entire token supply is minted at deployment, rendering the minting functionality and MinterRole ineffective.

If the intention was to have a fixed supply, the MinterRole should be removed entirely to avoid confusion. If minting was intended, the initial supply should not consume the entire cap. Additionally, consider migrating to a newer Solidity compiler version (e.g., 0.8.x) to benefit from built-in safety features and optimizations. Thoroughly review the token distribution strategy to mitigate centralization risks.

Contract & Record

1 audit on record
TypeToken
NetworkEthereum
Token age6y
Contract0xc770…e52d
Deployer0x7021…bbad
Badge for your website
FOX 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, 202653Medium
  2. Aug 13, 202668High

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

Related Audits

6 more on the recordAll audits
StorjTokenSTORJ · Ethereum53MediumFTTFTX TOKEN · Ethereum53MediumAmbire WalletWALLET · Ethereum53MediumMorphoEthereum54MediumUniswapUNI · Ethereum52MediumBeamEthereum54Medium

Would You Like a More Detailed Audit of FOX?

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