Quantum Audit Logo

Is 龙虾 Safe?

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

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

龙虾 龙虾
0xeccb…4444
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

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.

1 High1 Low1 Informational
Volume 24h
$1.76M
Liquidity
$2.21M
Price
$0.07323
Token Age
5mo
Top 10 Holders
85.6%

Security Findings

1 High1 Low1 Info
High

Missing Access Control for Supply Management Functions

H-01The `_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).
IssueThe `_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).
FixAny 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.
StatusUnresolved
Low

Reliance on Derived Contract for Initialization

L-01The `_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).
IssueThe `_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).
FixEnsure 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_); }`.
StatusUnresolved
Info

Unchecked Arithmetic for `_totalSupply`

I-01The `_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).
IssueThe `_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).
FixWhile the risk is low given the typical use of `_mint` and `_burn` with controlled `amount`s 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`.
StatusUnresolved

Category Ratings

TechnicalLow9/10

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.

GovernanceLow7/10

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.

UpgradesLow10/10

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.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

85.6% in top 10
30.5% in wallets55.1% in contracts
Effective Concentration52.5%

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

$2.24M across 8 pairs
Pancakeswap v2WBNBanalysed$2.21M98.3%UniswapUSDT$33.1K1.5%Pancakeswap v3USDT$2.7K0.1%UniswapUSDT$1.8K0.1%Pancakeswap v3USDT$5210.0%Pancakeswap v3WBNB$460.0%
Show 2 more pairsShow less
Pancakeswap v3WBNB$140.0%Pancakeswap v2USDT$30.0%

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 Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

3 addresses
Deployer
0xfdae…92af
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.

What Raised This Score

3 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

Related Audits

6 more on the record
TCryptochicks (TCC)Low Risk币安人生Low RiskSKYAILow RiskBLow RiskDOYRLow RiskCREPELow Risk

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