Quantum Audit Logo
Launch App

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

Is BabyShark Safe?

BABYSHARKBNB Chain
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
Technical8/10Governance1/10Upgrades6/10Checks passed5 of 7Findings1 Low · 2 Info3
SummaryAI Copilot

The provided code implements a standard ERC20 token. The implementation largely follows best practices, utilizing unchecked blocks safely within Solidity 0.8.x and including functions like increaseAllowance to enhance security.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 30% (85.0% total → 35.8% effective; 3.0% in EOAs, 82.0% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($22,192 across 1 pairs — thin market)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 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 45 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
82.0%Contracts3.0%15.0%Everyone else
82.0%Contracts3.0%15.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
85.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking82.0%
  • Walletsanonymous holders, free to sell3.0%
  • Everyone elsethe rest of the supply15.0%
Effective concentrationwhat the score reads35.8%
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$22.2K

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$22.2KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x3298…ea49

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

Security Findings

1 Low2 Info
Low

Centralized Minting/Burning (Design Choice)

The _mint and _burn functions are declared as internal virtual. This design allows a derived contract to implement specific logic for token supply manipulation. While this provides flexibility for tokenomics, it introduces a centralized point of control if the inheriting contract does not implement robust access control (e.g., onlyOwner, onlyMinter) for these powerful functions. Without proper restrictions, an attacker gaining control of the derived contract's owner could arbitrarily mint or burn tokens.L-01

Issue

The _mint and _burn functions are declared as internal virtual. This design allows a derived contract to implement specific logic for token supply manipulation. While this provides flexibility for tokenomics, it introduces a centralized point of control if the inheriting contract does not implement robust access control (e.g., onlyOwner, onlyMinter) for these powerful functions. Without proper restrictions, an attacker gaining control of the derived contract's owner could arbitrarily mint or burn tokens.

Fix

Any contract inheriting from this ERC20 base must implement strict access control mechanisms (e.g., OpenZeppelin's Ownable or AccessControl) for the _mint and _burn functions to prevent unauthorized supply changes. Clearly define and document the roles and permissions associated with these functions.

Status

Unresolved

Info

Standard ERC20 Implementation

The contract provides a robust and standard implementation of the ERC20 token specification. It includes increaseAllowance and decreaseAllowance functions, which are best practices to mitigate common approve race conditions by allowing atomic adjustments to allowances rather than direct setting.I-01

Issue

The contract provides a robust and standard implementation of the ERC20 token specification. It includes increaseAllowance and decreaseAllowance functions, which are best practices to mitigate common approve race conditions by allowing atomic adjustments to allowances rather than direct setting.

Fix

No specific recommendation. This finding highlights a strength of the contract.

Status

Unresolved

Info

Truncated Math Library

The provided Math library code is truncated, specifically the mulDiv function. This prevents a full security review of its arithmetic operations and potential edge cases. While the visible part includes an overflow check (require(denominator > prod1, "Math: mulDiv overflow")), the completeness and correctness of the entire function cannot be verified.I-02

Issue

The provided Math library code is truncated, specifically the mulDiv function. This prevents a full security review of its arithmetic operations and potential edge cases. While the visible part includes an overflow check (require(denominator > prod1, "Math: mulDiv overflow")), the completeness and correctness of the entire function cannot be verified.

Fix

If the Math library is intended for production use, ensure its full, verified source code is available for a complete security review. Verify that all arithmetic operations, especially complex ones like mulDiv, handle edge cases and potential overflows/underflows correctly.

Status

Unresolved

Analysis

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

The provided code implements a standard ERC20 token. The implementation largely follows best practices, utilizing unchecked blocks safely within Solidity 0.8.x and including functions like increaseAllowance to enhance security. The _mint and _burn functions are internal virtual, indicating that a derived contract would define their specific access control and usage, which is a common design pattern for extensible tokens. The Math library provided is truncated, preventing a full review of its contents.

Technical8/10Low risk

The technical architecture (7.1) is a standard ERC20 implementation, leveraging interfaces and an abstract Context contract. Code security (7.2) is strong, with appropriate use of unchecked blocks guarded by require statements to prevent integer overflows/underflows, as seen in _transfer and decreaseAllowance. Access control (7.3) for core token functions relies on msg.sender, while _mint and _burn are internal virtual, requiring derived contracts to implement specific access controls. No reentrancy or other critical code vulnerabilities were identified.

Governance1/10High risk

The contract defines basic ERC20 token economics (7.4) with a fixed decimals value of 18. The _mint and _burn functions, while internal, allow for potential supply manipulation if not properly restricted in an inheriting contract, representing a design choice for tokenomics. There are no explicit governance mechanisms (7.5) within this base contract, as expected for a foundational token contract.

Upgrades6/10Medium risk

The contract is not designed as an upgradeable proxy (7.7) itself, meaning it cannot be directly upgraded. However, its structure, including _beforeTokenTransfer and _afterTokenTransfer hooks, makes it suitable for use as an implementation contract in an upgradeable proxy system, allowing for future extensions without modifying the core logic. This design promotes extensibility and future compatibility.

Final RecommendationWhat to do about this score

Ensure that any contract inheriting from this ERC20 implementation properly secures the _mint and _burn functions with robust access control mechanisms to prevent unauthorized supply manipulation.

If the Math library is used in production, ensure its full, verified source code is available for a complete security review, especially for complex arithmetic operations like mulDiv. Adhering to these recommendations will enhance the overall security posture of the token system.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age3mo
Contract0x777b…8c28
Deployer0x7055…e6e4
Badge for your website
BabyShark 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, 202643Medium

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

Frequently Asked Questions

What is the BABYSHARK contract address?

The BabyShark contract on BNB Chain is 0x777bf78ad4546b61607a17bf4a1977dbbea98c28. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is BabyShark a scam?

Quantum Audit's risk score for BabyShark is 43/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is BABYSHARK liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $22.2K.

Who holds BABYSHARK?

As of Sep 4, 2026, the 10 largest holders own 85.0% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
GUABNB Chain43MediumTrenchesStarterPack战壕入门包 · BNB Chain43MediumChainbase TokenC · BNB Chain43MediummemestockBNB Chain43MediumGiggle CatNIANNIAN · BNB Chain43MediumUPONLYBNB Chain43Medium

Would You Like a More Detailed Audit of BabyShark?

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