Quantum Audit Logo

Is Break And Reclaim Safe?

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

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

Break And Reclaim BAN
0x848e…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 8d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with complex tax mechanisms and state-based transfer logic. It utilizes OpenZeppelin's upgradeable contracts for core functionality and ownership. Key findings include critical immutability of external dependencies, potential reentrancy concerns in the transfer function, and the limitation of a truncated source code for a full audit of the liquidation logic. The contract's design introduces significant operational and security risks due to fixed external addresses and the lack of a reentrancy guard on the main transfer function.

1 Critical1 High1 Medium1 Low2 Informational
Volume 24h
$800.6K
Liquidity
$711.9K
Price
$0.02694
Token Age
2mo
Top 10 Holders
19.8%

Security Findings

1 Crit1 High1 Med1 Low2 Info
Critical

Immutability of Critical External Dependencies

C-01The contract initializes critical external dependencies such as `taxProcessor`, `dividendContract`, `v2Router`, `quoteToken`, and `mainPool` only during the `initialize` function. There are no `onlyOwner` setter functions to update these addresses post-deployment. This design choice makes the contract highly inflexible. If any of these external contracts are compromised, deprecated, or require an update (e.g., due to a migration or vulnerability), the `FlapTaxTokenV3` contract cannot adapt without a full implementation upgrade. This introduces significant operational and security risks, as the token's core functionality relies on these fixed addresses.
IssueThe contract initializes critical external dependencies such as `taxProcessor`, `dividendContract`, `v2Router`, `quoteToken`, and `mainPool` only during the `initialize` function. There are no `onlyOwner` setter functions to update these addresses post-deployment. This design choice makes the contract highly inflexible. If any of these external contracts are compromised, deprecated, or require an update (e.g., due to a migration or vulnerability), the `FlapTaxTokenV3` contract cannot adapt without a full implementation upgrade. This introduces significant operational and security risks, as the token's core functionality relies on these fixed addresses.
FixImplement `onlyOwner` setter functions for all critical external contract addresses (`taxProcessor`, `dividendContract`, `v2Router`, `quoteToken`, `mainPool`). This will allow the contract owner to update these dependencies as needed, enhancing operational flexibility and enabling a rapid response to potential security incidents or ecosystem changes.
StatusUnresolved
High

Potential Reentrancy in `_transfer` via External Calls

H-01The `_transfer` function calls `_liquidateTax` which, in turn, makes external calls to `ITaxProcessor.processTax` and `IDividend.distribute`. While `_liquidateTax` uses a `notLiquidating` flag to prevent reentrancy *within* the liquidation logic, the `_transfer` function itself is not protected by a reentrancy guard. If `ITaxProcessor` or `IDividend` reenter `_transfer` (e.g., by calling `transfer` on this token), the `_transfer` logic could be re-executed with potentially inconsistent state, leading to incorrect tax calculations, bypassing of tax, or other unintended token transfer behaviors.
IssueThe `_transfer` function calls `_liquidateTax` which, in turn, makes external calls to `ITaxProcessor.processTax` and `IDividend.distribute`. While `_liquidateTax` uses a `notLiquidating` flag to prevent reentrancy *within* the liquidation logic, the `_transfer` function itself is not protected by a reentrancy guard. If `ITaxProcessor` or `IDividend` reenter `_transfer` (e.g., by calling `transfer` on this token), the `_transfer` logic could be re-executed with potentially inconsistent state, leading to incorrect tax calculations, bypassing of tax, or other unintended token transfer behaviors.
FixApply OpenZeppelin's `nonReentrant` modifier to the `_transfer` function. This will prevent reentrant calls from external contracts, ensuring that the function completes its execution and updates all state variables before any external calls can re-enter it.
StatusUnresolved
Medium

Truncated `_liquidateTax` Function Source Code

M-01The provided source code for the `_liquidateTax` function is truncated, specifically after the condition `taxAmount >= currentPoolState.liqu`. This prevents a full security analysis of the critical tax processing and dividend distribution logic. Without the complete code, it is impossible to verify the exact parameters passed to external calls, subsequent state updates, error handling, and overall robustness of this crucial function.
IssueThe provided source code for the `_liquidateTax` function is truncated, specifically after the condition `taxAmount >= currentPoolState.liqu`. This prevents a full security analysis of the critical tax processing and dividend distribution logic. Without the complete code, it is impossible to verify the exact parameters passed to external calls, subsequent state updates, error handling, and overall robustness of this crucial function.
FixProvide the complete and verified source code for the `_liquidateTax` function to enable a comprehensive security audit. This is essential for ensuring the integrity and security of the tax and dividend distribution mechanisms.
StatusUnresolved
Low

Lack of Emergency Pause Mechanism

L-01The contract lacks an emergency pause mechanism (e.g., `PausableUpgradeable` from OpenZeppelin) to halt transfers or critical operations in case of a severe vulnerability, exploit, or unexpected behavior. For a token with complex tax and state management, a pause mechanism can be crucial for mitigating damage during an attack or unforeseen circumstances, allowing time for investigation and resolution.
IssueThe contract lacks an emergency pause mechanism (e.g., `PausableUpgradeable` from OpenZeppelin) to halt transfers or critical operations in case of a severe vulnerability, exploit, or unexpected behavior. For a token with complex tax and state management, a pause mechanism can be crucial for mitigating damage during an attack or unforeseen circumstances, allowing time for investigation and resolution.
FixConsider integrating OpenZeppelin's `PausableUpgradeable` module. This would allow the contract owner to pause and unpause critical functions (like `_transfer`) in an emergency, providing a safety net against potential exploits or operational issues.
StatusUnresolved
Info

Fixed Liquidation Thresholds

I-01The `MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` variables are declared as `immutable` and set in the constructor. This design choice fixes these critical liquidation parameters for the lifetime of the contract. While this provides predictability, it might limit future adaptability if market conditions or protocol requirements change, necessitating adjustments to these thresholds.
IssueThe `MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` variables are declared as `immutable` and set in the constructor. This design choice fixes these critical liquidation parameters for the lifetime of the contract. While this provides predictability, it might limit future adaptability if market conditions or protocol requirements change, necessitating adjustments to these thresholds.
FixThis is a design choice. If flexibility is desired in the future, consider making these parameters configurable by the owner, similar to other dynamic parameters. If immutability is intentional for protocol stability, no change is needed.
StatusUnresolved
Info

Complex Pool State Management and Transitions

I-02The contract implements a `PackedPoolState` struct and an enum (`PoolState`) to manage various operational states (e.g., `BondingCurve`, `TaxEnforcedAntiFarmer`, `TaxFree`). State transitions are controlled by `onlyOwner` functions (`startMigration`, `finalizeMigration`) and time-based conditions within `_liquidateTax`. This complex state machine, while seemingly logical, increases the surface area for potential logic errors or unexpected behavior if not thoroughly tested under all possible scenarios.
IssueThe contract implements a `PackedPoolState` struct and an enum (`PoolState`) to manage various operational states (e.g., `BondingCurve`, `TaxEnforcedAntiFarmer`, `TaxFree`). State transitions are controlled by `onlyOwner` functions (`startMigration`, `finalizeMigration`) and time-based conditions within `_liquidateTax`. This complex state machine, while seemingly logical, increases the surface area for potential logic errors or unexpected behavior if not thoroughly tested under all possible scenarios.
FixEnsure comprehensive unit and integration tests cover all possible state transitions, edge cases, and time-dependent conditions. Formal verification might also be beneficial for such complex state machines to mathematically prove correctness.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract leverages OpenZeppelin's upgradeable ERC20 and Ownable components, providing a solid foundation for token functionality (7.1 Architecture). Storage packing for `PackedPoolState` is efficient. However, the `_transfer` function, which incorporates custom tax logic and external calls, lacks a comprehensive reentrancy guard, posing a significant risk (7.2 Code Security). The provided source code for `_liquidateTax` is truncated, preventing a full analysis of critical tax processing logic (7.2 Code Security).

GovernanceLow8/10

The contract's economic model relies on dynamic tax rates and liquidation thresholds, managed through a `PackedPoolState` struct. Ownership is managed via `OwnableUpgradeable`, allowing the owner to initiate migration states (7.5 Governance). A critical flaw is the immutability of essential external dependencies like `taxProcessor`, `dividendContract`, `v2Router`, and `quoteToken` after initialization (7.4 Economic). This design choice severely limits operational flexibility and introduces a single point of failure if any of these external contracts are compromised or require updates (7.8 Operations).

UpgradesLow9/10

The contract is designed as an upgradeable implementation using OpenZeppelin's `Initializable` pattern, with `_disableInitializers()` in the constructor and an `initializer` function (7.7 Upgrades). Storage layout appears compatible with typical upgrade patterns. However, the implementation does not include `_authorizeUpgrade`, suggesting reliance on a custom or Transparent Proxy for upgrade control. This implies that the proxy's upgrade mechanism, not this implementation, dictates upgrade authorization, which was not available for review.

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

19.8% in top 10
16.9% in wallets2.9% in contracts
Effective Concentration18.1%

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

$722.5K across 5 pairs
Pancakeswap v2WBNBanalysed$711.9K98.5%Pancakeswap v2USDT$7.0K1.0%Pancakeswap v3WBNB$2.9K0.4%Pancakeswap v3USDT$7240.1%Pancakeswap v2USDC$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 Burned78.4%
LP Locked78.4%

Key Addresses

10 addresses
Deployer
0xa061…4944
Unlocked LP Held By
0x04ef…a2f50xcdc2…e3ff0x2f11…181c0x53ed…2bfa0x763d…7d2b0x41bf…dd330xd6a6…9b740x1e34…a7080xb120…b8dd

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

What Raised This Score

4 factors
  • 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
Build On BNB (BOB)Low RiskFrippyLow RiskGiggle Mascot (MAX)Low RiskOKZOO (AIOT)Low RiskBinance Cat (BNBCAT)Low RiskNianNianLow Risk

Would You Like a More Detailed Audit of Break And Reclaim?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit