Is 错版马 (哭哭马) Safe? Smart Contract Security Analysis

Security Findings

2 Low1 Info

Low

Potential Re-initialization in Proxy Context

L-01The `_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.

IssueThe `_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.

FixIf 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.

StatusUnresolved

Low

Standard ERC-20 `approve` Front-Running Risk

L-02The 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.

IssueThe 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.

FixWhile 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.

StatusUnresolved

Info

Incomplete Token Implementation

I-01The 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.

IssueThe 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.

FixEnsure 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.

StatusUnresolved

Category Ratings

TechnicalLow10/10

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.

GovernanceLow10/10

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.

UpgradesLow10/10

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.

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

47.0% in top 10

3.7% in wallets43.2% in contracts

Effective Concentration21.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

$477.1K across 4 pairs

Pancakeswap v2WBNBanalysed$464.2K UniswapUSDT$11.9K UniswapUSDT$931 Pancakeswap v3WBNB$45

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%

Key Addresses

10 addresses

Deployer

0x67a5…1683

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.

What Raised This Score

2 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

Final Recommendation

AI Copilot

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.…

Read the verdictHide

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

TypeToken

Audit History

1 audit on record

Sep 30

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

Is 错版马 Safe?

Security Findings

Potential Re-initialization in Proxy Context

Standard ERC-20 `approve` Front-Running Risk

Incomplete Token Implementation

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of 错版马?