Quantum Audit Logo

Is memestock a Scam?

Honeypot, rug-pull and ownership checks

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

memestock MEMESTOCK
0x6ff4…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The audit of FlapTaxTokenV3 identified a critical vulnerability due to missing code for the `_processTax` function, which is essential for assessing reentrancy and external call risks. The contract implements an upgradeable ERC20 token with dynamic tax mechanisms and state transitions controlled by the owner. While the architecture is sound and leverages OpenZeppelin standards, the incomplete code prevents a full security assessment.

1 Critical1 Medium1 Low2 Informational
i Our automated scanner reviewed memestock (MEMESTOCK) on BNB Chain. 3 of 5 security checks passed — see the full breakdown below.
Volume 24h
$400.84M
Liquidity
$42.00M
Price
$0.9827
Age
17d
Top 10 Holders
23.9%

Security Findings

1 Crit1 Med1 Low2 Info
Critical

Incomplete `_liquidateTax` Function (Missing `_processTax` Implementation)

C-01The provided code snippet for `_liquidateTax` is truncated, specifically the `_processTax(taxAmount)` call and subsequent state updates. This external call is crucial for handling collected taxes and could introduce reentrancy vulnerabilities, external call risks, or incorrect tax processing if not properly implemented and secured. Without the full implementation, a complete security assessment is impossible.
IssueThe provided code snippet for `_liquidateTax` is truncated, specifically the `_processTax(taxAmount)` call and subsequent state updates. This external call is crucial for handling collected taxes and could introduce reentrancy vulnerabilities, external call risks, or incorrect tax processing if not properly implemented and secured. Without the full implementation, a complete security assessment is impossible.
FixProvide the full implementation of `_processTax` and the remainder of `_liquidateTax` for a complete security assessment. Ensure `_processTax` adheres to the Checks-Effects-Interactions pattern, handles potential reentrancy, and correctly manages tax funds.
StatusUnresolved
Medium

Centralized Control over Pool State Transitions

M-01The `startMigration` and `finalizeMigration` functions, restricted to the contract owner, allow unilateral changes to the `PoolState` (e.g., from `BondingCurve` to `Migrating` to `TaxEnforcedAntiFarmer`). These state changes directly impact transfer restrictions and tax application, potentially leading to unexpected behavior or economic implications for users without prior notice.
IssueThe `startMigration` and `finalizeMigration` functions, restricted to the contract owner, allow unilateral changes to the `PoolState` (e.g., from `BondingCurve` to `Migrating` to `TaxEnforcedAntiFarmer`). These state changes directly impact transfer restrictions and tax application, potentially leading to unexpected behavior or economic implications for users without prior notice.
FixImplement a timelock for critical state transitions to provide users with a grace period to react. Clearly document the implications of each pool state and the owner's ability to change them. Consider using a multi-signature wallet for ownership to distribute control.
StatusUnresolved
Low

Reliance on `block.timestamp` for Critical Expiration Logic

L-01The `_liquidateTax` function uses `block.timestamp` to determine if `taxExpirationTime` or `antiFarmerExpirationTime` has passed, triggering state changes. Miners can slightly manipulate `block.timestamp` (within a certain range), potentially influencing the exact block at which these state transitions occur.
IssueThe `_liquidateTax` function uses `block.timestamp` to determine if `taxExpirationTime` or `antiFarmerExpirationTime` has passed, triggering state changes. Miners can slightly manipulate `block.timestamp` (within a certain range), potentially influencing the exact block at which these state transitions occur.
FixWhile common, for highly time-sensitive or economically critical transitions, acknowledge the inherent miner manipulability. For most cases, `block.timestamp` is acceptable, but the risk should be understood. If absolute precision is required, consider a decentralized oracle for time.
StatusUnresolved
Info

Immutable Liquidation Thresholds

I-01The `MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` variables are declared as `immutable`, fixing their values at deployment. While this provides predictability, it removes the flexibility to adjust these critical economic parameters in response to evolving market conditions or protocol needs.
IssueThe `MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` variables are declared as `immutable`, fixing their values at deployment. While this provides predictability, it removes the flexibility to adjust these critical economic parameters in response to evolving market conditions or protocol needs.
FixAssess whether these thresholds are truly intended to be immutable for the lifetime of the contract. If future flexibility is desired, consider making them configurable by the owner or governance, potentially with a timelock.
StatusUnresolved
Info

All `maxSupply` Minted to Initializer

I-02The `initialize` function mints the entire `maxSupply` of tokens to `msg.sender` (the initializer/owner). This centralizes the initial token supply, which might not align with decentralization goals or require subsequent manual distribution mechanisms.
IssueThe `initialize` function mints the entire `maxSupply` of tokens to `msg.sender` (the initializer/owner). This centralizes the initial token supply, which might not align with decentralization goals or require subsequent manual distribution mechanisms.
FixEnsure this initial distribution strategy aligns with the project's tokenomics and distribution plans. If a more distributed initial supply is desired, consider alternative minting or distribution mechanisms during initialization.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract leverages OpenZeppelin's upgradeable standards for ERC20 and access control, demonstrating a solid architectural foundation (7.1 Architecture). Gas optimizations are evident through struct packing. However, a critical portion of the `_liquidateTax` function, specifically the `_processTax` external call, is missing from the provided code, preventing a full assessment of reentrancy and external interaction risks (7.2 Code Security, 7.6 External). The `_transfer` function correctly handles different pool states and tax application.

GovernanceMedium6/10

The contract's economic model includes dynamic buy/sell taxes and liquidation thresholds, managed through various `PoolState`s. The owner has significant control over these states via `startMigration` and `finalizeMigration` functions (7.5 Governance, 7.3 Access Control), which could lead to unexpected user behavior if not transparently managed. Initial liquidation thresholds are immutable, limiting adaptability (7.4 Economic). The entire token supply is minted to the initializer, centralizing initial distribution.

UpgradesHigh3/10

The contract correctly implements the `Initializable` pattern from OpenZeppelin, including `_disableInitializers()` in the constructor and proper `__init` calls (7.7 Upgrades). This indicates a UUPS proxy pattern is intended, allowing for future upgrades of the contract logic. No immediate upgrade safety issues were identified within the provided code snippet.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source

Holder Composition

23.9% in top 10
0.0% in wallets23.9% in contracts
Effective Concentration9.6%

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

$42.00M across 5 pairs
Pancakeswap v2GMEBanalysed$42.00M100.0%Pancakeswap v3WBNB$2050.0%Pancakeswap v3USDT$940.0%Pancakeswap v2BTCBR$10.0%Uniswap v2USDT$00.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 Holder88.2%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0x521d…f388
Unlocked LP Held By
0x4860…5fc30x8a81…d15a0x2c2b…e51c

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

What Raised This Score

9 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
  • LP top1 unlocked holder = 88.2% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • Token age < 30 days (still settling)
  • 1 Critical finding(s) from audit
  • 1 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
GUAMedium RiskTrenchesStarterPack (战壕入门包)Medium RiskChainbase Token (C)Medium RiskGiggle Cat (NIANNIAN)Medium RiskBabySharkMedium Risk吉祥马Medium Risk

Would You Like a More Detailed Audit of memestock?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit