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 implements a standard ERC-20 token, largely leveraging well-audited OpenZeppelin Contracts.

Read the full analysis
What raised the score
  • Top-10 concentration > 50%
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
58.1%Contracts27.2%Wallets14.8%Everyone else
58.1%Contracts27.2%Wallets14.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
85.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking58.1%
  • Walletsanonymous holders, free to sell27.2%
  • Everyone elsethe rest of the supply14.8%
Effective concentrationwhat the score reads50.4%
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$1.11M across 8 pairs
LP tokensLocked

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

Analysed pool$926.1KShare of depth83.7%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address
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.

Security Findings

1 Low3 Info
Low

Uninitialized Token Metadata

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

Issue

The _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.

Fix

Implement 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_); } ```

Status

Unresolved

Info

Reliance on OpenZeppelin Standard Implementation

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

Issue

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

Fix

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

Status

Resolved

Info

Fixed Supply Mechanism (in FourERC20)

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

Issue

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

Fix

Clearly 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).

Status

Unresolved

Info

Unused _contextSuffixLength Function

The _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.I-03

Issue

The _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.

Fix

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

Status

Resolved

Analysis

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

The FourERC20 contract implements a standard ERC-20 token, largely leveraging well-audited OpenZeppelin Contracts. The core functionality for transfers and allowances is robust. However, the token's metadata (name and symbol) is not initialized within the contract, and there are no public minting or burning mechanisms, indicating a fixed supply model unless extended by a derived contract. The overall technical risk is low due to the use of battle-tested libraries, but deployment considerations for metadata initialization are important.

Technical10/10Low risk

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.

Governance8/10Low risk

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.

Upgrades10/10Low risk

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.

Final RecommendationWhat to do about this score

It is recommended to ensure that the _init function is properly called in a constructor of a derived contract or during deployment to set the token's name and symbol, ensuring full ERC-20 compliance and usability.

For any future extensions, carefully consider the implementation of minting/burning mechanisms with appropriate access control. Thoroughly test any integrations with external protocols to ensure compatibility and security.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age7mo
Contract0xc51a…4444
Deployer0x03b2…84e2
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 4, 20260Low
  2. Aug 12, 202618Low

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