Quantum Audit Logo
Launch App

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

Is Cets On Gold Safe?

CETSBNB 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 record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance7/10Upgrades4/10Checks passed5 of 7Findings3 Medium · 3 Info6
SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with dynamic tax mechanisms and a multi-state pool system.

Read the full analysis
What raised the score
  • Proxy contract
  • Non-standard proxy storage
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 66.2%
  • LP top3 unlocked holders = 90.4%
  • Token age < 30 days
  • 3 Medium finding(s) from audit
Exact factors
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 66.2% (independent LP — depth risk, pool = 94% of DEX liquidity)
  • LP top3 unlocked holders = 90.4% (independent LP — depth risk, pool = 94% of DEX liquidity)
  • Token age < 30 days (still settling)
  • 3 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

Security Checklist

as of audit · Sep 45 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
12.8%Contracts11.6%Wallets75.6%Everyone else
12.8%Contracts11.6%75.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
24.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking12.8%
  • Walletsanonymous holders, free to sell11.6%
  • Everyone elsethe rest of the supply75.6%
Effective concentrationwhat the score reads16.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$554.1K across 4 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$522.2KShare of depth94.2%
Top-1 Unlocked Holder66.2%
Top-3 Unlocked90.4%
Unlocked LP held by
0x1fbf…a2750xfd5d…05960xb3b9…1cc00x30b8…44f40xfebe…384c0xda64…87c80xb7ec…25730xe20b…44930xf92f…4a700xa0b4…4cb2

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

Security Findings

3 Medium3 Info
Medium

External Call Risk in _processTax

The _liquidateTax function calls _processTax (truncated in the provided code). While poolState.notLiquidating acts as a reentrancy guard for the _liquidateTax function itself, _processTax likely involves external calls (e.g., to taxProcessor, dividendContract, or v2Router). If these external contracts are untrusted, compromised, or contain vulnerabilities, they could lead to unexpected behavior, reentrancy into other parts of the FlapTaxTokenV3 contract not protected by notLiquidating, or denial of service if they revert.M-01

Issue

The _liquidateTax function calls _processTax (truncated in the provided code). While poolState.notLiquidating acts as a reentrancy guard for the _liquidateTax function itself, _processTax likely involves external calls (e.g., to taxProcessor, dividendContract, or v2Router). If these external contracts are untrusted, compromised, or contain vulnerabilities, they could lead to unexpected behavior, reentrancy into other parts of the FlapTaxTokenV3 contract not protected by notLiquidating, or denial of service if they revert.

Fix

Thoroughly audit the _processTax function and all external contracts it interacts with. Implement try/catch blocks for external calls within _processTax to handle failures gracefully without reverting the entire transaction. Consider adding a reentrancy guard to _processTax itself if it performs sensitive state changes before/after external calls.

Status

Unresolved

Medium

Denial of Service via _liquidateTax Revert

The _liquidateTax function is invoked at the beginning of every _transfer operation. If _liquidateTax (specifically the truncated _processTax call within it, or any other logic) encounters an error and reverts, it will cause the entire _transfer transaction to revert. This could lead to a denial of service for all token transfers, effectively freezing the token.M-02

Issue

The _liquidateTax function is invoked at the beginning of every _transfer operation. If _liquidateTax (specifically the truncated _processTax call within it, or any other logic) encounters an error and reverts, it will cause the entire _transfer transaction to revert. This could lead to a denial of service for all token transfers, effectively freezing the token.

Fix

Ensure _processTax is highly resilient to failures. Implement try/catch blocks for external calls within _processTax to prevent them from propagating reverts to _transfer. If _processTax is critical, consider a mechanism for the owner to pause/unpause tax processing or to recover from failed liquidations without blocking all transfers.

Status

Unresolved

Medium

Immutability of Critical External Addresses

Several critical external contract addresses, including v2Router, quoteToken, mainPool, taxProcessor, dividendContract, and the pools mapping, are set only during the initialize function and cannot be modified afterward. This immutability means that if any of these addresses become compromised, deprecated, or if the protocol needs to adapt to changes (e.g., router upgrades, new tax processors), the contract would require a costly and disruptive upgrade or redeployment.M-03

Issue

Several critical external contract addresses, including v2Router, quoteToken, mainPool, taxProcessor, dividendContract, and the pools mapping, are set only during the initialize function and cannot be modified afterward. This immutability means that if any of these addresses become compromised, deprecated, or if the protocol needs to adapt to changes (e.g., router upgrades, new tax processors), the contract would require a costly and disruptive upgrade or redeployment.

Fix

Consider adding onlyOwner functions to allow updating these critical addresses. Implement appropriate security measures for these update functions, such as timelocks, multi-signature wallet requirements, or a governance mechanism, to prevent malicious or accidental changes.

Status

Unresolved

Info

Redundant Liquidation Threshold Variables

The contract defines MIN_LIQ_THRESHOLD (immutable), START_LIQ_THRESHOLD (immutable), initialLiquidationThreshold (public state variable), and poolState.liquidationThreshold (part of a packed struct). Both initialLiquidationThreshold and poolState.liquidationThreshold are initialized to START_LIQ_THRESHOLD and are never modified thereafter. This creates redundancy and potential for confusion regarding which variable represents the active liquidation threshold, especially given MIN_LIQ_THRESHOLD is also present but not actively used in the provided logic.I-01

Issue

The contract defines MIN_LIQ_THRESHOLD (immutable), START_LIQ_THRESHOLD (immutable), initialLiquidationThreshold (public state variable), and poolState.liquidationThreshold (part of a packed struct). Both initialLiquidationThreshold and poolState.liquidationThreshold are initialized to START_LIQ_THRESHOLD and are never modified thereafter. This creates redundancy and potential for confusion regarding which variable represents the active liquidation threshold, especially given MIN_LIQ_THRESHOLD is also present but not actively used in the provided logic.

Fix

Clarify the purpose and usage of each liquidation threshold variable in the contract's documentation. Consider removing redundant variables if they serve no distinct purpose to improve code clarity and reduce storage footprint.

Status

Unresolved

Info

Complex _transfer State Machine

The _transfer function implements a complex state machine with multiple if/else if branches based on the PoolState enum. While this design allows for flexible tax and transfer logic, the intricate conditional paths can increase the cognitive load for understanding the contract's behavior and raise the potential for subtle logic errors or edge cases if not thoroughly tested.I-02

Issue

The _transfer function implements a complex state machine with multiple if/else if branches based on the PoolState enum. While this design allows for flexible tax and transfer logic, the intricate conditional paths can increase the cognitive load for understanding the contract's behavior and raise the potential for subtle logic errors or edge cases if not thoroughly tested.

Fix

Ensure comprehensive unit and integration tests cover all possible PoolState transitions and transfer scenarios. Consider refactoring complex conditional logic into smaller, well-named helper functions to improve readability and maintainability.

Status

Unresolved

Info

Hardcoded maxSupply

The maxSupply of the token is defined as a constant with a value of 1e9 ether. This design choice fixes the total supply of the token permanently. While this might be the intended economic model, it means the total supply cannot be adjusted (e.g., for burning or minting beyond initial supply) without a contract upgrade.I-03

Issue

The maxSupply of the token is defined as a constant with a value of 1e9 ether. This design choice fixes the total supply of the token permanently. While this might be the intended economic model, it means the total supply cannot be adjusted (e.g., for burning or minting beyond initial supply) without a contract upgrade.

Fix

Document this design choice clearly, confirming that a fixed supply is the intended and desired behavior for the token's economic model.

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 multi-state pool system. The contract utilizes OpenZeppelin's upgradeable standards, ensuring a robust foundation. Key findings include potential risks associated with external calls in the _processTax function, which could lead to denial of service or reentrancy if not handled carefully. Additionally, the immutability of critical external addresses post-initialization presents a rigidity risk, and the _liquidateTax function's execution on every transfer introduces a single point of failure for all token operations. Several informational findings highlight areas for improved clarity and documentation.

Technical8/10Low risk

The contract demonstrates a solid technical foundation, leveraging OpenZeppelin's upgradeable ERC20 and access control components (7.2 Code Security, 7.1 Architecture). The PackedPoolState struct is a good example of gas-efficient storage. However, the _liquidateTax function, called on every transfer, contains an external call to _processTax (7.6 External), which, if vulnerable or prone to reverting, could lead to a denial of service for all token transfers (7.2 Code Security). The complex state machine within the _transfer function, while functional, increases the potential for subtle logic errors (7.2 Code Security).

Governance7/10Low risk

Access control is appropriately managed with OwnableUpgradeable for critical state transitions like startMigration and finalizeMigration (7.3 Access Control). However, several critical external addresses, such as v2Router, taxProcessor, and dividendContract, are set only during initialization and cannot be updated by the owner (7.5 Governance). This immutability introduces rigidity, requiring a contract upgrade for any necessary address changes. The token's maxSupply is hardcoded as a constant, fixing the total supply (7.4 Economic).

Upgrades4/10Medium risk

The contract is designed for upgradeability using OpenZeppelin's Initializable pattern (7.7 Upgrades). The _disableInitializers() in the constructor and the initializer modifier are correctly implemented, preventing re-initialization. The use of ERC20Upgradeable and OwnableUpgradeable ensures compatibility with proxy patterns. Future upgrades must carefully manage storage layout, especially with the PackedPoolState struct, to avoid collisions.

Final RecommendationWhat to do about this score

Prioritize a thorough audit of the _processTax function and all external contracts it interacts with, implementing robust error handling and reentrancy protection.

Consider adding owner-controlled update functions for critical external addresses, protected by a timelock or multi-signature wallet, to enhance protocol adaptability. Ensure comprehensive testing covers all state transitions and edge cases within the _transfer logic to mitigate potential denial of service risks.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age25d
Contract0xb0c2…7777
Deployer0xce27…5b18
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Badge for your website
Cets On Gold 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, 202635Medium
  2. Aug 31, 202616Low

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

Related Audits

6 more on the recordAll audits
MOMOBNB Chain35MediumXPIN TokenXPIN · BNB Chain34LowTRADOORBNB Chain34LowBeat TokenBEAT · BNB Chain34LowNew BNB CoinNNB · BNB Chain34LowSpaceXcoinBNB Chain34Low

Would You Like a More Detailed Audit of Cets On Gold?

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

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