Is MarsCoin Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 Low1 Info

Critical

Uninitialized Token State on Direct Deployment

C-01The `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).

IssueThe `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).

FixIf `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.

StatusUnresolved

Low

Standard ERC-20 `approve` Race Condition

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

IssueThe `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).

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

StatusUnresolved

Info

Base Contract Design for Supply Management

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

IssueThe `_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).

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceMedium5/10

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.

UpgradesLow9/10

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.

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

72.4% in wallets12.7% in contracts

Effective Concentration77.5%

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

$148.1K

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

1 addresses

Deployer

0x1bff…191a

What Raised This Score

3 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

Is MarsCoin Safe?

Security Findings

Uninitialized Token State on Direct Deployment

Standard ERC-20 `approve` Race Condition

Base Contract Design for Supply Management

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 MarsCoin?