Quantum Audit Logo

Is Baby Doge Coin a Scam?

Honeypot, rug-pull and ownership checks

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

Baby Doge Coin BABYDOGE
0xc748…e8de
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 18d ago 1 audit on record
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

This audit was conducted on an incomplete Solidity source code snippet. The provided code includes standard interfaces (IERC20), a SafeMath library, and a Context abstract contract. While these components demonstrate good security practices, the core logic of the 'CoinToken' contract was not provided, severely limiting the scope and depth of the security assessment. Consequently, a comprehensive evaluation of potential vulnerabilities such as reentrancy, access control issues, or economic exploits within the main token contract is not possible. The overall risk is assessed as High due to this critical information gap.

1 Critical1 High1 Medium1 Low1 Informational
i Our automated scanner reviewed Baby Doge Coin (BABYDOGE) on BNB Chain. 5 of 5 security checks passed — see the full breakdown below.
Volume 24h
$251.8K
Liquidity
$8.81M
Price
$0.0000000004
Age
5y
Top 10 Holders
78.5%

Security Findings

Critical

Incomplete Source Code Provided for Audit

C-01The provided Solidity source code snippet is incomplete, specifically missing the core 'CoinToken' contract implementation. This prevents a comprehensive security audit of the contract's primary logic, state variables, functions, and interactions. Critical vulnerabilities such as reentrancy, access control flaws, business logic errors, or economic exploits cannot be identified or assessed without the full source.
IssueThe provided Solidity source code snippet is incomplete, specifically missing the core 'CoinToken' contract implementation. This prevents a comprehensive security audit of the contract's primary logic, state variables, functions, and interactions. Critical vulnerabilities such as reentrancy, access control flaws, business logic errors, or economic exploits cannot be identified or assessed without the full source.
FixProvide the complete and verifiable source code for the 'CoinToken' contract, including all inherited contracts and libraries. A full audit should then be conducted on the complete codebase to ensure all potential vulnerabilities are identified and addressed.
StatusUnresolved
High

Outdated Solidity Compiler Version

H-01The contract uses Solidity compiler version `0.6.12`. This version is significantly outdated. Newer Solidity versions (e.g., 0.8.x) include important security enhancements, such as built-in overflow/underflow checks for arithmetic operations, improved error messages, and various optimizations. Using an older compiler version may expose the contract to known compiler-related bugs or prevent it from benefiting from modern security features.
IssueThe contract uses Solidity compiler version `0.6.12`. This version is significantly outdated. Newer Solidity versions (e.g., 0.8.x) include important security enhancements, such as built-in overflow/underflow checks for arithmetic operations, improved error messages, and various optimizations. Using an older compiler version may expose the contract to known compiler-related bugs or prevent it from benefiting from modern security features.
FixConsider upgrading the Solidity compiler version to a more recent and actively maintained release (e.g., `^0.8.0`). Ensure thorough testing is performed after any compiler upgrade, as syntax or behavior might change. If upgrading is not feasible, ensure all known vulnerabilities specific to `0.6.12` are understood and mitigated.
StatusUnresolved
Medium

ERC-20 `approve` Race Condition Vulnerability

M-01The `IERC20` interface, as included, highlights a known race condition vulnerability associated with the `approve()` function. If a user calls `approve()` to change an allowance from a non-zero value to another non-zero value, a malicious actor could front-run the transaction, use the original allowance, and then allow the new `approve()` transaction to proceed, effectively spending tokens twice (once with the old allowance, once with the new).
IssueThe `IERC20` interface, as included, highlights a known race condition vulnerability associated with the `approve()` function. If a user calls `approve()` to change an allowance from a non-zero value to another non-zero value, a malicious actor could front-run the transaction, use the original allowance, and then allow the new `approve()` transaction to proceed, effectively spending tokens twice (once with the old allowance, once with the new).
FixTo mitigate the `approve()` race condition, users should be instructed to first set the allowance to zero (`approve(spender, 0)`) and then set it to the desired non-zero value (`approve(spender, amount)`). Alternatively, consider using `increaseAllowance()` and `decreaseAllowance()` functions, if available in the token implementation, which are designed to safely modify allowances.
StatusUnresolved
Low

Unspecified SPDX License Identifier

L-01The contract uses `// SPDX-License-Identifier: Unlicensed`. While not a security vulnerability, using 'Unlicensed' or omitting a specific SPDX license identifier can create legal ambiguities regarding the contract's usage, distribution, and modification rights.
IssueThe contract uses `// SPDX-License-Identifier: Unlicensed`. While not a security vulnerability, using 'Unlicensed' or omitting a specific SPDX license identifier can create legal ambiguities regarding the contract's usage, distribution, and modification rights.
FixIt is best practice to specify a clear and widely recognized SPDX license identifier (e.g., `MIT`, `GPL-3.0-or-later`, `Apache-2.0`) to clarify the legal terms under which the code can be used. This improves transparency and interoperability within the blockchain ecosystem.
StatusUnresolved
Info

Potential for Unidentified Vulnerabilities in Core Logic

I-01Due to the critical limitation of an incomplete source code, the audit could not assess the specific implementation details of the 'CoinToken' contract. This means that common vulnerabilities such as reentrancy, improper access control, logical flaws in token transfers or minting/burning mechanisms, or other contract-specific exploits remain unexamined and could potentially exist within the unprovided code.
IssueDue to the critical limitation of an incomplete source code, the audit could not assess the specific implementation details of the 'CoinToken' contract. This means that common vulnerabilities such as reentrancy, improper access control, logical flaws in token transfers or minting/burning mechanisms, or other contract-specific exploits remain unexamined and could potentially exist within the unprovided code.
FixA full audit of the complete source code is essential to identify and mitigate any such vulnerabilities. This includes a thorough review of all custom functions, state changes, external calls, and access control mechanisms within the 'CoinToken' contract.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The provided code snippet demonstrates a foundational understanding of secure development by including the SafeMath library for arithmetic operations (7.2 Code Security) and adhering to the IERC20 standard interface (7.1 Architecture). However, the audit is severely limited by the absence of the full 'CoinToken' contract source code, making it impossible to assess its core logic, state transitions, and interactions (7.1 Architecture, 7.2 Code Security, 7.3 Access Control). Additionally, the use of Solidity compiler version 0.6.12 is outdated, lacking security features and optimizations present in newer versions (7.2 Code Security).

GovernanceMedium4/10

Due to the incomplete nature of the provided source code, it is impossible to assess any governance mechanisms (7.5 Governance) or economic models (7.4 Economic) that might be implemented within the 'CoinToken' contract. This includes evaluating tokenomics, fee structures, reward distribution, or potential for oracle manipulation (7.6 External). Therefore, the risk in these areas remains unquantified and potentially high.

UpgradesLow8/10

The provided information indicates that the contract is not a proxy (`is_proxy: false`) and therefore does not have upgradeability features (7.7 Upgrades). This eliminates risks associated with upgrade mechanisms, such as improper proxy initialization or logic contract vulnerabilities during upgrades. However, it also means that any discovered vulnerabilities in the deployed contract cannot be patched without a new deployment.

Security Checklist

Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

69.3% in wallets9.2% in contracts
Effective Concentration73.0%

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

Show 4 more pairsShow less

The 20 remaining pairs hold $954 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

LP Burned45.9%
LP Locked99.7% · Null Address, PinkLock02
Top-1 Unlocked Holder0.1%

Key Addresses

Deployer
0xf103…2b74
Unlocked LP Held By
0xbc09…596f0x6305…9b8a0x5d38…8a890x0370…3be80xfef4…8df80xe651…30c00x7e9d…6520

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

What Raised This Score

  • Top-10 concentration > 70% (78.5% total → 73.0% effective; 69.3% in EOAs, 9.2% in contracts — extreme)
  • 1 Critical finding(s) from audit
  • 1 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

Related Audits

MindNetwork FHE Token (FHE)Medium RiskOrochi Network Token (ON)Medium RiskTermMax (TMX)Medium RiskZestMedium RiskAPRO oracle Token (AT)Medium Riskutility token (UTILITY)Medium Risk

Would You Like a More Detailed Audit of Baby Doge Coin?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit