Quantum Audit Logo
Launch App

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

Is 熊猫头 Safe?

BNB 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
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical10/10Governance10/10Upgrades10/10Checks passed5 of 5Findings2 Low · 2 Info4
SummaryAI Copilot

The FourERC20 contract implements a standard ERC-20 token, largely leveraging battle-tested OpenZeppelin contracts.

Read the full analysis
What raised the score
  • Top-10 concentration > 20%
  • 2 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 20% (32.4% total → 21.9% effective; 15.0% in EOAs, 17.4% in contracts — mild)
  • 2 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 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
17.4%Contracts15.0%Wallets67.6%Everyone else
17.4%Contracts15.0%Wallets67.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
32.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking17.4%
  • Walletsanonymous holders, free to sell15.0%
  • Everyone elsethe rest of the supply67.6%
Effective concentrationwhat the score reads21.9%
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$109.3K across 2 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$109.3KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Security Findings

2 Low2 Info
Low

Incomplete Token Functionality (Base Contract)

The FourERC20 contract provides the core ERC-20 logic but lacks public functions for minting or burning tokens, and thus cannot manage its own supply. This is by design for a base contract intended to be inherited, but means it's not a fully functional, deployable token on its own without a derived contract implementing these mechanisms (7.1 Architecture).L-01

Issue

The FourERC20 contract provides the core ERC-20 logic but lacks public functions for minting or burning tokens, and thus cannot manage its own supply. This is by design for a base contract intended to be inherited, but means it's not a fully functional, deployable token on its own without a derived contract implementing these mechanisms (7.1 Architecture).

Fix

This is an architectural design choice. If a fully functional token is desired, a derived contract must be created to implement public _mint and _burn functions, along with appropriate access control for these operations.

Status

Unresolved

Low

Standard ERC-20 approve Race Condition

The approve function, while standard in ERC-20, is susceptible to a known race condition where a malicious spender can exploit a user's attempt to change an allowance. If a user first approves X, then approves Y, a front-running attacker could execute the first approval, then transfer X tokens, then execute the second approval, resulting in the attacker having Y tokens plus the X tokens from the first approval (7.2 Code Security). While increaseAllowance and decreaseAllowance are provided as mitigations, the approve function itself remains vulnerable if not used carefully by external callers.L-02

Issue

The approve function, while standard in ERC-20, is susceptible to a known race condition where a malicious spender can exploit a user's attempt to change an allowance. If a user first approves X, then approves Y, a front-running attacker could execute the first approval, then transfer X tokens, then execute the second approval, resulting in the attacker having Y tokens plus the X tokens from the first approval (7.2 Code Security). While increaseAllowance and decreaseAllowance are provided as mitigations, the approve function itself remains vulnerable if not used carefully by external callers.

Fix

Educate users to prefer increaseAllowance and decreaseAllowance over approve when modifying existing allowances. If approve must be used to change an existing allowance, it is safer to first set the allowance to zero, wait for that transaction to confirm, and then set the new allowance.

Status

Unresolved

Info

Missing Initialization Event

The _init function, which sets the token's name and symbol, does not emit an event. Emitting an event for critical initialization parameters is a best practice for transparency and off-chain indexing, allowing external systems to easily track the token's fundamental properties upon deployment (7.8 Operations).I-01

Issue

The _init function, which sets the token's name and symbol, does not emit an event. Emitting an event for critical initialization parameters is a best practice for transparency and off-chain indexing, allowing external systems to easily track the token's fundamental properties upon deployment (7.8 Operations).

Fix

Consider emitting an event, such as Initialized(string name, string symbol), within the _init function to provide a clear, immutable record of the token's initial configuration.

Status

Unresolved

Info

Absence of Operational Roles

The contract does not implement any specific operational roles such as owner, pauser, or minter. This means there are no centralized controls for emergency actions like pausing transfers or managing token supply, which might be desired for a production token (7.3 Access Control, 7.8 Operations). This is a design choice for a base contract.I-02

Issue

The contract does not implement any specific operational roles such as owner, pauser, or minter. This means there are no centralized controls for emergency actions like pausing transfers or managing token supply, which might be desired for a production token (7.3 Access Control, 7.8 Operations). This is a design choice for a base contract.

Fix

If centralized control or emergency mechanisms are required for the deployed token, a derived contract should implement appropriate access control patterns (e.g., OpenZeppelin's Ownable or AccessControl) and integrate functionalities like Pausable.

Status

Unresolved

Analysis

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

The FourERC20 contract implements a standard ERC-20 token, largely leveraging battle-tested OpenZeppelin contracts. It provides core token functionalities but is designed as a base contract, meaning it lacks public supply management (mint/burn) and operational roles. The code quality is high, and no critical vulnerabilities were identified. The identified issues are primarily informational or related to inherent ERC-20 design considerations.

Technical10/10Low risk

The contract is a robust implementation of the ERC-20 standard, inheriting from OpenZeppelin's Context and implementing IERC20 and IERC20Metadata. It correctly handles arithmetic operations using Solidity 0.8.0+'s default checked math, with a safe unchecked block in decreaseAllowance (7.2 Code Security). The use of _msgSender() for sender identification is appropriate. However, as a base contract, it does not include public minting/burning functions (7.1 Architecture), requiring a derived contract for full functionality.

Governance10/10Low risk

The FourERC20 contract is a foundational token implementation and does not include any specific governance or economic mechanisms (7.5 Governance, 7.4 Economic). There are no fees, staking, or voting functionalities. The absence of an owner or other administrative roles means there is no centralized control over the token's operational aspects, which is a design choice for a base contract (7.3 Access Control).

Upgrades10/10Low risk

The contract is not explicitly designed as an upgradeable proxy, and no proxy pattern is implemented (7.7 Upgrades). While it includes an internal _init function, which is common in upgradeable contracts, without a proxy wrapper, the contract itself is not upgradeable. Any future upgradeability would require deploying a separate proxy contract and linking this implementation.

Final RecommendationWhat to do about this score

For deployment, ensure a derived contract properly implements token supply mechanisms (minting/burning) and defines appropriate access control roles (e.g., Ownable, AccessControl) if centralized management is desired.

Consider adding events for all critical state changes, especially initialization parameters, to enhance transparency and off-chain monitoring. Users interacting with the approve function should be aware of the standard ERC-20 race condition and prefer increaseAllowance and decreaseAllowance where possible.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age10mo
Contract0xf352…4444
Deployer0xc142…da7e
Badge for your website
熊猫头 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. Aug 14, 20260Low

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

Frequently Asked Questions

What is the 熊猫头 contract address?

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

Is 熊猫头 a scam?

Quantum Audit's risk score for 熊猫头 is 0/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is 熊猫头 liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $109.3K.

Who holds 熊猫头?

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

Related Audits

6 more on the recordAll audits
TCryptochicksTCC · BNB Chain0Low币安人生BNB Chain0LowSKYAIBNB Chain0LowBBNB Chain0LowDOYRBNB Chain0LowCREPEBNB Chain0Low

Would You Like a More Detailed Audit of 熊猫头?

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