Quantum Audit Logo

Is BTCB Token Safe?

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

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

BTCB Token BTCB
0x7130…ad9c
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The BTCB Token contract is a standard BEP20 implementation with an Ownable access control pattern. It utilizes SafeMath for arithmetic operations, mitigating common integer overflow/underflow vulnerabilities. However, the contract features a centralized minting capability controlled by the owner, posing a significant economic risk. Additionally, ownership is managed by a single EOA, creating a single point of failure.

1 High1 Medium2 Informational
Volume 24h
$28.30M
Liquidity
$26.11M
Price
$80955.4900
Token Age
3y
Top 10 Holders
77.3%

Security Findings

1 High1 Med2 Info
High

Centralized Minting Capability

H-01The `mint` function, callable only by the contract owner, allows for the creation of an arbitrary amount of new tokens. This centralized control over the token supply introduces a significant economic risk (7.4 Economic) as the owner can unilaterally inflate the supply, potentially diluting the value for existing token holders without any checks or balances (7.3 Access Control).
IssueThe `mint` function, callable only by the contract owner, allows for the creation of an arbitrary amount of new tokens. This centralized control over the token supply introduces a significant economic risk (7.4 Economic) as the owner can unilaterally inflate the supply, potentially diluting the value for existing token holders without any checks or balances (7.3 Access Control).
FixConsider removing the `mint` function if a fixed supply is desired. If minting is a necessary feature, implement a robust governance mechanism (e.g., a multi-signature wallet or a DAO) to control minting operations, requiring multiple approvals or community consensus for any supply increases.
StatusUnresolved
Medium

Single Point of Failure for Ownership

M-01The contract's ownership is controlled by a single Externally Owned Account (EOA). If this EOA's private key is compromised, lost, or becomes inaccessible, an attacker could gain full control over critical functions like `mint` and `transferOwnership`, or the contract could become unmanageable (7.3 Access Control, 7.8 Operations).
IssueThe contract's ownership is controlled by a single Externally Owned Account (EOA). If this EOA's private key is compromised, lost, or becomes inaccessible, an attacker could gain full control over critical functions like `mint` and `transferOwnership`, or the contract could become unmanageable (7.3 Access Control, 7.8 Operations).
FixTransfer ownership from the current EOA to a multi-signature wallet (e.g., Gnosis Safe) to distribute control and require multiple approvals for sensitive operations, significantly reducing the risk of a single point of failure.
StatusUnresolved
Info

Older Solidity Compiler Version

I-01The contract is compiled with Solidity version 0.5.16. While `SafeMath` is used to mitigate integer overflows/underflows, newer compiler versions (e.g., 0.8.x) include built-in overflow checks by default, offer better gas optimizations, and incorporate various security improvements and bug fixes (7.2 Code Security).
IssueThe contract is compiled with Solidity version 0.5.16. While `SafeMath` is used to mitigate integer overflows/underflows, newer compiler versions (e.g., 0.8.x) include built-in overflow checks by default, offer better gas optimizations, and incorporate various security improvements and bug fixes (7.2 Code Security).
FixConsider upgrading to a more recent and actively maintained Solidity compiler version (e.g., 0.8.x) for future deployments or contract iterations to benefit from enhanced security features and optimizations. Ensure thorough testing if upgrading.
StatusUnresolved
Info

Standard ERC-20 `approve` Front-Running Risk

I-02The `approve` function is susceptible to a known ERC-20 front-running vulnerability. If a user approves an amount, and then approves a different amount without first setting the allowance to zero, a malicious actor could front-run the second transaction to spend the original allowance, and then spend the new allowance, effectively spending twice (7.2 Code Security). While `increaseAllowance` and `decreaseAllowance` functions are provided to mitigate this, the base `approve` function still carries this risk.
IssueThe `approve` function is susceptible to a known ERC-20 front-running vulnerability. If a user approves an amount, and then approves a different amount without first setting the allowance to zero, a malicious actor could front-run the second transaction to spend the original allowance, and then spend the new allowance, effectively spending twice (7.2 Code Security). While `increaseAllowance` and `decreaseAllowance` functions are provided to mitigate this, the base `approve` function still carries this risk.
FixEducate users to utilize `increaseAllowance` and `decreaseAllowance` instead of directly calling `approve` when modifying an existing allowance. Alternatively, consider implementing a 'zero-then-approve' pattern within the `approve` function itself, though this adds an extra transaction for users.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract demonstrates good technical practices, including the use of the SafeMath library (7.2 Code Security) to prevent integer overflows/underflows. It adheres to the BEP20 standard, providing expected token functionalities. Minor technical observations include the use of an older Solidity compiler version (0.5.16) and the inherent front-running risk associated with the standard ERC-20 `approve` function, though `increaseAllowance` and `decreaseAllowance` are provided (7.2 Code Security).

GovernanceHigh1/10

A significant economic risk (7.4 Economic) is the owner's ability to mint an unlimited supply of new tokens via the `mint` function (7.3 Access Control). This centralized control can lead to token dilution and value depreciation. Furthermore, the contract's ownership is held by a single Externally Owned Account (EOA), which presents a single point of failure (7.8 Operations). The initial token supply is also entirely minted to the deployer, centralizing initial distribution.

UpgradesHigh3/10

The contract is not designed with an upgradeability pattern (7.7 Upgrades), meaning its code is immutable once deployed. This eliminates upgrade-related risks but also prevents future bug fixes or feature enhancements without a new deployment.

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

77.3% in top 10
64.0% in wallets13.3% in contracts
Effective Concentration69.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

$84.04M across 30 pairs
Pancakeswap v3WBNBanalysed$26.11M31.1%Pancakeswap v3USDT$16.82M20.0%Pancakeswap v2MGC$13.78M16.4%Uniswap比特币$9.16M10.9%UniswapWBNB$6.99M8.3%Pancakeswap v2WBNB$3.18M3.8%
Show 4 more pairsShow less
Pancakeswap v3WBNB$1.46M1.7%UniswapUSDT$1.43M1.7%Pancakeswap v3WBNB$1.04M1.2%Pancakeswap v3USDT$910.6K1.1%

The 20 remaining pairs hold $3.17M 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 Holder97.5%
Top-3 Unlocked98.0%

Key Addresses

11 addresses
Deployer
0xf07c…7f47
Unlocked LP Held By
0x556b…d59e0x3254…0cab0xec08…40530x1c71…c5340xc262…8ab90xfd93…1c3e0xf8bb…17ab0x0c37…88780x11b5…1f8f0x51d1…093a

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 > 50% (77.3% total → 69.4% effective; 64.0% in EOAs, 13.3% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 97.5% (independent LP — depth risk, pool = 31% of DEX liquidity)
  • LP top3 unlocked holders = 98.0% (independent LP — depth risk, pool = 31% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium 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
孙小圣High RiskSlap Cat (SLAP)High RiskUnitas (UP)High RiskniulaiHigh RiskBNB Attestation (BAS)High RiskRICE AI (RICE)High Risk

Would You Like a More Detailed Audit of BTCB Token?

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

Get Detailed Audit