Quantum Audit Logo

Is MarsCoin a Scam?

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

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

MarsCoin MARSCOIN
0xfe18…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 6d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive 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. 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.

1 High2 Medium1 Low3 Informational
! 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.
Volume 24h
$12.38M
Liquidity
$785.6K
Price
$0.1307
Token Age
6d
Top 10 Holders
30.2%

Security Findings

1 High2 Med1 Low3 Info
High

Potential `uint96` Overflow in `PackedPoolState.liquidationThreshold`

H-01The `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.
IssueThe `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.
FixImplement 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.
StatusUnresolved
Medium

High Centralization Risk via Owner Privileges

M-01The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved
Medium

Reliance on External Contracts Introduces Dependency Risk

M-02The `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.
IssueThe `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.
FixThoroughly 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.
StatusUnresolved
Low

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

L-01The `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.
IssueThe `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.
FixWhile 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.
StatusUnresolved
Info

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

I-01The 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.
IssueThe 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.
FixAcknowledge 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).
StatusUnresolved
Info

Effective Use of Immutable Variables for Threshold Limits

I-02The 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.
IssueThe 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.
FixContinue 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.
StatusUnresolved
Info

Well-Implemented Upgradeability Pattern

I-03The 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.
IssueThe 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.
FixMaintain 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceLow7/10

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

UpgradesMedium4/10

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.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source

Holder Composition

30.2% in top 10
5.3% in wallets24.9% in contracts
Effective Concentration15.3%

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

$1.60M across 11 pairs
Pancakeswap v3USDTanalysed$785.6K49.2%Pancakeswap v3USDT$560.7K35.1%UniswapUSDT$239.8K15.0%Pancakeswap v3牛来$9.9K0.6%Pancakeswap v3SPCXB$8390.1%Uniswap v2USDT$300.0%
Show 4 more pairsShow less
Pancakeswap v2WBNB$90.0%Pancakeswap v2USDT$60.0%Pancakeswap v3USDC$20.0%Uniswap v2WBNB$10.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

Top-1 Unlocked Holder16.9%
Top-3 Unlocked31.2%

Key Addresses

11 addresses
Deployer
0x85de…82e5
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.

What Raised This Score

8 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

Related Audits

6 more on the record
Bitway Token (BTW)Medium RiskCZ'S DOG (BROCCOLI)Medium RiskCharacterX (CAI)Medium RiskMame Inu (MAME)Medium RiskAPRO oracle Token (AT)Medium Riskutility token (UTILITY)Medium Risk

Would You Like a More Detailed Audit of MarsCoin?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit