Quantum Audit Logo

Is SOCK a Scam?

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

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

SOCK SOCK
0x1250…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 2d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 Critical2 Medium1 Low1 Informational
! 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.
Volume 24h
$98.1K
Liquidity
$19.5K
Price
$0.00003551
Token Age
2d
Top 10 Holders
44.4%

Security Findings

1 Crit2 Med1 Low1 Info
Critical

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

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

Centralization Risk with Owner-Controlled State Transitions

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

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

M-02The `_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.
IssueThe `_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.
FixWhile `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.
StatusUnresolved
Low

Precision Loss in Tax Calculation

L-01The 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.
IssueThe 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.
FixAcknowledge 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.
StatusUnresolved
Info

Suboptimal Storage Packing in `PackedPoolState` Struct

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

Category Ratings

TechnicalMedium6/10

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.

GovernanceMedium4/10

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.

UpgradesHigh3/10

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.

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

44.4% in top 10
16.4% in wallets28.0% in contracts
Effective Concentration27.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

$19.5K

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
0xce92…b473
Unlocked LP Held By
0xddac…308c

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

What Raised This Score

11 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

Related Audits

6 more on the record
Infinity Ground AI (AIN)High RiskFinTech AI (FNA)High RiskTopazHigh RiskAnoma (XAN)Critical RiskPlasma (XPL)Critical RiskMirex (MRX)Critical Risk

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