Quantum Audit Logo

Is Saturn a Scam?

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

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

Saturn SATURN
0xf23e…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 4d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

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.

1 Critical1 High1 Medium1 Low1 Informational
! 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.
Volume 24h
$398.1K
Liquidity
$70.2K
Price
$0.0003759
Token Age
4d
Top 10 Holders
28.8%

Security Findings

1 Crit1 High1 Med1 Low1 Info
Critical

Incomplete `_liquidateTax` Function Analysis

C-01The 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.
IssueThe 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.
FixProvide 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.
StatusUnresolved
High

Centralized Control by Owner

H-01The 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.
IssueThe 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.
FixConsider 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.
StatusUnresolved
Medium

Complex State Machine Logic

M-01The 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.
IssueThe 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.
FixThoroughly 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.
StatusUnresolved
Low

Potential for Front-running State Transitions

L-01The `_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.
IssueThe `_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.
FixWhile `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.
StatusUnresolved
Info

Reliance on External Contracts

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

Category Ratings

TechnicalMedium6/10

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

GovernanceLow7/10

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

UpgradesMedium4/10

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

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source

Holder Composition

28.8% in top 10
3.4% in wallets25.3% in contracts
Effective Concentration13.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

$70.2K across 3 pairs
Pancakeswap v2WBNBanalysed$70.2K100.0%Uniswap v2USDT$00.0%Uniswap v2WBNB$00.0%

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

LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

1 addresses
Deployer
0xcd4f…864c

What Raised This Score

7 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

Related Audits

6 more on the record
ARKMedium Risk牛来Medium RiskMax Sister (LILY)Medium RiskXPIN Token (XPIN)Medium RiskTRADOORMedium RiskTutorial (TUT)Medium Risk

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