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
Technical9/10Governance7/10Upgrades10/10Checks passed5 of 5Findings1 High · 1 Low · 1 Info3
SummaryAI Copilot

The audited contract, FourERC20, is an implementation of the ERC-20 token standard, largely based on OpenZeppelin Contracts.

Read the full analysis
What raised the score
  • Top-10 concentration > 50%
  • 1 High finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 50% (85.6% total → 52.5% effective; 30.5% in EOAs, 55.1% in contracts — heavy)
  • 1 High 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

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
55.1%Contracts30.5%Wallets14.4%Everyone else
55.1%Contracts30.5%Wallets14.4%
ContractsWalletsEveryone elseBubble area = share of supply
85.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking55.1%
  • Walletsanonymous holders, free to sell30.5%
  • Everyone elsethe rest of the supply14.4%
Effective concentrationwhat the score reads52.5%
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$2.24M across 8 pairs
Show 2 more pairs

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$2.21MShare of depth98.3%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address
Unlocked LP held by
0x87ee…48ff0xfe73…147a

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

Security Findings

1 High1 Low1 Info
High

Missing Access Control for Supply Management Functions

The _mint and _burn functions, which control the total supply of the token, are implemented as internal functions in the FourERC20 base contract. However, the contract does not provide any built-in access control mechanisms (e.g., onlyOwner, onlyRole) to restrict who can call these functions when they are exposed by a derived contract. If a derived contract exposes mint() or burn() functions without proper authorization checks, any external caller could potentially mint an arbitrary amount of tokens or burn existing tokens, leading to a complete loss of token value and integrity (7.3 Access Control, 7.4 Economic).H-01

Issue

The _mint and _burn functions, which control the total supply of the token, are implemented as internal functions in the FourERC20 base contract. However, the contract does not provide any built-in access control mechanisms (e.g., onlyOwner, onlyRole) to restrict who can call these functions when they are exposed by a derived contract. If a derived contract exposes mint() or burn() functions without proper authorization checks, any external caller could potentially mint an arbitrary amount of tokens or burn existing tokens, leading to a complete loss of token value and integrity (7.3 Access Control, 7.4 Economic).

Fix

Any contract inheriting from FourERC20 and exposing _mint or _burn functionality must implement strong access control. Utilize established patterns like OpenZeppelin's Ownable or AccessControl to ensure that only authorized addresses or roles can execute these critical supply-altering functions. For example, add an onlyOwner modifier to the public mint and burn functions in the derived contract.

Status

Unresolved

Low

Reliance on Derived Contract for Initialization

The _init function, responsible for setting the token's _name and _symbol, is an internal function. This design requires any contract inheriting from FourERC20 to explicitly call _init in its constructor. Failure to call _init in the derived contract's constructor would result in the token having empty strings for its name and symbol, which could lead to display issues in wallets and interfaces (7.1 Architecture).L-01

Issue

The _init function, responsible for setting the token's _name and _symbol, is an internal function. This design requires any contract inheriting from FourERC20 to explicitly call _init in its constructor. Failure to call _init in the derived contract's constructor would result in the token having empty strings for its name and symbol, which could lead to display issues in wallets and interfaces (7.1 Architecture).

Fix

Ensure that any derived contract explicitly calls _init(string memory name_, string memory symbol_) in its constructor to properly set the token's metadata. For example: `constructor(string memory name_, string memory symbol_) { _init(name_, symbol_); }`.

Status

Unresolved

Info

Unchecked Arithmetic for _totalSupply

The _totalSupply variable is updated within unchecked blocks in both the _mint and _burn functions. While Solidity 0.8.0 and later versions automatically include overflow/underflow checks by default, unchecked blocks explicitly disable these checks. Although _balances updates are not in unchecked blocks and are protected, _totalSupply could theoretically overflow or underflow if an extremely large amount is passed to _mint or _burn without prior validation, potentially leading to an inconsistent state between _totalSupply and the sum of _balances (7.2 Code Security).I-01

Issue

The _totalSupply variable is updated within unchecked blocks in both the _mint and _burn functions. While Solidity 0.8.0 and later versions automatically include overflow/underflow checks by default, unchecked blocks explicitly disable these checks. Although _balances updates are not in unchecked blocks and are protected, _totalSupply could theoretically overflow or underflow if an extremely large amount is passed to _mint or _burn without prior validation, potentially leading to an inconsistent state between _totalSupply and the sum of _balances (7.2 Code Security).

Fix

While the risk is low given the typical use of _mint and _burn with controlled amounts and the protection on individual balances, consider whether the unchecked block for _totalSupply is strictly necessary. If _totalSupply is intended to always reflect the sum of balances, ensuring it also benefits from default overflow/underflow checks could provide an additional layer of safety, or ensure robust validation of amount before calling _mint/_burn.

Status

Unresolved

Analysis

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

The audited contract, FourERC20, is an implementation of the ERC-20 token standard, largely based on OpenZeppelin Contracts. It provides core token functionalities such as transfers, allowances, minting, and burning. The contract itself is a base implementation, meaning it relies on derived contracts to expose administrative functions like minting and burning with appropriate access control. While the core logic is robust, the absence of built-in access control for these critical functions in the base contract necessitates careful implementation in any inheriting contract to prevent severe vulnerabilities.

Technical9/10Low risk

The FourERC20 contract leverages OpenZeppelin's battle-tested ERC-20 implementation, ensuring a high standard of code security for core token operations (7.2 Code Security). Solidity 0.8+ provides automatic overflow/underflow checks, enhancing arithmetic safety. However, the base contract lacks explicit access control for critical supply management functions like _mint and _burn (7.3 Access Control). This design choice places the full responsibility on derived contracts to implement robust access control, which, if overlooked, could lead to severe vulnerabilities.

Governance7/10Low risk

The FourERC20 contract, as a base ERC-20 implementation, does not include any inherent governance or economic mechanisms (7.5 Governance, 7.4 Economic). Its economic model, including total supply management (minting/burning), is entirely dependent on how a derived contract implements and exposes these functions. The absence of built-in access control for _mint and _burn in this base contract presents a significant economic risk, as an improperly secured derived contract could allow unauthorized supply manipulation, devaluing the token.

Upgrades10/10Low risk

The FourERC20 contract is not designed as an upgradeable proxy contract (7.7 Upgrades). It is intended to be deployed as a standalone token or as an implementation contract for a proxy pattern, though no proxy-specific logic is included. The internal _init function is a common pattern for initializable contracts, but without a proxy, upgrade safety is not a direct concern for this specific codebase.

Final RecommendationWhat to do about this score

It is crucial for any contract inheriting from FourERC20 to implement robust access control mechanisms for administrative functions, particularly _mint and _burn.

Consider using established patterns like OpenZeppelin's Ownable or AccessControl to restrict who can perform these sensitive operations. Thoroughly test the derived contract's constructor to ensure _init is called correctly and that the token's name and symbol are properly set. Additionally, review the unchecked blocks for _totalSupply updates to ensure they align with the intended security model of the derived contract.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age5mo
Contract0xeccb…4444
Deployer0xfdae…92af
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. Sep 4, 20260Low
  2. Aug 12, 202624Low

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

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