Quantum Audit Logo

Is Cets On Gold Safe?

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

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

Cets On Gold CETS
0xb0c2…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

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.

3 Medium3 Informational
Volume 24h
$1.10M
Liquidity
$522.2K
Price
$0.0155
Token Age
25d
Top 10 Holders
24.4%

Security Findings

3 Med3 Info
Medium

External Call Risk in `_processTax`

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

Denial of Service via `_liquidateTax` Revert

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

Immutability of Critical External Addresses

M-03Several 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.
IssueSeveral 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.
FixConsider 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.
StatusUnresolved
Info

Redundant Liquidation Threshold Variables

I-01The 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.
IssueThe 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.
FixClarify 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.
StatusUnresolved
Info

Complex `_transfer` State Machine

I-02The `_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.
IssueThe `_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.
FixEnsure 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.
StatusUnresolved
Info

Hardcoded `maxSupply`

I-03The `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.
IssueThe `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.
FixDocument this design choice clearly, confirming that a fixed supply is the intended and desired behavior for the token's economic model.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceLow7/10

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

UpgradesMedium4/10

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.

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

24.4% in top 10
11.6% in wallets12.8% in contracts
Effective Concentration16.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

$554.1K across 4 pairs
Pancakeswap v2XAUtanalysed$522.2K94.2%Pancakeswap v3USDT$26.2K4.7%Pancakeswap v34$3.3K0.6%Uniswap v2XAUt$2.5K0.4%

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 Holder66.2%
Top-3 Unlocked90.4%

Key Addresses

11 addresses
Deployer
0xce27…5b18
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.

What Raised This Score

7 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

Related Audits

6 more on the record
XPIN Token (XPIN)Medium RiskTRADOORMedium RiskBeat Token (BEAT)Medium RiskNew BNB Coin (NNB)Medium RiskSpaceXcoinMedium RiskGen Z (Z)Medium Risk

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