Quantum Audit Logo

Is BabyShark Safe?

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

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

BabyShark BABYSHARK
0x777b…8c28
BNB Chain Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive 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. 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.

1 Low2 Informational
Volume 24h
$196.1K
Liquidity
$22.2K
Price
$0.005925
Token Age
3mo
Top 10 Holders
85.0%

Security Findings

1 Low2 Info
Low

Centralized Minting/Burning (Design Choice)

L-01The `_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.
IssueThe `_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.
FixAny 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.
StatusUnresolved
Info

Standard ERC20 Implementation

I-01The 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.
IssueThe 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.
FixNo specific recommendation. This finding highlights a strength of the contract.
StatusUnresolved
Info

Truncated Math Library

I-02The 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.
IssueThe 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.
FixIf 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceHigh1/10

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.

UpgradesMedium6/10

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.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

85.0% in top 10
3.0% in wallets82.0% in contracts
Effective Concentration35.8%

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

$22.2K

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x7055…e6e4
Unlocked LP Held By
0x3298…ea49

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

What Raised This Score

7 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

Related Audits

6 more on the record
GUAMedium RiskTrenchesStarterPack (战壕入门包)Medium RiskChainbase Token (C)Medium RiskmemestockMedium RiskGiggle Cat (NIANNIAN)Medium Risk吉祥马Medium Risk

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