The FourERC20 contract provides a standard ERC-20 token implementation based on OpenZeppelin's well-audited contracts. The core token functionalities are robust. However, as a base contract, it lacks specific minting/burning mechanisms and initial supply definition, which would be critical for a complete token system. Potential re-initialization issues exist if used in an upgradeable proxy context without modification. Overall, the technical risk is low for the provided code.

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 provides a standard ERC-20 token implementation based on OpenZeppelin's well-audited contracts.
Read the full analysis- Top-10 concentration > 20%
- 2 Low finding(s) from audit
Exact 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
Security Checklist
as of audit · Sep 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking43.2%
- Walletsanonymous holders, free to sell3.7%
- Everyone elsethe rest of the supply53.0%
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$464.2K97.3%
- UniswapUSDT$11.9K2.5%
- UniswapUSDT$9310.2%
- Pancakeswap v3WBNB$450.0%
The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0x4b05…74130x0ed9…97060xca4c…2d080xf864…777e0xc8ca…714a0xc78d…62590xb878…0a440xa970…d8850xa4d4…1102No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
LowPotential Re-initialization in Proxy Context
The _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.L-01
Issue
The _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.
Fix
If 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.
Status
Unresolved
LowStandard ERC-20 approve Front-Running Risk
The 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.L-02
approve Front-Running RiskIssue
The 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.
Fix
While 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.
Status
Unresolved
InfoIncomplete Token Implementation
The 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.I-01
Issue
The 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.
Fix
Ensure 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.
Status
Unresolved
Analysis
AI Copilotas of audit · Sep 4The 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.
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.
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.
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.
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 & 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 3, 20260Low
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