Quantum Audit Logo

Is Binance Brokers a Scam?

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

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

Binance Brokers BBROKERS
0xfe59…7777
BNB Chain Not verifiedLast checked 2d ago 1 audit on record New Launch · 1d old
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a complex tax and liquidation mechanism. The audit identified a critical information gap due to truncated code for the `_processTax` function, which prevents a full security assessment. Additionally, the contract exhibits high centralization risk and relies on `block.timestamp` for critical state transitions. While OpenZeppelin's upgradeable pattern is correctly implemented, the unverified `_processTax` function poses a significant unknown risk.

1 Critical1 High1 Medium1 Low
! Early-stage analysis. This token has limited on-chain history (1d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$443.2K
Liquidity
$1.90M
Price
$0.003534
Token Age
1d
Top 10 Holders
84.2%

Security Findings

1 Crit1 High1 Med1 Low
Critical

Incomplete Code Prevents Full Security Assessment of `_processTax` Function

C-01The provided source code for `FlapTaxTokenV3.sol` is truncated, specifically omitting the implementation of the `_processTax` function. This function is called within `_liquidateTax`, which executes on every token transfer. Without the full implementation, it is impossible to assess critical security aspects such as potential reentrancy vulnerabilities, external call interactions (e.g., with `v2Router`, `taxProcessor`, `dividendContract`), gas consumption, and overall correctness. While a `notLiquidating` flag is used as a reentrancy guard around the `_processTax` call, the full impact of `_processTax` on the contract's state and interactions with other components cannot be determined. (7.1…
IssueThe provided source code for `FlapTaxTokenV3.sol` is truncated, specifically omitting the implementation of the `_processTax` function. This function is called within `_liquidateTax`, which executes on every token transfer. Without the full implementation, it is impossible to assess critical security aspects such as potential reentrancy vulnerabilities, external call interactions (e.g., with `v2Router`, `taxProcessor`, `dividendContract`), gas consumption, and overall correctness. While a `notLiquidating` flag is used as a reentrancy guard around the `_processTax` call, the full impact of `_processTax` on the contract's state and interactions with other components cannot be determined. (7.1…
FixProvide the complete and untruncated source code for the `_processTax` function and any directly related external interfaces or contracts. A full audit of this critical component is essential to ensure the security and integrity of the token's tax and liquidation mechanisms.
StatusUnresolved
High

High Centralization Risk and Owner Privileges

H-01The `initialize` function mints the entire `maxSupply` (1 billion tokens) to `msg.sender` (the deployer/owner). The `owner` also controls critical state transitions via `startMigration` and `finalizeMigration`, which can change the `PoolState` and activate/deactivate tax mechanisms. This grants significant control to a single entity, posing a centralization risk. (7.3 Access Control, 7.4 Economic)
IssueThe `initialize` function mints the entire `maxSupply` (1 billion tokens) to `msg.sender` (the deployer/owner). The `owner` also controls critical state transitions via `startMigration` and `finalizeMigration`, which can change the `PoolState` and activate/deactivate tax mechanisms. This grants significant control to a single entity, posing a centralization risk. (7.3 Access Control, 7.4 Economic)
FixConsider implementing a multi-signature wallet for ownership or critical operations to distribute control. Clearly document the owner's capabilities and potential impact to users and the community.
StatusUnresolved
Medium

Reliance on `block.timestamp` for Critical State Transitions

M-01The `_liquidateTax` function uses `block.timestamp` to determine `taxExpirationTime` and `antiFarmerExpirationTime`, which trigger changes in the `PoolState` (e.g., from `TaxEnforcedAntiFarmer` to `TaxEnforced` or `TaxFree`). While `block.timestamp` is generally reliable, miners can manipulate it within a small window (up to 900 seconds on Ethereum, similar on BSC). This could potentially allow a miner to prematurely or belatedly trigger a state change, impacting tax collection or anti-farmer mechanisms. (7.2 Code Security, 7.4 Economic)
IssueThe `_liquidateTax` function uses `block.timestamp` to determine `taxExpirationTime` and `antiFarmerExpirationTime`, which trigger changes in the `PoolState` (e.g., from `TaxEnforcedAntiFarmer` to `TaxEnforced` or `TaxFree`). While `block.timestamp` is generally reliable, miners can manipulate it within a small window (up to 900 seconds on Ethereum, similar on BSC). This could potentially allow a miner to prematurely or belatedly trigger a state change, impacting tax collection or anti-farmer mechanisms. (7.2 Code Security, 7.4 Economic)
FixFor highly time-sensitive or economically critical state transitions, consider using a more robust time oracle (e.g., Chainlink Keepers or a custom time-weighted average oracle) if precise timing is paramount and miner manipulation is a significant concern. Evaluate the impact of a small timestamp deviation on the protocol's economics.
StatusUnresolved
Low

Gas Inefficiency from `_liquidateTax` on Every Transfer

L-01The `_liquidateTax` function is called at the beginning of every `_transfer` operation. This function performs several state reads, comparisons, and potentially state writes, even if no liquidation or state change is required. If `_processTax` involves complex operations or external calls (which cannot be fully assessed due to truncated code), this could lead to higher gas costs for every token transfer, impacting user experience and network congestion. (7.2 Code Security, 7.8 Operations)
IssueThe `_liquidateTax` function is called at the beginning of every `_transfer` operation. This function performs several state reads, comparisons, and potentially state writes, even if no liquidation or state change is required. If `_processTax` involves complex operations or external calls (which cannot be fully assessed due to truncated code), this could lead to higher gas costs for every token transfer, impacting user experience and network congestion. (7.2 Code Security, 7.8 Operations)
FixEvaluate the gas cost implications of calling `_liquidateTax` on every transfer. Consider optimizing the logic to only perform checks or operations when strictly necessary, or explore alternative mechanisms for tax liquidation that are not tied to every single transfer.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract leverages OpenZeppelin's upgradeable ERC20 standards, ensuring a robust foundation for token functionality and future enhancements (7.1 Architecture). It implements a complex state machine for tax enforcement and liquidation, utilizing a `notLiquidating` flag as a reentrancy guard for the `_processTax` function (7.2 Code Security). However, the truncation of the `_processTax` function prevents a full security assessment, posing a critical unknown risk (C-01). Additionally, the reliance on `block.timestamp` for critical state transitions introduces a minor risk of miner manipulation (M-01).

GovernanceHigh2/10

The contract exhibits a high degree of centralization, with the owner receiving the entire `maxSupply` upon initialization and retaining exclusive control over critical state transitions like `startMigration` and `finalizeMigration` (7.3 Access Control, 7.4 Economic). This concentration of power introduces significant trust assumptions. The system also relies on external contracts such as `taxProcessor`, `dividendContract`, and `v2Router`, whose security and behavior are critical to the overall protocol's integrity (7.6 External).

UpgradesHigh3/10

The contract correctly implements the OpenZeppelin upgradeable pattern, including `Initializable` and `_disableInitializers()` in the constructor, along with an `initializer` function (7.7 Upgrades). This design allows for future upgrades to fix bugs or add features without deploying a new contract, provided the upgrade proxy is managed securely.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source

Holder Composition

84.2% in top 10
55.3% in wallets28.9% in contracts
Effective Concentration66.9%

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

$1.90M

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 Holder55.6%
Top-3 Unlocked100.0%

Key Addresses

3 addresses
Deployer
0x415a…6004
Unlocked LP Held By
0x14e5…be4a0x6921…11af

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

What Raised This Score

11 factors
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Top-10 concentration > 50% (84.2% total → 66.9% effective; 55.3% in EOAs, 28.9% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 55.6% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 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
Based Token (BASED)Critical RiskGRVTCritical RiskFalcon Finance (FF)Critical RiskKGENCritical RiskSpaceX (SPCXB)Critical RiskLorenzo Governance Token (BANK)Critical Risk

Would You Like a More Detailed Audit of Binance Brokers?

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

Get Detailed Audit