Quantum Audit Logo
Launch App

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

Is Marscoin Safe?

MARSBNB 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/10Governance8/10Upgrades10/10Checks passed5 of 5Findings2 High · 2 Medium4
SummaryAI Copilot

The audit of the Token contract revealed a well-structured ERC20 implementation leveraging standard OpenZeppelin patterns.

Read the full analysis
What raised the score
  • Top-10 concentration > 20%
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
Exact 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

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
35.6%Contracts8.7%55.8%Everyone else
35.6%Contracts8.7%55.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
44.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking35.6%
  • Walletsanonymous holders, free to sell8.7%
  • Everyone elsethe rest of the supply55.8%
Effective concentrationwhat the score reads22.9%
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$52.8K across 2 pairs

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$52.8KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address
Unlocked LP held by
0xd5e4…fc30

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

Security Findings

2 High2 Medium
High

Irreversible Transfer Mode Change

The 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.H-01

Issue

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

Fix

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

Status

Unresolved

High

Initial Transfer Restriction Requires Owner Action

In 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.H-02

Issue

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

Fix

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

Status

Unresolved

Medium

Centralized Transfer Control in MODE_TRANSFER_CONTROLLED

When _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.M-01

Issue

When _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.

Fix

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

Status

Unresolved

Medium

Risk of Permanent Lock if Ownership Renounced in Restricted Mode

The 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.M-02

Issue

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

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical8/10Low risk

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.

Governance8/10Low risk

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

Upgrades10/10Low risk

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.

Final RecommendationWhat to do about this score

It is strongly recommended to carefully review the intended lifecycle and operational requirements for the token's transfer modes.

Consider modifying the setMode function to allow the owner to revert to restricted modes from MODE_NORMAL if such flexibility is desired for future emergencies or operational changes. Additionally, ensure a clear plan is in place for transitioning the token out of its initial MODE_TRANSFER_RESTRICTED state, and exercise extreme caution if considering renouncing ownership, as it could lead to permanent transfer restrictions.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age1y
Contract0x1fd4…5b68
Deployer0xf8fb…b71d
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. Sep 4, 20264Low
  2. Aug 17, 202610Low

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

Related Audits

6 more on the recordAll audits
osbookBNB Chain4LowTaggerTAG · BNB Chain5LowSmart Solve TokenSST · BNB Chain5LowUpscreenerUPS · BNB Chain3LowPaluBNB Chain2Low哈基米BNB Chain2Low

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