Quantum Audit Logo

Is bStocks Never Sleep Safe?

On-chain security analysis — is it a scam or legit?

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

bStocks Never Sleep BSTOCKS
0x244b…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a dynamic tax mechanism and pool-based state transitions. The audit identified a critical vulnerability due to the incomplete `_processTax` function, which is central to the token's economic model. Additionally, a high-severity bug in timestamp calculation for tax expiration and medium-severity concerns regarding long-term timestamp truncation and high centralization risk were found. These issues significantly impact the contract's functionality, security, and long-term viability.

1 Critical1 High2 Medium
Volume 24h
$12.9K
Liquidity
$30.2K
Price
$0.00006095
Token Age
8d
Top 10 Holders
46.0%

Security Findings

1 Crit1 High2 Med
Critical

Incomplete `_processTax` Function

C-01The `_processTax` function, which is called within `_liquidateTax` and is responsible for handling accumulated tax amounts, is entirely missing from the provided source code. This function is central to the token's economic model and its interactions with the `taxProcessor` and `dividendContract`. Without its implementation, the core functionality of tax distribution and liquidation cannot be assessed for security vulnerabilities, including reentrancy, incorrect calculations, or improper external calls.
IssueThe `_processTax` function, which is called within `_liquidateTax` and is responsible for handling accumulated tax amounts, is entirely missing from the provided source code. This function is central to the token's economic model and its interactions with the `taxProcessor` and `dividendContract`. Without its implementation, the core functionality of tax distribution and liquidation cannot be assessed for security vulnerabilities, including reentrancy, incorrect calculations, or improper external calls.
FixComplete the implementation of the `_processTax` function. Ensure it correctly handles the accumulated tax, interacts securely with `taxProcessor` and `dividendContract`, and implements reentrancy guards if external calls are made. The completed function must be thoroughly audited.
StatusUnresolved
High

Incorrect `taxExpirationTime` Calculation in `finalizeMigration`

H-01In the `finalizeMigration` function, the `taxExpirationTime` is updated with `currentPoolState.taxExpirationTime + block.timestamp`. If `currentPoolState.taxExpirationTime` is already an absolute timestamp (as implied by its usage with `block.timestamp > currentPoolState.taxExpirationTime`), adding `block.timestamp` to it will result in an extremely large and incorrect future timestamp, effectively making the tax period last for an unintended, excessively long duration.
IssueIn the `finalizeMigration` function, the `taxExpirationTime` is updated with `currentPoolState.taxExpirationTime + block.timestamp`. If `currentPoolState.taxExpirationTime` is already an absolute timestamp (as implied by its usage with `block.timestamp > currentPoolState.taxExpirationTime`), adding `block.timestamp` to it will result in an extremely large and incorrect future timestamp, effectively making the tax period last for an unintended, excessively long duration.
FixCorrect the calculation of `taxExpirationTime` in `finalizeMigration`. If the intention is to extend the tax period from the current time, it should be `block.timestamp + duration` (where `duration` is the intended extension). If it's meant to be a fixed absolute time, it should be set directly. Ensure the logic aligns with the intended economic model.
StatusUnresolved
Medium

Long-Term Timestamp Truncation Risk

M-01The `taxExpirationTime` (uint64) and `antiFarmerExpirationTime` (uint48) variables are used to store `block.timestamp` values. While sufficient for current operations, `block.timestamp` is a `uint256`. Casting it to `uint64` or `uint48` introduces a truncation risk in the distant future (approximately 2070 for `uint64` and 2040 for `uint48`). If the contract is intended for operation beyond these dates, this could lead to unexpected behavior and incorrect state transitions.
IssueThe `taxExpirationTime` (uint64) and `antiFarmerExpirationTime` (uint48) variables are used to store `block.timestamp` values. While sufficient for current operations, `block.timestamp` is a `uint256`. Casting it to `uint64` or `uint48` introduces a truncation risk in the distant future (approximately 2070 for `uint64` and 2040 for `uint48`). If the contract is intended for operation beyond these dates, this could lead to unexpected behavior and incorrect state transitions.
FixConsider using `uint256` for `taxExpirationTime` and `antiFarmerExpirationTime` if the contract is expected to operate for several decades. Alternatively, implement a migration strategy or a mechanism to reset these values before the truncation threshold is reached.
StatusUnresolved
Medium

High Centralization Risk via Owner Privileges

M-02The `onlyOwner` role has extensive control over critical contract parameters and state transitions. The owner can initiate and finalize migration (`startMigration`, `finalizeMigration`), which changes the `PoolState` and affects tax enforcement. The owner also sets crucial external addresses (`taxProcessor`, `dividendContract`, `v2Router`, `quoteToken`, `mainPool`, and other `pools`) during initialization. This high degree of centralization means a single compromised or malicious owner account could significantly impact the protocol's integrity and user funds.
IssueThe `onlyOwner` role has extensive control over critical contract parameters and state transitions. The owner can initiate and finalize migration (`startMigration`, `finalizeMigration`), which changes the `PoolState` and affects tax enforcement. The owner also sets crucial external addresses (`taxProcessor`, `dividendContract`, `v2Router`, `quoteToken`, `mainPool`, and other `pools`) during initialization. This high degree of centralization means a single compromised or malicious owner account could significantly impact the protocol's integrity and user funds.
FixTo mitigate centralization risks, consider implementing a multi-signature wallet for the owner address. For highly sensitive operations, a time-lock mechanism could be introduced to provide a delay before changes take effect, allowing the community or users to react to potentially malicious actions.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract utilizes OpenZeppelin's upgradeable standards (ERC20Upgradeable, OwnableUpgradeable, Initializable) and `SafeERC20` for secure token interactions, demonstrating good foundational practices (7.2 Code Security). However, a critical vulnerability exists due to the truncated `_processTax` function, which is essential for tax liquidation and external interactions, preventing a full security assessment (7.2 Code Security, 7.6 External). A high-severity bug in `finalizeMigration` incorrectly calculates `taxExpirationTime` by adding `block.timestamp` to an existing absolute timestamp, leading to an excessively large and incorrect value (7.1 Architecture, 7.2 Code Security). Furthermore, the use of `uint64` and `uint48` for `taxExpirationTime` and `antiFarmerExpirationTime` introduces a long-term risk of `block.timestamp` truncation, potentially causing unexpected state transitions in the distant future (7.1 Architecture).

GovernanceMedium4/10

The contract's economic model involves dynamic buy/sell taxes and a liquidation mechanism, which are central to its design (7.4 Economic). The `onlyOwner` role holds significant control, allowing the owner to initiate and finalize migration, set critical external addresses (tax processor, dividend contract, router), and manage pool addresses (7.3 Access Control, 7.5 Governance). While common for initial deployments, this high degree of centralization presents a medium risk, as the owner could manipulate parameters or external integrations. The tax calculation logic appears sound, but its ultimate impact depends heavily on the missing `_processTax` implementation (7.4 Economic).

UpgradesHigh3/10

The contract is designed as an upgradeable proxy implementation, correctly using OpenZeppelin's `Initializable` and `_disableInitializers()` in the constructor (7.7 Upgrades). This allows for future upgrades to fix bugs or add features without redeploying the entire system. However, `MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` are declared as `immutable`, meaning these specific parameters cannot be altered in future upgrades, which might limit flexibility (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

46.0% in top 10
14.1% in wallets31.9% in contracts
Effective Concentration26.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

$33.8K across 3 pairs
Pancakeswap v2SPYBanalysed$30.2K89.3%Pancakeswap v3USDT$3.6K10.7%

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

Key Addresses

10 addresses
Deployer
0x7eaf…4837
Unlocked LP Held By
0xf949…02980x2ee3…3c7f0x61d0…92ef0x12af…c9cc0xd379…60d80x7551…c6120x41ba…90f00x358c…e6b80x12e3…eb97

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% (46.0% total → 26.8% effective; 14.1% in EOAs, 31.9% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($33,829 across 3 pairs — thin market)
  • LP top1 unlocked holder = 99.9% (independent LP — depth risk, pool = 89% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 89% of DEX liquidity)
  • Token age < 30 days (still settling)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 Medium 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
金蟾 (JIN)Critical RiskZypher Token (POP)Critical RiskSOLANA (SOL)Critical RiskSTBL_Token - STBL Governance Token (STBL)Critical RiskTartSwap (TART)Critical RiskSpaceX (SPCXB)Critical Risk

Would You Like a More Detailed Audit of bStocks Never Sleep?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit