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.

On-chain security analysis — is it a scam or legit?
Is 我踏马来了 Safe?
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 →The FourERC20 contract implements a standard ERC-20 token, largely leveraging well-audited OpenZeppelin Contracts.
Read the full analysis- 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 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking58.1%
- Walletsanonymous holders, free to sell27.2%
- Everyone elsethe rest of the supply14.8%
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- Pancakeswap v2WBNBAnalysed$926.1K83.7%
- Pancakeswap v3WBNB$97.8K8.8%
- UniswapUSDT$80.3K7.3%
- Pancakeswap v3USDT$1.4K0.1%
- UniswapUSDT$4310.0%
- Pancakeswap v2USDT$140.0%
Show 2 more pairs
The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0xefba…a0770x7836…cbb30xd3a5…726b0xfacd…2a140x6756…5a91No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
LowUninitialized 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
InfoReliance 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
InfoFixed 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
InfoUnused _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
_contextSuffixLength FunctionIssue
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 4The 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.
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.
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.
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
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 4, 20260Low
- 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