Early-stage security check — honeypot & rug-pull analysis

Is MarsCoin a Scam?

MARSCOIN

BNB 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 recordNew Launch · 6d old

Chart

39/ 100

Medium RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical8/10 Governance7/10 Upgrades4/10 Checks passed3 of 5 Findings1 High · 2 Medium · 1 Low · 3 Info7

SummaryAI Copilot

The FlapTaxTokenV3 contract implements an ERC20 token with advanced tax mechanisms, including asymmetric buy/sell taxes, anti-farmer tax, and a dynamic liquidation threshold.

Read the full analysis

What raised the score

Proxy contract
Non-standard proxy storage
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Volume/Liquidity > 15×
Token age < 7 days
1 High finding(s) from audit
2 Medium finding(s) from audit
1 Low finding(s) from audit

Exact factors

Proxy contract (upgradeable — admin can replace logic)
Non-standard proxy storage (Etherscan-confirmed)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Volume/Liquidity > 15× (15.8× — wash-trading signal)
Token age < 7 days (early, volatile)
1 High finding(s) from audit
2 Medium 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

Early-stage analysis. This token has limited on-chain history (6d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.

Security Checklist

as of audit · Sep 43 of 5 checks passed

Contract verifiedVerified

OwnershipRenounced

MintNo mint

Liquidity lockNot locked

UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

30.2%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking24.9%
Walletsanonymous holders, free to sell5.3%
Everyone elsethe rest of the supply69.8%

Effective concentrationwhat the score reads15.3%

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$1.60M across 11 pairs

Show 4 more pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$785.6KShare of depth49.2%

Top-1 Unlocked Holder16.9%

Top-3 Unlocked31.2%

Unlocked LP held by

0xa986…be860x75be…ee900xde93…0bbc0x1119…26f50x07fb…e6a30x0be6…546d0xb3aa…92a00x0d1d…51fd0x7a97…4c920xcd6c…9dd5

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

Security Findings

1 High2 Medium1 Low3 Info

High

Potential `uint96` Overflow in `PackedPoolState.liquidationThreshold`

The liquidationThreshold field within the PackedPoolState struct is defined as uint96. While the current maxSupply of 1 billion tokens (1e9 ether) fits within this type, the contract's custom:security-note explicitly warns that if the total supply limit is changed to more than 1 billion ether, this field type must be revisited. Failure to do so could lead to an integer overflow if the liquidationThreshold value exceeds uint96's maximum capacity (~79 billion tokens with 18 decimals), causing incorrect calculations or unexpected protocol behavior. This is a critical design consideration for future scalability.H-01

Issue

Fix

Implement a robust monitoring system for the token's maxSupply and liquidationThreshold values. If there is any intention to increase maxSupply significantly in the future, proactively adjust the liquidationThreshold data type (e.g., to uint128 or uint256) in a new implementation to prevent potential overflows. Consider adding runtime checks to ensure liquidationThreshold never exceeds type(uint96).max during updates.

Status

Unresolved

Medium

High Centralization Risk via Owner Privileges

The OwnableUpgradeable pattern grants significant control to a single owner address. Functions like startMigration are protected by onlyOwner. Furthermore, the initialize function allows the owner to set critical parameters such as taxProcessor, dividendContract, v2Router, quoteToken, antiFarmerDuration, buyTax, sellTax, taxDuration, liqExpectedOutputAmount, and the initial pools. This extensive control over core protocol addresses and economic parameters introduces a high degree of centralization, making the protocol vulnerable to a single point of compromise or malicious action by the owner.M-01

Issue

Fix

Consider implementing a multi-signature wallet (e.g., Gnosis Safe) for the owner role to require multiple approvals for critical operations. For highly sensitive parameters or actions, explore time-locked governance mechanisms or decentralized autonomous organization (DAO) control to distribute power and increase transparency.

Status

Unresolved

Medium

Reliance on External Contracts Introduces Dependency Risk

The FlapTaxTokenV3 contract relies heavily on several external contracts, including v2Router, taxProcessor, dividendContract, quoteToken, and the addresses within the pools mapping. These external dependencies are set during initialization and can be critical for the token's functionality (e.g., tax processing, liquidity management, dividend distribution). A compromise, malfunction, or malicious upgrade in any of these external contracts could directly impact the security and functionality of FlapTaxTokenV3, potentially leading to loss of funds or service disruption.M-02

Issue

Fix

Thoroughly audit and vet all external contracts before integrating them. Implement robust input validation for external addresses. Consider adding mechanisms to pause critical interactions with external contracts in emergencies or to allow the owner to update compromised external addresses. Clearly document the trust assumptions made regarding each external dependency.

Status

Unresolved

Low

Potential Gas Limit Exceeded in `initialize` for Large Pool Arrays

The initialize function includes a for loop that iterates through the params.pools array to set pools[params.pools[i]] = true. If the params.pools array contains an extremely large number of addresses, this loop could consume a significant amount of gas. In extreme cases, it might cause the transaction to exceed the block gas limit, preventing the contract from being initialized successfully.L-01

Issue

Fix

While unlikely for typical deployments, consider imposing a reasonable maximum limit on the size of the params.pools array during initialization. Alternatively, if a very large number of pools is anticipated, implement a paginated or batched approach for adding pools post-initialization via an owner-controlled function, rather than during a single deployment transaction.

Status

Unresolved

Info

Reliance on `block.timestamp` for Time-Dependent Mechanisms

The contract utilizes taxExpirationTime and antiFarmerExpirationTime, which are derived from block.timestamp. While block.timestamp is a standard EVM primitive, it is susceptible to minor manipulation by miners (within a small window, typically a few seconds). For highly time-sensitive operations, this could introduce a slight degree of unpredictability or allow for minor front-running opportunities related to tax expirations.I-01

Issue

Fix

Acknowledge the inherent limitations of block.timestamp in EVM. For most applications, this level of precision is acceptable. If extreme precision or resistance to miner manipulation is critical for future features, consider alternative time-keeping mechanisms (e.g., relying on oracle-provided timestamps, though this introduces new trust assumptions).

Status

Unresolved

Info

Effective Use of Immutable Variables for Threshold Limits

The contract correctly utilizes immutable keywords for MIN_LIQ_THRESHOLD and START_LIQ_THRESHOLD in its constructor. This ensures that these critical threshold limits are set once at deployment and cannot be altered thereafter, providing a strong guarantee of their values across all clones and future upgrades of this implementation. This is a good practice for fixed protocol parameters.I-02

Issue

Fix

Continue to identify and apply the immutable keyword to any other parameters that are intended to be unchangeable throughout the contract's lifecycle, enhancing security and predictability.

Status

Unresolved

Info

Well-Implemented Upgradeability Pattern

The contract correctly implements the UUPS (Universal Upgradeable Proxy Standard) pattern by inheriting from OpenZeppelin's Initializable, ERC20Upgradeable, ERC20PermitUpgradeable, and OwnableUpgradeable contracts. The constructor calls _disableInitializers() to prevent re-initialization of the implementation contract, and the initialize function uses the initializer modifier. This setup provides a secure and standard way to manage contract upgrades.I-03

Issue

Fix

Maintain strict control over the proxy's admin address, as this address has the power to upgrade the contract. Ensure that upgrade proposals are thoroughly tested and reviewed before deployment to production.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

The FlapTaxTokenV3 contract implements an ERC20 token with advanced tax mechanisms, including asymmetric buy/sell taxes, anti-farmer tax, and a dynamic liquidation threshold. It leverages OpenZeppelin's upgradeable contracts for secure upgradeability. The audit identified a high-severity risk related to potential integer overflow in a packed struct field if token supply limits are significantly altered, alongside medium-severity centralization and external dependency risks. The contract demonstrates good architectural practices for upgradeability and gas optimization.

Technical8/10Low risk

The contract utilizes OpenZeppelin's upgradeable standards and implements a gas-optimized PackedPoolState struct (7.1 Architecture). A notable technical risk is the uint96 type for liquidationThreshold, which could overflow if the maxSupply is increased beyond its current limits, as explicitly noted in the code (7.2 Code Security). The initialize function's loop for adding pools could potentially hit gas limits if an excessively large array is provided (7.8 Operations).

Governance7/10Low risk

The contract exhibits a medium level of centralization due to the onlyOwner role having extensive control over critical parameters such as tax rates, external contract addresses (taxProcessor, dividendContract, v2Router), and the ability to initiate migration (7.3 Access Control, 7.5 Governance). The economic model relies on time-dependent and anti-farmer taxes, which are sensitive to block.timestamp (7.4 Economic). Significant trust is placed in external dependencies like taxProcessor and v2Router (7.6 External).

Upgrades4/10Medium risk

The contract is designed for upgradeability using OpenZeppelin's Initializable and Upgradeable patterns, indicating a UUPS proxy implementation (7.7 Upgrades). Immutable variables (MIN_LIQ_THRESHOLD, START_LIQ_THRESHOLD) are correctly set in the constructor, ensuring their persistence across upgrades and instances (7.1 Architecture). The _disableInitializers() call in the constructor prevents re-initialization of the implementation contract.

Final RecommendationWhat to do about this score

It is recommended to carefully review the uint96 type for liquidationThreshold and implement robust checks or alternative data types if the token's maxSupply is ever considered for an increase beyond current limits.

Additionally, consider implementing a multi-signature wallet for critical owner-controlled functions to mitigate centralization risks and enhance security. Thoroughly vet all external contract addresses before deployment.

Contract & Record

1 audit on record

TypeFlapTaxTokenV3

NetworkBNB Chain

Token age6d

Contract0xfe18…7777

Deployer0x85de…82e5

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

Badge for your website

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

Sep 4, 202639Medium
Aug 3, 202637Medium

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

Frequently Asked Questions

What is the MARSCOIN contract address?

The MarsCoin contract on BNB Chain is 0xfe189e97832da1573e4e4ff034f4ffc3a15c7777. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.