Quantum Audit Logo
Launch App

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

Is Saturn a Scam?

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

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

Read the full analysis
What raised the score
  • Proxy contract
  • Non-standard proxy storage
  • Token age < 7 days
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 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)
  • Token age < 7 days (early, volatile)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 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 (4d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.

Security Checklist

as of audit · Sep 45 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax1% / 1%

Holders

as of audit · Sep 4, 2026
25.3%Contracts3.4%71.2%Everyone else
25.3%Contracts71.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
28.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking25.3%
  • Walletsanonymous holders, free to sell3.4%
  • Everyone elsethe rest of the supply71.2%
Effective concentrationwhat the score reads13.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$70.2K across 3 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$70.2KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Security Findings

1 Critical1 High1 Medium1 Low1 Info
Critical

Incomplete _liquidateTax Function Analysis

The provided source code for the _liquidateTax function is truncated. This function is invoked on every _transfer to the mainPool and is responsible for critical operations including PoolState transitions, tax distribution to taxProcessor and dividendContract, and potential swaps via v2Router. Without the complete implementation, it is impossible to assess fundamental security properties such as reentrancy vulnerabilities, potential denial-of-service conditions, integer overflows/underflows in tax calculations or external interactions, and overall economic integrity.C-01

Issue

The provided source code for the _liquidateTax function is truncated. This function is invoked on every _transfer to the mainPool and is responsible for critical operations including PoolState transitions, tax distribution to taxProcessor and dividendContract, and potential swaps via v2Router. Without the complete implementation, it is impossible to assess fundamental security properties such as reentrancy vulnerabilities, potential denial-of-service conditions, integer overflows/underflows in tax calculations or external interactions, and overall economic integrity.

Fix

Provide the full and complete source code for the _liquidateTax function to allow for a comprehensive security audit. A full audit of this function is essential to ensure the safety and correctness of the token's core economic mechanisms.

Status

Unresolved

High

Centralized Control by Owner

The contract utilizes the OwnableUpgradeable pattern, granting the owner sole control over critical functions such as startMigration and finalizeMigration. These functions directly alter the PoolState, which in turn affects tax rates and transfer restrictions. This centralized control introduces a single point of failure, where a compromised owner key or a malicious owner could unilaterally change the token's operational parameters, potentially leading to economic manipulation or system disruption.H-01

Issue

The contract utilizes the OwnableUpgradeable pattern, granting the owner sole control over critical functions such as startMigration and finalizeMigration. These functions directly alter the PoolState, which in turn affects tax rates and transfer restrictions. This centralized control introduces a single point of failure, where a compromised owner key or a malicious owner could unilaterally change the token's operational parameters, potentially leading to economic manipulation or system disruption.

Fix

Consider implementing a multi-signature wallet for the owner address to distribute control among multiple trusted parties. For highly sensitive operations, explore adding time-locks to allow for community review or emergency intervention before changes take effect.

Status

Unresolved

Medium

Complex State Machine Logic

The contract implements a complex state machine using the PoolState enum (BondingCurve, Migrating, TaxEnforcedAntiFarmer, TaxEnforced, TaxFree) with transitions managed within _transfer and _liquidateTax. The intricate conditions and order of checks for state changes, especially those dependent on block.timestamp and pools mapping, increase the likelihood of subtle logic errors or unintended state transitions. Such errors could lead to incorrect tax application, unexpected transfer restrictions, or economic imbalances.M-01

Issue

The contract implements a complex state machine using the PoolState enum (BondingCurve, Migrating, TaxEnforcedAntiFarmer, TaxEnforced, TaxFree) with transitions managed within _transfer and _liquidateTax. The intricate conditions and order of checks for state changes, especially those dependent on block.timestamp and pools mapping, increase the likelihood of subtle logic errors or unintended state transitions. Such errors could lead to incorrect tax application, unexpected transfer restrictions, or economic imbalances.

Fix

Thoroughly review and test all state transitions and their associated conditions. Consider formal verification methods or extensive unit and integration testing to cover all possible state paths and edge cases. Document the state machine logic clearly to aid future understanding and maintenance.

Status

Unresolved

Low

Potential for Front-running State Transitions

The _liquidateTax function triggers PoolState changes based on block.timestamp exceeding specific expiration times (taxExpirationTime, antiFarmerExpirationTime). If a state transition (e.g., from TaxEnforced to TaxFree) offers a significant economic advantage, malicious actors could monitor the mempool for transactions that would trigger these changes. They could then front-run such transactions to gain an unfair advantage by executing their own transactions (e.g., large trades) just before the state change occurs.L-01

Issue

The _liquidateTax function triggers PoolState changes based on block.timestamp exceeding specific expiration times (taxExpirationTime, antiFarmerExpirationTime). If a state transition (e.g., from TaxEnforced to TaxFree) offers a significant economic advantage, malicious actors could monitor the mempool for transactions that would trigger these changes. They could then front-run such transactions to gain an unfair advantage by executing their own transactions (e.g., large trades) just before the state change occurs.

Fix

While block.timestamp is inherently susceptible to miner manipulation and front-running, for time-based state transitions, consider if the economic impact of front-running is acceptable. If not, explore alternative mechanisms that are less susceptible to front-running, such as commit-reveal schemes or batching transactions, though these often add complexity.

Status

Unresolved

Info

Reliance on External Contracts

The FlapTaxTokenV3 contract relies on several external contracts, including taxProcessor, dividendContract, v2Router, and quoteToken. The security and trustworthiness of these external dependencies are paramount to the overall integrity of the system. Any vulnerabilities, malicious behavior, or incorrect configuration in these external contracts could directly impact the functionality and security of the FlapTaxTokenV3 token.I-01

Issue

The FlapTaxTokenV3 contract relies on several external contracts, including taxProcessor, dividendContract, v2Router, and quoteToken. The security and trustworthiness of these external dependencies are paramount to the overall integrity of the system. Any vulnerabilities, malicious behavior, or incorrect configuration in these external contracts could directly impact the functionality and security of the FlapTaxTokenV3 token.

Fix

Ensure that all external contract addresses are correctly configured and point to audited, trusted, and immutable contracts where possible. Implement robust validation for external contract addresses during initialization and any subsequent updates. Regularly monitor the security posture of all integrated external protocols.

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 a dynamic tax mechanism and a multi-state pool system. The contract utilizes OpenZeppelin's upgradeable patterns and SafeERC20 for secure token operations. However, a critical portion of the _liquidateTax function, which is central to the token's economic logic and state transitions, was truncated in the provided source code, preventing a complete security assessment of this core functionality. This significantly elevates the overall risk level.

Technical6/10Medium risk

The contract leverages well-audited OpenZeppelin libraries for ERC20, access control (Ownable), and upgradeability (Initializable), enhancing code security (7.2 Code Security). The use of SafeERC20 mitigates common ERC20 interaction risks. However, the core _liquidateTax function, critical for tax processing and state transitions, is truncated, preventing a full assessment of potential reentrancy, integer overflows, or other logic errors (7.2 Code Security). The complex state machine for PoolState and its transitions introduces significant logic complexity, increasing the surface area for potential vulnerabilities (7.1 Architecture).

Governance7/10Low risk

The contract employs an OwnableUpgradeable pattern, granting the owner significant control over critical functions like startMigration and finalizeMigration, which directly influence the token's PoolState and tax enforcement (7.5 Governance, 7.3 Access Control). This centralization introduces a single point of failure. The economic model, particularly the tax rates and liquidation thresholds, is dynamic and depends heavily on the PoolState transitions (7.4 Economic). The full economic implications of the tax distribution and liquidation process cannot be fully assessed due to the truncated _liquidateTax function (7.4 Economic).

Upgrades4/10Medium risk

The contract is designed for upgradeability using OpenZeppelin's Initializable pattern, correctly employing _disableInitializers() in the constructor and initializer modifier for the initialize function (7.7 Upgrades). State variables are declared appropriately for proxy storage, and immutable variables are handled correctly. This standard approach minimizes common upgrade-related risks, assuming the proxy itself is correctly configured (e.7 Upgrades).

Final RecommendationWhat to do about this score

It is imperative to provide the complete source code for the _liquidateTax function to enable a comprehensive security assessment of the token's core economic and operational logic.

Additionally, consider implementing multi-signature wallets or time-locks for critical owner-controlled functions to mitigate risks associated with centralized control. Thoroughly review the complex state machine logic to ensure all transitions and conditions are robust and free from unintended behavior.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age4d
Contract0xf23e…7777
Deployer0xcd4f…864c
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Badge for your website
Saturn 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, 202633Low
  2. Sep 2, 202614Low

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

Related Audits

6 more on the recordAll audits
ARKBNB Chain33Low牛来BNB Chain33LowMax SisterLILY · BNB Chain33LowTrusta.AITA · BNB Chain33LowMeta Financial AIMEFAI · BNB Chain33LowXeleb AIXCX · BNB Chain33Low

Would You Like a More Detailed Audit of Saturn?

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