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 →

老子 老子
0x1a5f…4444
BNB Chain
Not verifiedThis 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 9d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The FourERC20 contract is a standard implementation of the ERC-20 token interface, leveraging well-audited OpenZeppelin Contracts. It provides core token functionalities like transfers, allowances, and balance tracking. The contract itself does not expose public minting or burning mechanisms, meaning its supply is fixed at zero unless extended by a derived contract. Overall, the code quality is high, and no critical vulnerabilities were identified.

2 Low2 Informational
Volume 24h
$525.1K
Liquidity
$277.6K
Price
$0.001435
Token Age
8mo
Top 10 Holders
86.5%

Security Findings

2 Low2 Info
Low

Potential Centralization of Supply Control (if extended)

L-01As a base ERC-20 contract, `FourERC20` does not expose minting or burning. However, if a derived contract were to implement public `mint` and `burn` functions, these would typically be controlled by a single `owner` or `minter` address. This centralization of control over the token supply could pose a risk if the controlling address is compromised or acts maliciously, allowing arbitrary minting or burning.
IssueAs a base ERC-20 contract, `FourERC20` does not expose minting or burning. However, if a derived contract were to implement public `mint` and `burn` functions, these would typically be controlled by a single `owner` or `minter` address. This centralization of control over the token supply could pose a risk if the controlling address is compromised or acts maliciously, allowing arbitrary minting or burning.
FixIf a derived contract introduces minting/burning, consider implementing a multi-signature wallet for the controlling address or a time-locked mechanism for significant supply changes to reduce the risk of a single point of failure and enhance transparency.
StatusUnresolved
Low

Standard ERC-20 `approve` Race Condition

L-02The `approve` function, while standard for ERC-20, is susceptible to a known front-running vulnerability. If a user approves an amount `X` for a spender, and then decides to change it to `Y` by sending another `approve(spender, Y)` transaction, a malicious spender could front-run the second transaction. The spender could spend `X` tokens after the first `approve` but before the second `approve` is mined, then the second `approve` would set the allowance to `Y`, allowing the spender to potentially spend `X + Y` tokens if `Y` is also a significant amount.
IssueThe `approve` function, while standard for ERC-20, is susceptible to a known front-running vulnerability. If a user approves an amount `X` for a spender, and then decides to change it to `Y` by sending another `approve(spender, Y)` transaction, a malicious spender could front-run the second transaction. The spender could spend `X` tokens after the first `approve` but before the second `approve` is mined, then the second `approve` would set the allowance to `Y`, allowing the spender to potentially spend `X + Y` tokens if `Y` is also a significant amount.
FixUsers should be advised to use `increaseAllowance` and `decreaseAllowance` functions when modifying allowances, as these functions are designed to mitigate this specific race condition. If `approve` must be used, users should first set the allowance to zero and wait for that transaction to confirm before setting a new allowance.
StatusUnresolved
Info

Incomplete Token Functionality (No Public Mint/Burn)

I-01The `FourERC20` contract provides internal `_mint` and `_burn` functions but does not expose any public methods to call them. This means the token's `_totalSupply` will remain zero and no tokens can be created or destroyed unless a derived contract implements a public minting mechanism. This is a design choice, not a vulnerability, but it's crucial for functionality.
IssueThe `FourERC20` contract provides internal `_mint` and `_burn` functions but does not expose any public methods to call them. This means the token's `_totalSupply` will remain zero and no tokens can be created or destroyed unless a derived contract implements a public minting mechanism. This is a design choice, not a vulnerability, but it's crucial for functionality.
FixIf the intention is for this contract to be a standalone, functional token with a supply, a derived contract must be deployed that exposes minting and/or burning capabilities, typically with appropriate access control. If it's intended purely as a base for other contracts, this design is acceptable.
StatusUnresolved
Info

`_init` Function Design for Non-Proxy Context

I-02The `_init` function is an internal function designed to set the token's name and symbol. While this is standard for OpenZeppelin's `ERC20` base, its internal nature means it must be called from a constructor of a derived contract. If this contract were ever to be used as an implementation for an upgradeable proxy, the `_init` function would need to be renamed to `initialize` and include an `initializer` modifier to prevent multiple calls.
IssueThe `_init` function is an internal function designed to set the token's name and symbol. While this is standard for OpenZeppelin's `ERC20` base, its internal nature means it must be called from a constructor of a derived contract. If this contract were ever to be used as an implementation for an upgradeable proxy, the `_init` function would need to be renamed to `initialize` and include an `initializer` modifier to prevent multiple calls.
FixGiven that the contract is not a proxy (`is_proxy: false`), this is not a direct vulnerability. However, if future plans involve upgradeability, ensure proper initialization patterns (e.g., `initialize` function with `initializer` modifier) are adopted to prevent re-initialization attacks.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1) of the FourERC20 contract is robust, built upon the battle-tested OpenZeppelin ERC-20 standard. It correctly implements all required ERC-20 functions and includes additional safety features like `increaseAllowance` and `decreaseAllowance` to mitigate common allowance-related issues. Code security (7.2) is strong, benefiting from Solidity 0.8+ default overflow/underflow checks and careful use of `unchecked` blocks where safety is guaranteed, such as in `decreaseAllowance` after a `require` check. Access control (7.3) for core functions is standard ERC-20, while internal minting/burning functions (`_mint`, `_burn`) are not publicly exposed, requiring a derived contract for supply management.

GovernanceLow8/10

The contract's economic model (7.4) is straightforward, as it's a basic ERC-20 token without complex DeFi primitives or fee structures. The token supply is initially zero and fixed, as no public minting or burning mechanisms are exposed. If a derived contract were to introduce such mechanisms, the economic risk would depend on the access control implemented for those functions (L-01). There are no governance (7.5) features within this contract, simplifying its operational overhead (7.8) and reducing associated risks.

UpgradesLow10/10

The FourERC20 contract is not designed as an upgradeable proxy (7.7). The `is_proxy: false` flag in the provided context confirms this. Therefore, there are no upgrade-specific risks to assess. The internal `_init` function, while common in upgradeable patterns, is not a vulnerability in a non-proxy context (I-02).

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

86.5% in top 10
33.9% in wallets52.5% in contracts
Effective Concentration55.0%

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

$282.6K across 5 pairs
Pancakeswap v2WBNBanalysed$277.6K98.2%UniswapUSDT$4.9K1.7%Pancakeswap v3USDT$510.0%Pancakeswap v2USDT$00.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

2 addresses
Deployer
0x3ef8…8766
Unlocked LP Held By
0x0ed9…9706

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

What Raised This Score

2 factors
  • Top-10 concentration > 50% (86.5% total → 55.0% effective; 33.9% in EOAs, 52.5% in contracts — heavy)
  • 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

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