Quantum Audit Logo

Is Binancians a Scam?

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

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

Binancians BINANCIANS
0xa15a…7777
BNB Chain
Not verifiedThis 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 today 1 audit on record New Launch · 19h old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The audit of FlapTaxTokenV3 identified critical and high-severity vulnerabilities related to inconsistent state management, denial of service risks from external calls, and reentrancy. While the contract leverages OpenZeppelin's upgradeable patterns and efficient storage, these core logic and interaction flaws pose significant risks to the protocol's stability and economic model. Medium and low-severity issues regarding owner centralization and potential integer truncation were also noted. A critical informational finding was also noted due to truncated code.

1 Critical2 High1 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (19h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$404.8K
Liquidity
$53.1K
Price
$0.0002744
Token Age
19h
Top 10 Holders
37.2%

Security Findings

1 Crit2 High1 Med1 Low1 Info
Critical

Inconsistent `taxExpirationTime` Logic Leading to Premature Tax-Free State

C-01The `taxExpirationTime` variable is initialized as a duration (`uint64(params.taxDuration)`) in `initialize`. However, in `finalizeMigration`, `block.timestamp` is added to it, converting it into an absolute timestamp. The `_liquidateTax` function then compares `block.timestamp` directly to `currentPoolState.taxExpirationTime`. If `finalizeMigration` is *not* called, `taxExpirationTime` remains a duration. In this scenario, `block.timestamp > duration` will almost immediately evaluate to true (as `block.timestamp` is a large absolute number and `duration` is a relatively small number of seconds), causing the contract to prematurely transition to `PoolState.TaxFree`, effectively disabling ta…
IssueThe `taxExpirationTime` variable is initialized as a duration (`uint64(params.taxDuration)`) in `initialize`. However, in `finalizeMigration`, `block.timestamp` is added to it, converting it into an absolute timestamp. The `_liquidateTax` function then compares `block.timestamp` directly to `currentPoolState.taxExpirationTime`. If `finalizeMigration` is *not* called, `taxExpirationTime` remains a duration. In this scenario, `block.timestamp > duration` will almost immediately evaluate to true (as `block.timestamp` is a large absolute number and `duration` is a relatively small number of seconds), causing the contract to prematurely transition to `PoolState.TaxFree`, effectively disabling ta…
FixEnsure `taxExpirationTime` consistently represents either a duration or an absolute timestamp. If it's an absolute timestamp, it should be initialized as `uint64(block.timestamp + params.taxDuration)` in `initialize`. If it's a duration, the comparison in `_liquidateTax` needs to be adjusted (e.g., `block.timestamp > initialTimestamp + currentPoolState.taxExpirationTime`).
StatusUnresolved
High

Denial of Service via External Calls in `_liquidateTax`

H-01The `_liquidateTax` function, called during every `_transfer` to the `mainPool`, makes external calls to `ITaxProcessor(taxProcessor).processTax(...)` and `IDividend(dividendContract).distribute(...)`. If either `taxProcessor` or `dividendContract` is a malicious contract, or contains a bug that causes it to revert, all transfers to the `mainPool` will be blocked. This creates a single point of failure and can lead to a denial of service for critical token functionality.
IssueThe `_liquidateTax` function, called during every `_transfer` to the `mainPool`, makes external calls to `ITaxProcessor(taxProcessor).processTax(...)` and `IDividend(dividendContract).distribute(...)`. If either `taxProcessor` or `dividendContract` is a malicious contract, or contains a bug that causes it to revert, all transfers to the `mainPool` will be blocked. This creates a single point of failure and can lead to a denial of service for critical token functionality.
FixImplement robust error handling for external calls. Consider using a pull-based mechanism for tax processing and dividend distribution, or implement a circuit breaker/emergency pause mechanism for these external interactions. Ensure `taxProcessor` and `dividendContract` are highly trusted and thoroughly audited.
StatusUnresolved
High

Reentrancy Risk in `_liquidateTax`

H-02The `_liquidateTax` function performs state changes (updating `poolState`) and calculates `taxAmount` (based on `balanceOf(address(this))`) *before* making external calls to `ITaxProcessor(taxProcessor).processTax(...)` and `IDividend(dividendContract).distribute(...)`. While the state changes occur before the calls, if the `taxProcessor` or `dividendContract` are untrusted or malicious, they could reenter the `FlapTaxTokenV3` contract. A reentrant call could potentially manipulate the contract's internal token balance (`balanceOf(address(this))`) before `processTax` or `distribute` are executed, leading to incorrect tax processing or unexpected behavior.
IssueThe `_liquidateTax` function performs state changes (updating `poolState`) and calculates `taxAmount` (based on `balanceOf(address(this))`) *before* making external calls to `ITaxProcessor(taxProcessor).processTax(...)` and `IDividend(dividendContract).distribute(...)`. While the state changes occur before the calls, if the `taxProcessor` or `dividendContract` are untrusted or malicious, they could reenter the `FlapTaxTokenV3` contract. A reentrant call could potentially manipulate the contract's internal token balance (`balanceOf(address(this))`) before `processTax` or `distribute` are executed, leading to incorrect tax processing or unexpected behavior.
FixApply the Checks-Effects-Interactions pattern strictly. Ensure all state changes related to `taxAmount` and `poolState` are finalized *before* any external calls are made. Consider using a reentrancy guard if external calls cannot be moved after all state updates.
StatusUnresolved
Medium

Owner Centralization and Control over Pool States

M-01The `OwnableUpgradeable` pattern grants the contract owner significant control over critical protocol parameters and state transitions. The owner can initiate (`startMigration`) and finalize (`finalizeMigration`) changes to the `PoolState`, which directly impacts the token's tax mechanisms and transfer restrictions. While this level of control might be intended for initial setup and migration, it introduces a centralization risk where a compromised owner key could manipulate the token's core functionality.
IssueThe `OwnableUpgradeable` pattern grants the contract owner significant control over critical protocol parameters and state transitions. The owner can initiate (`startMigration`) and finalize (`finalizeMigration`) changes to the `PoolState`, which directly impacts the token's tax mechanisms and transfer restrictions. While this level of control might be intended for initial setup and migration, it introduces a centralization risk where a compromised owner key could manipulate the token's core functionality.
FixConsider implementing a multi-signature wallet for ownership to reduce the risk of a single point of failure. For critical state transitions, consider adding a timelock or a governance mechanism to allow community oversight and reaction time.
StatusUnresolved
Low

Potential `uint48` Truncation for `antiFarmerExpirationTime`

L-01The `antiFarmerExpirationTime` is stored as a `uint48`. It is calculated as `block.timestamp + antiFarmerDuration`. While current `block.timestamp` values and typical `antiFarmerDuration` values fit within `uint48`, if `antiFarmerDuration` is set to an extremely large value (e.g., many decades or centuries in seconds), the sum `block.timestamp + antiFarmerDuration` could exceed the maximum value of `uint48` (`2^48 - 1`). This would result in silent truncation, leading to an incorrect and potentially much earlier `antiFarmerExpirationTime` than intended.
IssueThe `antiFarmerExpirationTime` is stored as a `uint48`. It is calculated as `block.timestamp + antiFarmerDuration`. While current `block.timestamp` values and typical `antiFarmerDuration` values fit within `uint48`, if `antiFarmerDuration` is set to an extremely large value (e.g., many decades or centuries in seconds), the sum `block.timestamp + antiFarmerDuration` could exceed the maximum value of `uint48` (`2^48 - 1`). This would result in silent truncation, leading to an incorrect and potentially much earlier `antiFarmerExpirationTime` than intended.
FixEnsure that `antiFarmerDuration` is constrained to values that, when added to `block.timestamp`, will not exceed `type(uint48).max`. Add a `require` check during initialization or any setter function for `antiFarmerDuration` to validate this. Alternatively, consider using `uint64` for `antiFarmerExpirationTime` if a longer duration is genuinely needed.
StatusUnresolved
Info

Truncated Code in `_liquidateTax` Function

I-01The provided source code for the `_liquidateTax` function is truncated at the end of a critical conditional statement: `taxAmount >= currentPoolState.liqu... (truncated)`. This prevents a full and accurate assessment of the exact conditions under which tax processing and dividend distribution are triggered.
IssueThe provided source code for the `_liquidateTax` function is truncated at the end of a critical conditional statement: `taxAmount >= currentPoolState.liqu... (truncated)`. This prevents a full and accurate assessment of the exact conditions under which tax processing and dividend distribution are triggered.
FixProvide the complete and untruncated source code for a comprehensive audit.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

7.1 Architecture and 7.2 Code Security are generally well-structured, utilizing OpenZeppelin's upgradeable contracts and a gas-efficient packed struct for `PoolState`. Immutable variables are correctly handled in the constructor. However, critical logic flaws were found in the `taxExpirationTime` management, leading to potential premature state transitions. Significant risks were identified in 7.6 External Interactions, specifically denial of service and reentrancy vulnerabilities stemming from external calls within the `_liquidateTax` function, which is part of the core transfer logic.

GovernanceMedium4/10

7.5 Governance relies on an `OwnableUpgradeable` pattern, granting the owner significant control over critical state transitions like `startMigration` and `finalizeMigration`. This introduces centralization risk, although `taxProcessor` and `dividendContract` addresses appear to be immutable post-initialization. 7.4 Economic aspects are impacted by the owner's ability to control tax enforcement states and the initial distribution of `maxSupply` to the deployer, which is a common but centralized pattern.

UpgradesLow8/10

7.7 Upgrades are handled using OpenZeppelin's `Initializable` pattern, with `_disableInitializers()` correctly called in the constructor and `initializer` modifier used for `initialize`. The use of immutable variables set in the constructor (`MIN_LIQ_THRESHOLD`, `START_LIQ_THRESHOLD`) is appropriate for upgradeable contracts. Storage layout appears compatible with OpenZeppelin's upgradeability guidelines, reducing the risk of storage collisions in future upgrades.

Security Checklist

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

Holder Composition

37.2% in top 10
28.1% in wallets9.2% in contracts
Effective Concentration31.7%

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

$53.1K across 2 pairs

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
0x0d48…a971

What Raised This Score

6 factors
  • Top-10 concentration > 30% (37.2% total → 31.7% effective; 28.1% in EOAs, 9.2% in contracts — moderate)
  • Token age < 24h (brand new — bot activity, unproven)
  • 1 Critical finding(s) from audit
  • 2 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
ZestMedium RiskMetaSoilVerseProtocol (MSVP)Medium RiskSOON Token (SOON)Medium RiskBitcatMedium RiskBaby Doge Coin (BABYDOGE)Medium RiskMindNetwork FHE Token (FHE)Medium Risk

Would You Like a More Detailed Audit of Binancians?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit