Quantum Audit Logo

Is Marscoin Safe?

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

Is this your token? Publish your own audit on this page →

Marscoin MARS
0x1fd4…5b68
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The audit of the Token contract revealed a well-structured ERC20 implementation leveraging standard OpenZeppelin patterns. However, the custom transfer mode logic introduces significant centralization and several critical operational and governance risks. Key issues include an irreversible state change for transfer modes, an initially restricted transfer state, and the potential for permanent transfer lock if ownership is renounced prematurely. These design choices could severely impact token utility and user funds if not managed carefully.

2 High2 Medium
Volume 24h
$5.6K
Liquidity
$52.8K
Price
$0.0000961
Token Age
1y
Top 10 Holders
44.2%

Security Findings

2 High2 Med
High

Irreversible Transfer Mode Change

H-01The `setMode` function contains a condition `if (_mode != MODE_NORMAL) { _mode = v; }`. This logic prevents the owner from changing the token's transfer mode once it has been set to `MODE_NORMAL` (0). This means that if the project ever needs to re-enable transfer restrictions (e.g., for security incidents, regulatory compliance, or specific event phases), it will be impossible to do so, permanently removing a critical control mechanism.
IssueThe `setMode` function contains a condition `if (_mode != MODE_NORMAL) { _mode = v; }`. This logic prevents the owner from changing the token's transfer mode once it has been set to `MODE_NORMAL` (0). This means that if the project ever needs to re-enable transfer restrictions (e.g., for security incidents, regulatory compliance, or specific event phases), it will be impossible to do so, permanently removing a critical control mechanism.
FixModify the `setMode` function to remove the `if (_mode != MODE_NORMAL)` condition, allowing the owner full flexibility to switch between all defined modes at any time. Alternatively, if the irreversible nature is intentional, clearly document this design choice and its implications.
StatusUnresolved
High

Initial Transfer Restriction Requires Owner Action

H-02In the constructor, the `_mode` is initialized to `MODE_TRANSFER_RESTRICTED`. This means that immediately after deployment, no token transfers are possible until the contract owner explicitly calls `setMode(MODE_NORMAL)`. If the owner fails to perform this action, or if there's a delay, users might be unable to transfer their tokens, leading to confusion, frustration, and potential economic loss.
IssueIn the constructor, the `_mode` is initialized to `MODE_TRANSFER_RESTRICTED`. This means that immediately after deployment, no token transfers are possible until the contract owner explicitly calls `setMode(MODE_NORMAL)`. If the owner fails to perform this action, or if there's a delay, users might be unable to transfer their tokens, leading to confusion, frustration, and potential economic loss.
FixConsider initializing the `_mode` to `MODE_NORMAL` if the intention is for the token to be freely transferable from deployment. If the restricted initial state is intentional, ensure robust off-chain communication and operational procedures are in place to promptly transition the token to `MODE_NORMAL`.
StatusUnresolved
Medium

Centralized Transfer Control in MODE_TRANSFER_CONTROLLED

M-01When `_mode` is set to `MODE_TRANSFER_CONTROLLED`, the `_beforeTokenTransfer` hook enforces `require(from == owner() || to == owner(), 'Token: Invalid transfer');`. This design choice means that only transfers involving the contract owner (either as sender or receiver) are permitted. While potentially intentional for specific use cases, this severely centralizes control over token movement and significantly limits the token's liquidity and utility for general users, posing a high economic risk for token holders.
IssueWhen `_mode` is set to `MODE_TRANSFER_CONTROLLED`, the `_beforeTokenTransfer` hook enforces `require(from == owner() || to == owner(), 'Token: Invalid transfer');`. This design choice means that only transfers involving the contract owner (either as sender or receiver) are permitted. While potentially intentional for specific use cases, this severely centralizes control over token movement and significantly limits the token's liquidity and utility for general users, posing a high economic risk for token holders.
FixClearly communicate the implications of `MODE_TRANSFER_CONTROLLED` to all potential users and stakeholders. Ensure this mode aligns with the project's long-term vision and decentralization goals. If broader transferability is desired, this mode should be used sparingly or redesigned.
StatusUnresolved
Medium

Risk of Permanent Lock if Ownership Renounced in Restricted Mode

M-02The `Ownable` contract includes a `renounceOwnership()` function. If the contract owner renounces ownership while the token is in `MODE_TRANSFER_RESTRICTED` or `MODE_TRANSFER_CONTROLLED`, and especially if `MODE_NORMAL` has not been set (due to H-01), no entity will be able to call `setMode` to change the transfer restrictions. This could permanently lock the token in a restricted state, rendering it untransferable and valueless.
IssueThe `Ownable` contract includes a `renounceOwnership()` function. If the contract owner renounces ownership while the token is in `MODE_TRANSFER_RESTRICTED` or `MODE_TRANSFER_CONTROLLED`, and especially if `MODE_NORMAL` has not been set (due to H-01), no entity will be able to call `setMode` to change the transfer restrictions. This could permanently lock the token in a restricted state, rendering it untransferable and valueless.
FixImplement a safeguard to prevent `renounceOwnership()` if the token is not in `MODE_NORMAL`. Alternatively, ensure that ownership is only renounced after the token has been definitively set to `MODE_NORMAL` and the irreversible nature of this action is fully understood and accepted.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract utilizes standard and well-audited OpenZeppelin patterns for ERC20 functionality and ownership, including safe use of `unchecked` blocks for arithmetic operations (7.2 Code Security). The implementation of `_beforeTokenTransfer` for custom logic is a robust pattern. However, the custom transfer mode logic introduces significant operational constraints, specifically the `setMode` function's conditional logic (`if (_mode != MODE_NORMAL)`) which creates a permanent, irreversible state change once `MODE_NORMAL` is activated (7.1 Architecture, 7.3 Access Control). No reentrancy vulnerabilities or complex external interactions were identified.

GovernanceLow8/10

The `Ownable` pattern provides a clear, single point of administrative control for critical functions like `setMode` (7.5 Governance). The ability to restrict transfers offers flexibility for specific project phases. However, the token's economic utility is heavily centralized and can be severely limited by the owner's actions, particularly due to the initial `MODE_TRANSFER_RESTRICTED` state (7.4 Economic). The irreversible nature of setting `MODE_NORMAL` via `setMode` represents a significant governance risk, as it removes the ability to re-impose transfer controls even in emergency situations (7.5 Governance, 7.8 Operations). Renouncing ownership while in a restricted mode could permanently lock the token's transferability (7.8 Operations).

UpgradesLow10/10

The contract is not designed with an upgradeability pattern (e.g., proxy). Therefore, there are no specific upgrade-related risks (7.7 Upgrades). Any changes to the contract logic would require a new deployment and migration of assets, which is a standard approach for non-upgradeable contracts.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

44.2% in top 10
8.7% in wallets35.6% in contracts
Effective Concentration22.9%

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

$52.8K across 2 pairs
Pancakeswap v2WBNBanalysed$52.8K100.0%Pancakeswap v2Subject 3$40.0%

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

2 addresses
Deployer
0xf8fb…b71d
Unlocked LP Held By
0xd5e4…fc30

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

3 factors
  • Top-10 concentration > 20% (44.2% total → 22.9% effective; 8.7% in EOAs, 35.6% in contracts — mild)
  • 2 High finding(s) from audit
  • 2 Medium 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

Related Audits

6 more on the record
Tagger (TAG)Low RiskSmart Solve Token (SST)Low RiskPaluLow Risk哈基米Low RiskBanana For Scale (BANANAS31)Low RiskREAL WORLD APPAREL (JACKET)Low Risk

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