Quantum Audit Logo

Is SnapCoin a Scam?

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

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

SnapCoin SNAPCOIN
0x354e…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 3h old
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

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.

1 Critical2 High2 Medium1 Low1 Informational
! 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.
Volume 24h
$104.6K
Liquidity
$17.2K
Price
$0.00002716
Token Age
3h
Top 10 Holders
99.4%

Security Findings

1 Crit2 High2 Med1 Low1 Info
Critical

Incomplete `_liquidateTax` Function Prevents Full Audit

C-01The 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.
IssueThe 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.
FixProvide 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.
StatusUnresolved
High

Centralization of Token Supply to Deployer

H-01During 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).
IssueDuring 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).
FixImplement 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.
StatusUnresolved
High

Potential Reentrancy and MEV Risk in `_liquidateTax`

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

Immutability of Critical External Dependencies

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

Lack of Direct Owner Control over Tax Parameters

M-02While 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).
IssueWhile 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).
FixConsider 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.
StatusUnresolved
Low

Inefficient `_liquidateTax` Trigger Mechanism

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

Upgradeability Considerations for `PackedPoolState` Struct

I-01The `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).
IssueThe `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).
FixWhen 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.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

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

GovernanceHigh1/10

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

UpgradesHigh3/10

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

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

99.4% in top 10
11.7% in wallets87.6% in contracts
Effective Concentration46.8%

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

$17.2K across 3 pairs

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x6f3b…38c5
Unlocked LP Held By
0x14e5…be4a

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

What Raised This Score

12 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

Related Audits

6 more on the record
WebKey DAO 2.0 (WKEYDAO2)Critical RiskPieverse Token (PIEVERSE)Critical RiskSK Hynix (SKHYB)Critical RiskGameStop (GMEB)Critical RiskApple (AAPLB)Critical RiskSandisk Corporation (SNDKB)Critical Risk

Would You Like a More Detailed Audit of SnapCoin?

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

Get Detailed Audit