Is 4 Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 Info

Critical

Incomplete ERC-20 Implementation (Non-Functional Token)

C-01The `FourERC20` contract, as provided, lacks a public constructor to initialize the token's `name` and `symbol` via `_init`. More critically, it does not expose any public or external function to call the internal `_mint` function. If this contract is deployed directly, it will result in an ERC-20 token with no name, no symbol, and a permanent zero total supply, rendering it completely non-functional and unusable. This represents a fundamental architectural flaw for a standalone token (7.1 Architecture, 7.4 Economic).

IssueThe `FourERC20` contract, as provided, lacks a public constructor to initialize the token's `name` and `symbol` via `_init`. More critically, it does not expose any public or external function to call the internal `_mint` function. If this contract is deployed directly, it will result in an ERC-20 token with no name, no symbol, and a permanent zero total supply, rendering it completely non-functional and unusable. This represents a fundamental architectural flaw for a standalone token (7.1 Architecture, 7.4 Economic).

FixA new contract should be created that inherits from `FourERC20`. This derived contract must include a public constructor that calls `_init(string memory name_, string memory symbol_)` to set the token's metadata. Additionally, it must implement a public or access-controlled function (e.g., `mint` or `initialMint`) that calls the internal `_mint(address account, uint256 amount)` to create the initial token supply and distribute it.

StatusUnresolved

Info

Contract Designed for Inheritance, Not Direct Deployment

I-01The `FourERC20` contract is structured as a base OpenZeppelin `ERC20` implementation, providing internal functions like `_init`, `_mint`, and `_burn`. This design pattern is common for creating extensible token standards. It is intended to be inherited by a derived contract that would then implement specific constructor logic and supply mechanisms (7.1 Architecture). This is not a vulnerability in itself, but a misunderstanding of this design leads directly to the critical issue of a non-functional token if deployed incorrectly.

IssueThe `FourERC20` contract is structured as a base OpenZeppelin `ERC20` implementation, providing internal functions like `_init`, `_mint`, and `_burn`. This design pattern is common for creating extensible token standards. It is intended to be inherited by a derived contract that would then implement specific constructor logic and supply mechanisms (7.1 Architecture). This is not a vulnerability in itself, but a misunderstanding of this design leads directly to the critical issue of a non-functional token if deployed incorrectly.

FixEnsure that any deployment strategy for `FourERC20` involves creating a derived contract that properly extends its functionality, specifically by implementing a constructor and a token supply mechanism. Document this design intent clearly for future developers and deployers.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract leverages well-audited OpenZeppelin ERC-20 standards, providing robust implementations for core token functionalities like transfers and allowances (7.2 Code Security). The use of `increaseAllowance` and `decreaseAllowance` mitigates common allowance front-running risks. However, the contract lacks a public constructor to initialize token metadata and a public minting mechanism, making it non-functional if deployed directly (7.1 Architecture). This design oversight prevents token creation and renders the contract unusable as a standalone ERC-20 token.

GovernanceLow8/10

The economic model is inherently flawed if the contract is deployed as-is, as no tokens can be minted, leading to a zero total supply (7.4 Economic). This directly impacts the utility and value proposition of the token, rendering it economically inert. There are no specific governance mechanisms implemented within this contract (7.5 Governance), which is typical for a base ERC-20, but the lack of a functional supply mechanism is a critical economic impediment.

UpgradesLow9/10

The contract does not implement any proxy patterns or upgrade mechanisms (7.7 Upgrades). This means the contract is immutable once deployed, preventing any future modifications to its logic. While this eliminates upgrade-related risks such as proxy misconfigurations or malicious upgrade paths, it also means any discovered issues or desired feature enhancements would require a new deployment.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

63.0% in top 10

16.1% in wallets46.9% in contracts

Effective Concentration34.9%

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

$1.43M across 16 pairs

Pancakeswap v2WBNBanalysed$1.29M Pancakeswap v3USDT$84.9K Pancakeswap v3WBNB$45.9K UniswapUSDT$4.3K Pancakeswap v3WBNB$2.8K Pancakeswap v3USDT$2.5K

Show 4 more pairsShow less

Uniswap比特币$782 Pancakeswap v3ASTER$473 Pancakeswap v3USELESS$117 Pancakeswap v3Cake$44

The 6 remaining pairs hold $26 between them and are not listed.

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 Burned99.9% · ≈ permanent lock

LP Locked99.9%

Key Addresses

10 addresses

Deployer

0x5511…7f3d

Unlocked LP Held By

0x5b8d…6ef20xdfff…a08b0x33eb…bf5b0x286b…87260x6662…c1550x40f3…0fe70x5604…8c260xed1d…751f0xd36b…6deb

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 > 30% (63.0% total → 34.9% effective; 16.1% in EOAs, 46.9% in contracts — moderate)
1 Critical 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

Is 4 Safe?