Is 我踏马来了 Safe? Smart Contract Security Analysis

Security Findings

1 Low3 Info

Low

Uninitialized Token Metadata

L-01The `_init` function, which is responsible for setting the token's `_name` and `_symbol`, is declared as `internal` but is not called by a constructor within the `FourERC20` contract. If `FourERC20` is deployed directly without a derived contract calling `_init` in its constructor, the token's name and symbol will remain empty strings. This impacts the token's usability and display in wallets and explorers, potentially causing confusion or misrepresentation.

IssueThe `_init` function, which is responsible for setting the token's `_name` and `_symbol`, is declared as `internal` but is not called by a constructor within the `FourERC20` contract. If `FourERC20` is deployed directly without a derived contract calling `_init` in its constructor, the token's name and symbol will remain empty strings. This impacts the token's usability and display in wallets and explorers, potentially causing confusion or misrepresentation.

FixImplement a constructor in `FourERC20` or a derived contract that calls `_init(string memory name_, string memory symbol_)` to ensure the token's metadata is properly set upon deployment. For example: ```solidity constructor(string memory name_, string memory symbol_) { _init(name_, symbol_); } ```

StatusUnresolved

Info

Reliance on OpenZeppelin Standard Implementation

I-01The `FourERC20` contract is largely based on the OpenZeppelin Contracts (v4.9.4) ERC-20 implementation. This foundation provides a high degree of security due to extensive audits, community review, and battle-testing of the OpenZeppelin library, significantly reducing the likelihood of common vulnerabilities like reentrancy or integer overflows.

IssueThe `FourERC20` contract is largely based on the OpenZeppelin Contracts (v4.9.4) ERC-20 implementation. This foundation provides a high degree of security due to extensive audits, community review, and battle-testing of the OpenZeppelin library, significantly reducing the likelihood of common vulnerabilities like reentrancy or integer overflows.

FixContinue to leverage well-audited and maintained libraries like OpenZeppelin. Ensure that any custom logic added to derived contracts maintains the same high security standards.

StatusResolved

Info

Fixed Supply Mechanism (in FourERC20)

I-02The `FourERC20` contract, as provided, does not expose any public functions for minting or burning tokens. The `_mint` and `_burn` functions are internal, meaning that the total supply of the token is fixed after its initial deployment (assuming an initial mint is performed in a constructor or derived contract). This design choice impacts the token's economic model and prevents dynamic supply adjustments without further contract extensions.

IssueThe `FourERC20` contract, as provided, does not expose any public functions for minting or burning tokens. The `_mint` and `_burn` functions are internal, meaning that the total supply of the token is fixed after its initial deployment (assuming an initial mint is performed in a constructor or derived contract). This design choice impacts the token's economic model and prevents dynamic supply adjustments without further contract extensions.

FixClearly document the intended supply mechanism (fixed, capped, or elastic) for the token. If a dynamic supply is desired, a derived contract must implement and expose minting/burning functions with appropriate access control (e.g., using `Ownable` or a governance mechanism).

StatusUnresolved

Info

Unused `_contextSuffixLength` Function

I-03The `_contextSuffixLength()` function, inherited from the `Context` contract, is present in `FourERC20` but returns 0 and is not explicitly utilized within the contract's logic. While harmless, it represents a minor piece of unused code from the inherited library.

IssueThe `_contextSuffixLength()` function, inherited from the `Context` contract, is present in `FourERC20` but returns 0 and is not explicitly utilized within the contract's logic. While harmless, it represents a minor piece of unused code from the inherited library.

FixNo action is strictly required as this is part of the OpenZeppelin library's design for potential meta-transaction handling. It can be ignored or, if desired, the `Context` contract could be replaced with a more minimal version if meta-transaction support is not needed and gas optimization is critical.

StatusResolved

Category Ratings

TechnicalLow10/10

The contract (7.1 Architecture, 7.2 Code Security) is built upon OpenZeppelin's battle-tested ERC-20 implementation (v4.9.4), which provides a strong foundation for security, including robust handling of integer arithmetic and standard ERC-20 behaviors. The use of `_msgSender()` supports meta-transactions. A minor issue (7.8 Operations) is that the `_init` function, responsible for setting the token's name and symbol, is internal and not called by a constructor, meaning the token will lack proper metadata if deployed directly. Additionally, the `_contextSuffixLength` function from the inherited `Context` contract is present but unused.

GovernanceLow8/10

The FourERC20 contract (7.4 Economic, 7.5 Governance) does not implement any governance mechanisms or explicit owner roles, aligning with the prefill information that ownership is renounced. The contract also lacks public minting or burning functions, implying a fixed supply model after initial deployment. This design choice means the token's economic parameters are static within this contract, reducing the attack surface related to supply manipulation, but requiring external mechanisms if dynamic supply is desired.

UpgradesLow10/10

The contract (7.7 Upgrades) is not designed with an upgrade proxy pattern, meaning it is immutable once deployed. This eliminates upgrade-related risks such as proxy misconfigurations or logic errors during upgrades, but also means any discovered vulnerabilities or desired feature changes 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

85.2% in top 10

27.2% in wallets58.1% in contracts

Effective Concentration50.4%

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.11M across 8 pairs

Pancakeswap v2WBNBanalysed$926.1K Pancakeswap v3WBNB$97.8K UniswapUSDT$80.3K Pancakeswap v3USDT$1.4K UniswapUSDT$431 Pancakeswap v2USDT$14

Show 2 more pairsShow less

Pancakeswap v3USDT$2 Uniswap v2USDT$1

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

6 addresses

Deployer

0x03b2…84e2

Unlocked LP Held By

0xefba…a0770x7836…cbb30xd3a5…726b0xfacd…2a140x6756…5a91

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% (85.2% total → 50.4% effective; 27.2% in EOAs, 58.1% in contracts — heavy)
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

Is 我踏马来了 Safe?

Security Findings

Uninitialized Token Metadata

Reliance on OpenZeppelin Standard Implementation

Fixed Supply Mechanism (in FourERC20)

Unused `_contextSuffixLength` Function

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 我踏马来了?