Quantum Audit Logo
Launch App

Honeypot, rug-pull and ownership checks

Is memestock a Scam?

MEMESTOCKBNB 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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance6/10Upgrades3/10Checks passed5 of 7Findings1 Critical · 1 Medium · 1 Low · 2 Info5
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.

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
  • LP top1 unlocked holder = 88.2%
  • LP top3 unlocked holders = 100.0%
  • Token age < 30 days
  • 1 Critical finding(s) from audit
  • 1 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
  • 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

Our automated scanner reviewed memestock (MEMESTOCK) on BNB Chain. 5 of 7 security checks passed — see the full breakdown below.

Security Checklist

as of audit · Sep 45 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
23.9%Contracts76.1%Everyone else
23.9%Contracts76.1%Everyone else
ContractsEveryone elseBubble area = share of supply
23.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking23.9%
  • Everyone elsethe rest of the supply76.1%
Effective concentrationwhat the score reads9.6%
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$42.00M across 5 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$42.00MShare of depth100.0%
Top-1 Unlocked Holder88.2%
Top-3 Unlocked100.0%
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.

Security Findings

1 Critical1 Medium1 Low2 Info
Critical

Incomplete _liquidateTax Function (Missing _processTax Implementation)

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

Issue

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

Fix

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

Status

Unresolved

Medium

Centralized Control over Pool State Transitions

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

Issue

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

Fix

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

Status

Unresolved

Low

Reliance on block.timestamp for Critical Expiration Logic

The _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.L-01

Issue

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

Fix

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

Status

Unresolved

Info

Immutable Liquidation Thresholds

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

Issue

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

Fix

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

Status

Unresolved

Info

All maxSupply Minted to Initializer

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical7/10Low risk

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.

Governance6/10Medium risk

The contract's economic model includes dynamic buy/sell taxes and liquidation thresholds, managed through various PoolStates. 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.

Upgrades3/10High risk

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.

Final RecommendationWhat to do about this score

Prioritize providing the complete implementation of the _processTax function and the remainder of _liquidateTax to address the critical missing code vulnerability.

Implement a timelock for owner-controlled state transitions to enhance transparency and provide users with reaction time. Review the immutability of economic parameters to ensure long-term adaptability.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age17d
Contract0x6ff4…7777
Deployer0x521d…f388
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Badge for your website
memestock 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, 202643Medium
  2. Aug 30, 202624Low

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

Related Audits

6 more on the recordAll audits
GUABNB Chain43MediumTrenchesStarterPack战壕入门包 · BNB Chain43MediumChainbase TokenC · BNB Chain43MediumGiggle CatNIANNIAN · BNB Chain43MediumBabySharkBNB Chain43MediumUPONLYBNB Chain43Medium

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 Is this your token? Publish your own audit on this page