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

Is SnapCoin a Scam?

SNAPCOIN

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 · 3h old

Chart

100/ 100

Critical RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical4/10 Governance1/10 Upgrades3/10 Checks passed3 of 5 Findings1 Critical · 2 High · 2 Medium · 1 Low · 1 Info7

SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms and a state machine for managing pool interactions.

Read the full analysis

What raised the score

Proxy contract
Non-standard proxy storage
Top-10 concentration > 30%
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Liquidity < $50k
LP top1 unlocked holder = 100.0%
LP top3 unlocked holders = 100.0%
Token age < 24h
1 Critical finding(s) from audit
2 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)
Top-10 concentration > 30% (99.4% total → 46.8% effective; 11.7% in EOAs, 87.6% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Liquidity < $50k ($17,156 across 3 pairs — thin market)
LP top1 unlocked holder = 100.0% (independent LP — depth risk)
LP top3 unlocked holders = 100.0% (independent LP — depth risk)
Token age < 24h (brand new — bot activity, unproven)
1 Critical finding(s) from audit
2 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 (3h 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

99.4%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking87.6%
Walletsanonymous holders, free to sell11.7%
Everyone elsethe rest of the supply0.6%

Effective concentrationwhat the score reads46.8%

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$17.2K across 3 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$17.2KShare of depth100.0%

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

Unlocked LP held by

0x14e5…be4a

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

Security Findings

1 Critical2 High2 Medium1 Low1 Info

Critical

Incomplete `_liquidateTax` Function Prevents Full Audit

The provided source code for the _liquidateTax function is truncated, specifically at the point where poolState = currentPoolState is assigned after _processTax(taxAmount). This prevents a complete analysis of the function's logic, including its interaction with external contracts, potential reentrancy vectors, and overall security implications. Without the full implementation, critical vulnerabilities could remain undetected.C-01

Issue

Fix

Provide the complete and untruncated source code for the _liquidateTax function to allow for a comprehensive security assessment. This is essential for verifying the integrity and safety of the contract's core tax processing logic.

Status

Unresolved

High

Centralization of Token Supply to Deployer

During the initialize function, the entire maxSupply (1e9 ether) of tokens is minted directly to msg.sender (the deployer). This grants the deployer 100% of the token supply, leading to extreme centralization. This single entity has the power to significantly influence market prices, control any future governance mechanisms, or dump tokens, posing a severe economic risk to the project and its users (7.4 Economic).H-01

Issue

Fix

Implement a more decentralized initial token distribution strategy. This could involve vesting schedules, multi-signature wallets for large holdings, or a community-controlled treasury. If this is an intended design for a specific phase, ensure users are fully aware of this centralization risk.

Status

Unresolved

High

Potential Reentrancy and MEV Risk in `_liquidateTax`

The _liquidateTax function performs state changes (currentPoolState.notLiquidating = false before _processTax and true after) and likely makes external calls via _processTax(taxAmount) (which would interact with taxProcessor and dividendContract). This pattern is highly susceptible to reentrancy if _processTax calls an untrusted contract that can re-enter _transfer and subsequently _liquidateTax before notLiquidating is reset. Additionally, the function's reliance on block.timestamp and taxAmount to trigger state changes or tax processing creates opportunities for MEV (Miner Extractable Value) where an attacker could front-run transactions to manipulate the timing…H-02

Issue

Fix

Implement a 'Checks-Effects-Interactions' pattern to mitigate reentrancy. Ensure all state changes are completed before any external calls are made. If _processTax involves external calls, consider using reentrancy guards. Thoroughly analyze the full _processTax implementation for reentrancy vectors. For MEV, consider adding a delay or a commit-reveal scheme for sensitive state transitions if applicable, or ensure that the economic incentives for front-running are minimized.

Status

Unresolved

Medium

Immutability of Critical External Dependencies

The taxProcessor and dividendContract addresses are set during the initialize function and are immutable thereafter. This means that if these external contracts are compromised, become buggy, or require upgrades, the FlapTaxTokenV3 contract cannot adapt by updating these addresses. This introduces a single point of failure and limits operational flexibility (7.6 External, 7.8 Operations).M-01

Issue

Fix

Implement owner-controlled functions to allow for updating the taxProcessor and dividendContract addresses. This should be protected by onlyOwner and potentially a timelock to provide a window for users to react to changes. Ensure robust validation for new addresses (e.g., checking for non-zero address).

Status

Unresolved

Medium

Lack of Direct Owner Control over Tax Parameters

While the owner can initiate state transitions (startMigration, finalizeMigration) that indirectly affect tax parameters, there are no direct owner-controlled functions to adjust buyTaxRate, sellTaxRate, taxExpirationTime, or antiFarmerDuration after initialization. This limits the project's ability to respond to changing market conditions, regulatory requirements, or unforeseen economic circumstances by dynamically adjusting the tax structure (7.5 Governance).M-02

Issue

Fix

Consider adding owner-controlled functions to allow for the adjustment of key tax parameters such as buyTaxRate, sellTaxRate, taxExpirationTime, and antiFarmerDuration. These functions should be protected by onlyOwner and potentially a timelock to ensure transparency and provide a grace period for users.

Status

Unresolved

Low

Inefficient `_liquidateTax` Trigger Mechanism

The _liquidateTax function is called on every _transfer where the to address is the mainPool. While this ensures tax liquidation is regularly checked, it could lead to unnecessary gas consumption if transfers to the mainPool are frequent but the conditions for actual liquidation (e.g., taxAmount >= liquidationThreshold or block.timestamp > taxExpirationTime) are rarely met. This constant checking adds overhead without always performing a useful action (7.2 Code Security).L-01

Issue

Fix

Consider optimizing the trigger for _liquidateTax. This could involve: 1) Implementing a minimum time interval between liquidation checks. 2) Allowing an external actor (e.g., keeper bot) to trigger liquidation when conditions are met, potentially incentivized by a small fee. 3) Only checking liquidation conditions if the accumulated tax balance exceeds a certain threshold.

Status

Unresolved

Info

Upgradeability Considerations for `PackedPoolState` Struct

The PackedPoolState struct is efficiently packed into a single storage slot (8+16+16+8+96+64+48 = 256 bits). While this is good for gas efficiency, adding new fields to this struct in a future upgrade requires extreme caution. If new fields are added without careful consideration of storage slot packing, it could lead to storage collisions with existing data, resulting in data corruption or unexpected contract behavior (7.7 Upgrades).I-01

Issue

Fix

When planning future upgrades, if modifications to the PackedPoolState struct are necessary, ensure that new fields are appended carefully to avoid overwriting existing data. Consult OpenZeppelin's upgrade guidelines on storage layout and consider using tools like hardhat-upgrades or foundry-upgrades to detect storage layout incompatibilities during development.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms and a state machine for managing pool interactions. A critical portion of the _liquidateTax function was truncated in the provided source, preventing a full security assessment. Key findings include significant centralization of token supply to the deployer, potential reentrancy/MEV risks in the tax liquidation process, and immutability of critical external dependencies. The contract utilizes OpenZeppelin's upgradeable patterns correctly for its proxy implementation.

Technical4/10Medium risk

The contract leverages OpenZeppelin's battle-tested upgradeable ERC20, Ownable, and Permit implementations, contributing to a solid foundation (7.1 Architecture). However, a critical portion of the _liquidateTax function was truncated, preventing a complete analysis of its security implications (7.2 Code Security). The visible logic in _liquidateTax suggests potential reentrancy or MEV opportunities due to state changes and likely external calls within a single transaction (7.2 Code Security). Additionally, the mechanism for triggering _liquidateTax on every transfer to the mainPool could lead to inefficient gas usage (7.2 Code Security).

Governance1/10High risk

The contract establishes clear owner roles for initiating and finalizing migration states, which is a positive aspect of its operational control (7.5 Governance). However, a significant economic risk is present as 100% of the token supply is minted to the deployer during initialization, leading to high centralization (7.4 Economic). Furthermore, critical external dependencies like taxProcessor and dividendContract are immutable after deployment, limiting flexibility and introducing a single point of failure if these contracts need updates or are compromised (7.6 External). The owner also lacks direct control over adjusting tax rates and durations, which could hinder adaptability to market changes (7.5 Governance).

Upgrades3/10High risk

The contract correctly implements the UUPS proxy pattern by inheriting from Initializable and calling _disableInitializers() in the constructor, ensuring proper upgradeability (7.7 Upgrades). The use of __ERC20_init, __ERC20Permit_init, and __Ownable_init follows OpenZeppelin's recommended initialization pattern for upgradeable contracts. Future upgrades must carefully manage storage, especially if new fields are added to the PackedPoolState struct, to prevent storage collisions (7.7 Upgrades).

Final RecommendationWhat to do about this score

It is imperative to provide the complete source code for the _liquidateTax function to enable a thorough security review, especially concerning reentrancy and external call interactions.

Address the high centralization of token supply by implementing a more distributed initial token allocation or a robust governance mechanism. Consider adding owner-controlled functions to update critical external dependencies and adjust tax parameters to enhance operational flexibility and responsiveness to unforeseen circumstances. Review the _liquidateTax trigger mechanism for gas efficiency and potential MEV vulnerabilities.

Contract & Record

1 audit on record

TypeFlapTaxTokenV3

NetworkBNB Chain

Token age3h

Contract0x354e…7777

Deployer0x6f3b…38c5

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, 2026100Critical
Aug 13, 202690Critical

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

Frequently Asked Questions

What is the SNAPCOIN contract address?

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