Quantum Audit Logo

Is Bitcoin Cash Token Safe?

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

Is this your token? Publish your own audit on this page →

Bitcoin Cash Token BCH
0x8ff7…4adf
BNB Chain
Not verifiedThis 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 today 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The BEP20BitcoinCash token contract implements a standard BEP20 interface with owner-controlled minting. It utilizes SafeMath for arithmetic safety and an Ownable pattern for access control. The primary risk identified is the centralized minting authority, which grants the owner significant control over the token's supply and potential economic stability.

1 High2 Medium1 Low1 Informational
Volume 24h
$208.2K
Liquidity
$50.9K
Price
$352.2200
Token Age
3y
Top 10 Holders
79.4%

Security Findings

1 High2 Med1 Low1 Info
High

Centralized Minting Authority

H-01The `mint` function is restricted to the contract owner via the `onlyOwner` modifier. This allows the owner to mint an arbitrary amount of new tokens at any time, which can lead to significant inflation and devaluation of the token supply. This introduces a high centralization risk and potential for economic manipulation (7.4 Economic, 7.3 Access Control).
IssueThe `mint` function is restricted to the contract owner via the `onlyOwner` modifier. This allows the owner to mint an arbitrary amount of new tokens at any time, which can lead to significant inflation and devaluation of the token supply. This introduces a high centralization risk and potential for economic manipulation (7.4 Economic, 7.3 Access Control).
FixConsider implementing a multi-signature wallet for the owner address or a time-locked governance mechanism for the `mint` function. Alternatively, remove the minting capability entirely if a fixed supply is desired, or cap the total supply to prevent unlimited inflation.
StatusUnresolved
Medium

Older Solidity Compiler Version

M-01The contract is compiled with Solidity version 0.5.16. While `SafeMath` is used to prevent integer overflows/underflows, newer Solidity versions (e.g., 0.8.x) include built-in overflow/underflow checks by default, reducing reliance on external libraries and potentially offering better gas efficiency and security features (7.2 Code Security).
IssueThe contract is compiled with Solidity version 0.5.16. While `SafeMath` is used to prevent integer overflows/underflows, newer Solidity versions (e.g., 0.8.x) include built-in overflow/underflow checks by default, reducing reliance on external libraries and potentially offering better gas efficiency and security features (7.2 Code Security).
FixConsider upgrading the contract to a more recent Solidity compiler version (e.g., 0.8.x) to benefit from the latest security features, optimizations, and built-in safety checks. Thorough testing would be required after such an upgrade.
StatusUnresolved
Medium

`approve` Race Condition Vulnerability

M-02The standard ERC-20 `approve` function is susceptible to a known front-running race condition. If a user approves an amount, and then attempts to change that approved amount, a malicious actor could front-run the second `approve` transaction. This could allow the malicious actor to spend both the original and the new approved amounts, leading to a double-spend scenario (7.2 Code Security). While `increaseAllowance` and `decreaseAllowance` are provided, the `approve` function itself remains vulnerable.
IssueThe standard ERC-20 `approve` function is susceptible to a known front-running race condition. If a user approves an amount, and then attempts to change that approved amount, a malicious actor could front-run the second `approve` transaction. This could allow the malicious actor to spend both the original and the new approved amounts, leading to a double-spend scenario (7.2 Code Security). While `increaseAllowance` and `decreaseAllowance` are provided, the `approve` function itself remains vulnerable.
FixEducate users to exclusively use `increaseAllowance` and `decreaseAllowance` instead of directly calling `approve` to modify existing allowances. For new allowances, `approve` is safe. Ensure client-side applications guide users towards these safer functions.
StatusUnresolved
Low

Unused `_msgData()` Function

L-01The `_msgData()` function from the `Context` contract is included but not utilized anywhere within the `BEP20BitcoinCash` contract. The `this;` statement within `_msgData()` is a no-op and does not serve any functional purpose (7.2 Code Security).
IssueThe `_msgData()` function from the `Context` contract is included but not utilized anywhere within the `BEP20BitcoinCash` contract. The `this;` statement within `_msgData()` is a no-op and does not serve any functional purpose (7.2 Code Security).
FixRemove the `_msgData()` function from the `Context` contract or the `Context` inheritance if it's not intended for use, to slightly reduce contract bytecode size and improve code clarity.
StatusUnresolved
Info

Redundant `getOwner()` Function

I-01The `BEP20BitcoinCash` contract includes a public function `getOwner()` which simply returns the result of the `owner()` function inherited from `Ownable`. This creates a redundant external interface for the same functionality (7.1 Architecture).
IssueThe `BEP20BitcoinCash` contract includes a public function `getOwner()` which simply returns the result of the `owner()` function inherited from `Ownable`. This creates a redundant external interface for the same functionality (7.1 Architecture).
FixConsider removing the `getOwner()` function to avoid redundancy, as the `owner()` function already provides the same information and is a standard part of the `Ownable` pattern.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract implements the BEP20 standard, utilizing the SafeMath library to prevent integer overflows/underflows (7.2 Code Security). The code structure is clear and follows common patterns. However, it uses an older Solidity compiler version (0.5.16), which might lack some modern optimizations and security features. The standard `approve` function is susceptible to a known front-running race condition (7.2 Code Security), although `increaseAllowance` and `decreaseAllowance` are provided to mitigate this.

GovernanceHigh1/10

The contract features an `Ownable` access control pattern, granting the deployer significant power (7.3 Access Control). The `mint` function is restricted to the owner, allowing them to increase the total supply at will (7.4 Economic). This introduces a high centralization risk, as the owner can unilaterally devalue the token. The `burn` function is publicly accessible, allowing users to reduce their own balance.

UpgradesHigh3/10

This contract is not designed with an upgradeability pattern (7.7 Upgrades). This means its logic cannot be modified or extended after deployment. While this eliminates upgrade-related risks, any discovered vulnerabilities would require a new contract deployment and migration, which is a standard limitation for non-upgradeable contracts.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

79.4% in top 10
77.7% in wallets1.7% in contracts
Effective Concentration78.4%

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

$185.7K across 30 pairs
Pancakeswap v3WBNBanalysed$50.9K27.4%Pancakeswap v3WBNB$48.6K26.2%UniswapUSDT$28.6K15.4%0x8a1E…1256WBNB$17.9K9.6%0x738B…24bAUSDT$9.0K4.9%Pancakeswap v2WBNB$7.5K4.0%
Show 4 more pairsShow less
0x7207…4575WBNB$4.2K2.3%MdexBUSD$3.7K2.0%BiswapWBNB$2.7K1.4%TidaldexCZB$2.4K1.3%

The 20 remaining pairs hold $10.2K 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 Holder47.2%
Top-3 Unlocked96.9%

Key Addresses

8 addresses
Deployer
0x88ef…0566
Unlocked LP Held By
0xcd02…2e210xd9d3…df0f0x5de5…6d920x6472…015f0xa7c7…64700xb806…cd240xa81f…3a94

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

What Raised This Score

8 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 70% (79.4% total → 78.4% effective; 77.7% in EOAs, 1.7% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top3 unlocked holders = 96.9% (independent LP — depth risk, pool = 27% of DEX liquidity)
  • 1 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

Related Audits

6 more on the record
Based Token (BASED)Critical RiskGRVTCritical RiskFalcon Finance (FF)Critical RiskKGENCritical RiskBinance Brokers (BBROKERS)Critical RiskSpaceX (SPCXB)Critical Risk

Would You Like a More Detailed Audit of Bitcoin Cash Token?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit