Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is MarsCoin Safe?

MARSCOINBNB 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
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance5/10Upgrades9/10Checks passed5 of 5Findings1 Critical · 1 Low · 1 Info3
SummaryAI Copilot

The FourERC20 contract implements a standard ERC-20 token based on OpenZeppelin's audited codebase.

Read the full analysis
What raised the score
  • Top-10 concentration > 70%
  • 1 Critical finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 70% (85.2% total → 77.5% effective; 72.4% in EOAs, 12.7% in contracts — extreme)
  • 1 Critical finding(s) from audit
  • 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
12.7%Contracts72.4%Wallets14.8%Everyone else
12.7%Contracts72.4%Wallets14.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
85.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking12.7%
  • Walletsanonymous holders, free to sell72.4%
  • Everyone elsethe rest of the supply14.8%
Effective concentrationwhat the score reads77.5%
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$148.1K

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$148.1KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Security Findings

1 Critical1 Low1 Info
Critical

Uninitialized Token State on Direct Deployment

The FourERC20 contract lacks a public constructor to initialize its state variables. The _init function, which sets the token's _name and _symbol, is internal and is not called within the contract itself. Furthermore, there are no public minting functions. If this contract is deployed directly, the _name, _symbol, and _totalSupply will remain empty or zero, rendering the token completely non-functional and unusable as an ERC-20 token. This is a critical functional flaw (7.1 Architecture, 7.8 Operations).C-01

Issue

The FourERC20 contract lacks a public constructor to initialize its state variables. The _init function, which sets the token's _name and _symbol, is internal and is not called within the contract itself. Furthermore, there are no public minting functions. If this contract is deployed directly, the _name, _symbol, and _totalSupply will remain empty or zero, rendering the token completely non-functional and unusable as an ERC-20 token. This is a critical functional flaw (7.1 Architecture, 7.8 Operations).

Fix

If FourERC20 is intended to be a deployable token, add a public constructor that calls _init(string memory name_, string memory symbol_) and implements an initial minting mechanism (e.g., _mint(msg.sender, initialSupply)). If it is strictly a base contract, ensure that any inheriting contract explicitly calls _init in its constructor or initializer.

Status

Unresolved

Low

Standard ERC-20 approve Race Condition

The approve function, while compliant with the ERC-20 standard, is susceptible to a known front-running vulnerability. If a user approves an amount, then attempts to change that approval to a different non-zero amount, an attacker can front-run the second transaction to spend the original approved amount. The second transaction will then set the allowance to the new amount, potentially allowing the attacker to spend more than intended. The contract includes increaseAllowance and decreaseAllowance which mitigate this, but the approve function itself remains vulnerable (7.2 Code Security).L-01

Issue

The approve function, while compliant with the ERC-20 standard, is susceptible to a known front-running vulnerability. If a user approves an amount, then attempts to change that approval to a different non-zero amount, an attacker can front-run the second transaction to spend the original approved amount. The second transaction will then set the allowance to the new amount, potentially allowing the attacker to spend more than intended. The contract includes increaseAllowance and decreaseAllowance which mitigate this, but the approve function itself remains vulnerable (7.2 Code Security).

Fix

Educate users about the approve race condition and strongly recommend using increaseAllowance and decreaseAllowance instead of directly calling approve when modifying an existing allowance. If approve must be used, advise users to first set the allowance to zero before setting a new non-zero value.

Status

Unresolved

Info

Base Contract Design for Supply Management

The _mint and _burn functions are declared as internal and are not exposed through any public or external functions within FourERC20. This indicates that FourERC20 is designed as a base contract, expecting a derived contract to implement the actual token supply management (minting and burning). If deployed directly without a derived contract, no tokens can ever be created or destroyed, making the totalSupply permanently zero (7.1 Architecture).I-01

Issue

The _mint and _burn functions are declared as internal and are not exposed through any public or external functions within FourERC20. This indicates that FourERC20 is designed as a base contract, expecting a derived contract to implement the actual token supply management (minting and burning). If deployed directly without a derived contract, no tokens can ever be created or destroyed, making the totalSupply permanently zero (7.1 Architecture).

Fix

This is a design choice. Ensure that the deployment strategy aligns with this design. If FourERC20 is intended to be a standalone, deployable token, consider adding public minting/burning functions or a constructor that mints an initial supply. If it's a base contract, document this clearly for developers inheriting from it.

Status

Unresolved

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 based on OpenZeppelin's audited codebase. While the core ERC-20 logic is robust, a critical functional flaw exists where the token's name, symbol, and initial supply are not set upon deployment, rendering the token unusable. Additionally, a low-severity issue related to the standard ERC-20 approve function's race condition is noted, though mitigated by alternative functions.

Technical8/10Low risk

The contract leverages OpenZeppelin's well-audited ERC20 implementation, contributing to strong code security (7.2 Code Security). It includes increaseAllowance and decreaseAllowance to mitigate common ERC-20 approve front-running issues. However, a critical functional flaw exists where the token's name, symbol, and initial supply are not initialized due to the _init function being internal and not called by a constructor (7.1 Architecture, 7.8 Operations). This renders the token non-functional if deployed directly, impacting its core utility.

Governance5/10Medium risk

This contract is a basic ERC-20 token and does not incorporate any governance mechanisms or complex economic models (7.5 Governance, 7.4 Economic). All standard ERC-20 operations are permissionless once allowances are set. Therefore, there are no inherent governance or economic risks within this specific contract; any such risks would stem from a higher-level protocol integrating this token.

Upgrades9/10Low risk

The contract is not designed as an upgradeable proxy (7.7 Upgrades). The provided information indicates it is intended for direct deployment, not as an implementation contract for a proxy. Consequently, there are no upgrade-specific risks such as storage collisions, improper initializer patterns, or proxy-related vulnerabilities.

Final RecommendationWhat to do about this score

It is imperative to address the critical initialization flaw.

If FourERC20 is intended to be a deployable token, a public constructor must be added to call the _init function and set the token's metadata (name and symbol), and to implement a minting mechanism to establish an initial supply. If it is meant as a base contract, ensure any inheriting contract properly calls _init in its constructor or initializer. Additionally, while increaseAllowance and decreaseAllowance mitigate some risks, users should be educated on the approve race condition.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age1mo
Contract0x1706…4444
Deployer0x1bff…191a
Badge for your website
MarsCoin 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. Aug 20, 202623Low

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
MEET48 TokenIDOL · BNB Chain23Lowbinanceus doodlesBOODLES · BNB Chain23LowChainGPTCGPT · BNB Chain23Low妖蝶BNB Chain22LowZygoSwapZSWAP · BNB Chain21LowThe Final Form BullCZ · BNB Chain25Low

Would You Like a More Detailed Audit of MarsCoin?

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