Quantum Audit Logo
Launch App

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

Is SOCK a Scam?

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 · 2d old
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance4/10Upgrades3/10Checks passed4 of 7Findings1 Critical · 2 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic taxation and liquidation mechanisms.

Read the full analysis
What raised the score
  • Proxy contract
  • Non-standard proxy storage
  • Top-10 concentration > 20%
  • 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 < 7 days
  • 1 Critical 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 > 20% (44.4% total → 27.6% effective; 16.4% in EOAs, 28.0% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($19,480 across 1 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 < 7 days (early, volatile)
  • 1 Critical 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 (2d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.

Security Checklist

as of audit · Sep 44 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax3% / 3%

Holders

as of audit · Sep 4, 2026
28.0%Contracts16.4%Wallets55.6%Everyone else
28.0%Contracts16.4%Wallets55.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
44.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking28.0%
  • Walletsanonymous holders, free to sell16.4%
  • Everyone elsethe rest of the supply55.6%
Effective concentrationwhat the score reads27.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$19.5K

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$19.5KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xddac…308c

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

Security Findings

1 Critical2 Medium1 Low1 Info
Critical

Denial of Service (DoS) on All Transfers Due to Reverting External Calls

The _liquidateTax function is called at the beginning of every _transfer operation. This function contains external calls to ITaxProcessor(taxProcessor).processTax(...) and IDividend(dividendContract).distributeDividends(...). If either of these external calls reverts for any reason (e.g., misconfiguration, temporary issues in the external contract, or malicious action targeting the external contract), all subsequent _transfer calls will also revert, effectively halting all token transfers for all users. This constitutes a severe denial of service for the entire token functionality.C-01

Issue

The _liquidateTax function is called at the beginning of every _transfer operation. This function contains external calls to ITaxProcessor(taxProcessor).processTax(...) and IDividend(dividendContract).distributeDividends(...). If either of these external calls reverts for any reason (e.g., misconfiguration, temporary issues in the external contract, or malicious action targeting the external contract), all subsequent _transfer calls will also revert, effectively halting all token transfers for all users. This constitutes a severe denial of service for the entire token functionality.

Fix

Implement robust error handling for external calls within _liquidateTax. Consider using try/catch blocks to gracefully handle reverts without blocking core token transfers. Alternatively, decouple the tax liquidation process from the _transfer function. This could involve moving the liquidation logic to a separate, owner-callable function or a function that can be called by anyone but does not revert if external calls fail (e.g., by using a pull-based mechanism for tax processing or allow…

Status

Unresolved

Medium

Centralization Risk with Owner-Controlled State Transitions

The OwnableUpgradeable pattern grants the contract owner significant control over critical state transitions. Functions like startMigration and finalizeMigration are onlyOwner and directly change the poolState, which dictates the token's taxation rules. While necessary for initial setup and migration, this centralized control allows the owner to unilaterally alter the token's economic behavior, potentially without sufficient community oversight or warning. The taxProcessor and dividendContract addresses are set during initialization and cannot be changed, but the owner's ability to trigger state changes that affect their interaction is significant.M-01

Issue

The OwnableUpgradeable pattern grants the contract owner significant control over critical state transitions. Functions like startMigration and finalizeMigration are onlyOwner and directly change the poolState, which dictates the token's taxation rules. While necessary for initial setup and migration, this centralized control allows the owner to unilaterally alter the token's economic behavior, potentially without sufficient community oversight or warning. The taxProcessor and dividendContract addresses are set during initialization and cannot be changed, but the owner's ability to trigger state changes that affect their interaction is significant.

Fix

For critical owner-controlled functions that significantly alter the token's economic model, consider implementing a timelock mechanism. This would introduce a delay between the owner initiating a change and it becoming effective, providing users and the community with time to react or exit if they disagree with the proposed changes. Additionally, review if any other critical parameters should be immutable or have a more decentralized update mechanism.

Status

Unresolved

Medium

Potential for Front-running/MEV on Time-Based State Transitions

The _liquidateTax function modifies the poolState based on block.timestamp exceeding taxExpirationTime or antiFarmerExpirationTime. Specifically, it can transition the pool state from TaxEnforcedAntiFarmer to TaxEnforced or TaxFree. If the economic impact of these state changes (e.g., changes in tax rates) is significant, malicious actors or miners could front-run transactions to ensure their operations occur just before or after a state transition, potentially gaining an unfair advantage. While block.timestamp is a standard mechanism, its manipulability by miners within a small window is a known vector for MEV.M-02

Issue

The _liquidateTax function modifies the poolState based on block.timestamp exceeding taxExpirationTime or antiFarmerExpirationTime. Specifically, it can transition the pool state from TaxEnforcedAntiFarmer to TaxEnforced or TaxFree. If the economic impact of these state changes (e.g., changes in tax rates) is significant, malicious actors or miners could front-run transactions to ensure their operations occur just before or after a state transition, potentially gaining an unfair advantage. While block.timestamp is a standard mechanism, its manipulability by miners within a small window is a known vector for MEV.

Fix

While block.timestamp is commonly used, be aware of its limitations regarding precise timing and potential for MEV. If the economic implications of these state transitions are critical, consider if alternative mechanisms (e.g., a commit-reveal scheme, or requiring a specific block number instead of timestamp for critical changes) could mitigate front-running. Ensure that the economic model accounts for potential MEV around these state changes.

Status

Unresolved

Low

Precision Loss in Tax Calculation

The tax calculation (amount * rate) / 10000 uses integer division. For small amount values or small buyTaxRate/sellTaxRate values, this can result in a calculated tax of 0, even if a fractional tax should theoretically apply. For example, if amount is 100 and rate is 1 (representing 0.01%), the calculation (100 * 1) / 10000 yields 0. This means the protocol might collect slightly less tax than intended for small transactions.L-01

Issue

The tax calculation (amount * rate) / 10000 uses integer division. For small amount values or small buyTaxRate/sellTaxRate values, this can result in a calculated tax of 0, even if a fractional tax should theoretically apply. For example, if amount is 100 and rate is 1 (representing 0.01%), the calculation (100 * 1) / 10000 yields 0. This means the protocol might collect slightly less tax than intended for small transactions.

Fix

Acknowledge that integer division inherently causes precision loss. If this minor loss is acceptable for the protocol's economic model, no change is strictly necessary. If higher precision is desired for very small transactions or rates, consider using a higher precision fixed-point math library or adjusting the tax rate basis (e.g., using a denominator of 100_000 or 1_000_000 instead of 10_000) to allow for finer granularity in tax rates.

Status

Unresolved

Info

Suboptimal Storage Packing in PackedPoolState Struct

The PackedPoolState struct contains members of various sizes: uint8, uint16, bool, uint96, uint64, uint48. While Solidity attempts to pack variables into 32-byte storage slots, the current ordering may not be optimal. Reordering the members from largest to smallest (or grouping smaller types strategically) can reduce the number of storage slots used, thereby saving gas on state reads and writes.I-01

Issue

The PackedPoolState struct contains members of various sizes: uint8, uint16, bool, uint96, uint64, uint48. While Solidity attempts to pack variables into 32-byte storage slots, the current ordering may not be optimal. Reordering the members from largest to smallest (or grouping smaller types strategically) can reduce the number of storage slots used, thereby saving gas on state reads and writes.

Fix

Reorder the PackedPoolState struct members to optimize storage packing. A more efficient order would typically place larger data types before smaller ones, for example: uint96 liquidationThreshold, uint64 taxExpirationTime, uint48 antiFarmerExpirationTime, uint16 buyTaxRate, uint16 sellTaxRate, uint8 state, bool notLiquidating. This could potentially reduce the number of storage slots from 3 to 1 or 2, leading to gas savings.

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 taxation and liquidation mechanisms. The audit identified a critical denial of service vulnerability where external calls within the transfer logic can halt all token transfers. Medium risks include significant owner control over critical state transitions and potential for front-running on tax rate changes. The contract utilizes OpenZeppelin's upgradeable patterns effectively, ensuring upgrade safety. Recommendations focus on robust error handling for external interactions, decentralizing control where feasible, and optimizing gas efficiency.

Technical6/10Medium risk

The contract demonstrates a well-structured architecture (7.1) using OpenZeppelin standards for ERC20 and upgradeability. However, a critical code security (7.2) vulnerability exists where external calls to taxProcessor and dividendContract within the _liquidateTax function, which is called on every transfer, can cause all token transfers to revert if these external calls fail. This represents a severe denial of service. Additionally, minor precision loss (7.2) in tax calculations due to integer division was noted, and struct packing (7.2) could be optimized for gas efficiency.

Governance4/10Medium risk

The contract's economic model (7.4) involves dynamic tax rates and state transitions (e.g., BondingCurve to TaxEnforcedAntiFarmer). Access control (7.3) is managed via OwnableUpgradeable, granting the owner significant power to initiate migration phases (startMigration, finalizeMigration) which alter the token's tax behavior. This centralization introduces a medium risk. Furthermore, state changes based on block.timestamp within _liquidateTax could be susceptible to front-running or MEV (7.4) if the economic impact of these transitions is substantial, potentially allowing actors to gain an advantage.

Upgrades3/10High risk

The contract is designed as an upgradeable proxy (7.7) using OpenZeppelin's Initializable and ERC20Upgradeable patterns. The constructor correctly calls _disableInitializers() to prevent re-initialization of the implementation contract. The initialize function uses the initializer modifier, ensuring it can only be called once. This setup adheres to standard upgradeability best practices, minimizing risks associated with upgrades.

Final RecommendationWhat to do about this score

Prioritize addressing the critical denial of service vulnerability by implementing robust error handling for external calls within the _liquidateTax function.

Consider moving tax processing to a separate, pull-based mechanism or an owner-triggered function to decouple it from core token transfers. Evaluate the economic impact of owner-controlled state transitions and explore options for decentralization or timelocks for critical parameters. Finally, optimize struct packing for gas efficiency and acknowledge the precision loss in tax calculations.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age2d
Contract0x1250…7777
Deployer0xce92…b473
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Badge for your website
SOCK 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, 202670High
  2. Sep 3, 202651Medium

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

Related Audits

6 more on the recordAll audits
Infinity Ground AIAIN · BNB Chain70HighFinTech AIFNA · BNB Chain70HighTopazBNB Chain70HighLitecoin TokenLTC · BNB Chain70HighiShares China Large-Cap ETF (Ondo Tokenized)FXION · BNB Chain70HighAnomaXAN · BNB Chain71High

Would You Like a More Detailed Audit of SOCK?

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

Get Detailed Audit Is this your token? Publish your own audit on this page