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
SummaryAI Copilot

The FourERC20 contract provides a standard ERC-20 token implementation based on OpenZeppelin's well-audited 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% (47.0% total → 21.0% effective; 3.7% in EOAs, 43.2% 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 47 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
43.2%Contracts3.7%53.0%Everyone else
43.2%Contracts3.7%53.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
47.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking43.2%
  • Walletsanonymous holders, free to sell3.7%
  • Everyone elsethe rest of the supply53.0%
Effective concentrationwhat the score reads21.0%
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$477.1K across 4 pairs
LP tokensLocked

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

Analysed pool$464.2KShare of depth97.3%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0%
Unlocked LP held by
0x4b05…74130x0ed9…97060xca4c…2d080xf864…777e0xc8ca…714a0xc78d…62590xb878…0a440xa970…d8850xa4d4…1102

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

Security Findings

2 Low1 Info
Low

Potential Re-initialization in Proxy Context

The _init function, which sets the token's name and symbol, is an internal function. If this FourERC20 contract were to be used as an implementation contract in an upgradeable proxy pattern (e.g., UUPS or Transparent), this _init function could be called multiple times by malicious actors after deployment, leading to re-initialization of state variables. While the provided context states is_proxy: false, this is a common vulnerability when base contracts are repurposed for upgradeable systems without modification.L-01

Issue

The _init function, which sets the token's name and symbol, is an internal function. If this FourERC20 contract were to be used as an implementation contract in an upgradeable proxy pattern (e.g., UUPS or Transparent), this _init function could be called multiple times by malicious actors after deployment, leading to re-initialization of state variables. While the provided context states is_proxy: false, this is a common vulnerability when base contracts are repurposed for upgradeable systems without modification.

Fix

If this contract is intended to be used as an implementation for an upgradeable proxy, the _init function should be renamed to initialize and protected with OpenZeppelin's initializer modifier. This modifier ensures the function can only be called once, preventing re-initialization attacks.

Status

Unresolved

Low

Standard ERC-20 approve Front-Running Risk

The standard ERC-20 approve function is susceptible to a known front-running vulnerability. If a user approves an amount, and then attempts to change that approved amount to a different value, a malicious actor observing the transaction can front-run the second approve call. This allows the attacker to spend the original approved amount before the new approval takes effect, and then also spend the newly approved amount.L-02

Issue

The standard ERC-20 approve function is susceptible to a known front-running vulnerability. If a user approves an amount, and then attempts to change that approved amount to a different value, a malicious actor observing the transaction can front-run the second approve call. This allows the attacker to spend the original approved amount before the new approval takes effect, and then also spend the newly approved amount.

Fix

While the contract includes increaseAllowance and decreaseAllowance functions to mitigate this, users should be educated to use these functions instead of directly calling approve to modify an existing allowance. If approve must be used to change an allowance, it is safer to first set the allowance to zero and wait for that transaction to confirm before setting the new allowance.

Status

Unresolved

Info

Incomplete Token Implementation

The provided FourERC20 contract is a base implementation of the ERC-20 standard. It includes core functionalities like transfers and allowances but lacks concrete mechanisms for initial supply, minting, or burning tokens. These critical functionalities are left to be implemented in a derived contract via the _mint and _burn internal virtual functions.I-01

Issue

The provided FourERC20 contract is a base implementation of the ERC-20 standard. It includes core functionalities like transfers and allowances but lacks concrete mechanisms for initial supply, minting, or burning tokens. These critical functionalities are left to be implemented in a derived contract via the _mint and _burn internal virtual functions.

Fix

Ensure that any derived contract implementing the _mint and _burn functions incorporates robust access control, supply caps, and other necessary security measures to prevent unauthorized token creation or destruction. A complete audit of the derived contract will be essential to assess the full security posture of the token.

Status

Unresolved

Analysis

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

The FourERC20 contract provides a standard ERC-20 token implementation based on OpenZeppelin's well-audited contracts. The core token functionalities are robust. However, as a base contract, it lacks specific minting/burning mechanisms and initial supply definition, which would be critical for a complete token system. Potential re-initialization issues exist if used in an upgradeable proxy context without modification. Overall, the technical risk is low for the provided code.

Technical10/10Low risk

The contract (7.1 Architecture) is a standard ERC-20 implementation, inheriting from OpenZeppelin's battle-tested contracts, which contributes to high code quality and security. (7.2 Code Security) It correctly uses Solidity 0.8.0+ checked arithmetic, with a safe unchecked block in decreaseAllowance. (7.3 Access Control) Access control for core ERC-20 functions is standard and secure, relying on _msgSender(). (7.6 External) There are no external calls to untrusted contracts. (7.8 Operations) No specific operational roles are defined within this base contract.

Governance10/10Low risk

As a base ERC-20 contract, FourERC20 does not define specific (7.4 Economic) tokenomics, such as initial supply, minting, or burning mechanisms. These critical aspects would be implemented in a derived contract, making a full economic assessment impossible at this level. (7.5 Governance) No governance mechanisms are present within this contract, as it focuses solely on the core token functionality. The economic and governance risks are low for the provided code, but depend heavily on the inheriting contract's implementation.

Upgrades10/10Low risk

The contract is not designed as an upgradeable proxy (7.7 Upgrades). The _init function, which sets immutable token properties, is an internal function. If this contract were to be used as an implementation for an upgradeable proxy, _init would need to be replaced with an initialize function protected by an initializer modifier to prevent re-initialization attacks. Given the is_proxy: false status, the upgradeability risk for this specific contract is low, but it highlights a common pitfall.

Final RecommendationWhat to do about this score

It is recommended to thoroughly audit any derived contracts that implement the minting, burning, and initial supply logic, as these will define the complete token's security and economic model.

If this contract is intended for use as an implementation in an upgradeable proxy system, ensure the _init function is properly secured against multiple calls by converting it to an initialize function with an initializer modifier. Users should be aware of the standard ERC-20 approve front-running risk, although increaseAllowance and decreaseAllowance provide safer alternatives.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age7mo
Contract0x671e…4444
Deployer0x67a5…1683
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 3, 20260Low

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

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