Quantum Audit Logo
Launch App

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

Is HOMER CZ Safe?

HOMERBNB 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 record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance8/10Upgrades4/10Checks passed5 of 7Findings1 Critical · 1 High · 1 Medium · 1 Low · 2 Info6
SummaryAI Copilot

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

Read the full analysis
What raised the score
  • Proxy contract
  • Non-standard proxy storage
  • Top-10 concentration > 20%
  • Token age < 30 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)
  • Top-10 concentration > 20% (29.0% total → 21.4% effective; 16.3% in EOAs, 12.7% in contracts — mild)
  • Token age < 30 days (still settling)
  • 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

Security Checklist

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

Holders

as of audit · Sep 4, 2026
12.7%Contracts16.3%Wallets71.0%Everyone else
12.7%16.3%71.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
29.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking12.7%
  • Walletsanonymous holders, free to sell16.3%
  • Everyone elsethe rest of the supply71.0%
Effective concentrationwhat the score reads21.4%
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$60.8K across 2 pairs

The risk score reads depth across every pair.

LP tokensLocked

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

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

Security Findings

1 Critical1 High1 Medium1 Low2 Info
Critical

Missing Critical Function Implementation (_processTax)

The provided source code is truncated, specifically missing the implementation of the _processTax(uint256 taxAmount) function. This function is called within _liquidateTax, which is invoked on every token transfer. _processTax is central to the contract's tax collection and distribution mechanism. Without its full code, a comprehensive security assessment of the core economic logic, external interactions, and potential vulnerabilities (e.g., reentrancy, incorrect accounting) is impossible.C-01

Issue

The provided source code is truncated, specifically missing the implementation of the _processTax(uint256 taxAmount) function. This function is called within _liquidateTax, which is invoked on every token transfer. _processTax is central to the contract's tax collection and distribution mechanism. Without its full code, a comprehensive security assessment of the core economic logic, external interactions, and potential vulnerabilities (e.g., reentrancy, incorrect accounting) is impossible.

Fix

Provide the complete and verified source code for the _processTax function. A full re-audit of the contract, focusing on this critical component, is required once the code is available.

Status

Unresolved

High

Potential Reentrancy in _liquidateTax

The _liquidateTax function modifies the notLiquidating state variable (currentPoolState.notLiquidating = false; then true;) around a call to _processTax. If _processTax (whose implementation is missing) makes an external call to an untrusted contract (e.g., taxProcessor, dividendContract, v2Router), and that external call re-enters _liquidateTax or _transfer, it could lead to unexpected behavior or asset manipulation. The notLiquidating flag is intended to prevent re-entry into the liquidation logic, but its effectiveness depends entirely on the behavior of the missing _processTax function.H-01

Issue

The _liquidateTax function modifies the notLiquidating state variable (currentPoolState.notLiquidating = false; then true;) around a call to _processTax. If _processTax (whose implementation is missing) makes an external call to an untrusted contract (e.g., taxProcessor, dividendContract, v2Router), and that external call re-enters _liquidateTax or _transfer, it could lead to unexpected behavior or asset manipulation. The notLiquidating flag is intended to prevent re-entry into the liquidation logic, but its effectiveness depends entirely on the behavior of the missing _processTax function.

Fix

Once the _processTax implementation is available, rigorously audit it for external calls. If external calls are present, ensure they follow the Checks-Effects-Interactions pattern. Consider using a reentrancy guard or OpenZeppelin's ReentrancyGuard if multiple external calls are made or if the logic is complex.

Status

Unresolved

Medium

Centralized Control Over Pool State Transitions

The startMigration and finalizeMigration functions, which control critical transitions in the poolState (e.g., from BondingCurve to Migrating, and Migrating to TaxEnforcedAntiFarmer), are protected by the onlyOwner modifier. This grants a single address (the owner) unilateral control over these significant operational changes, posing a centralization risk. A malicious or compromised owner could manipulate the pool state without community consensus.M-01

Issue

The startMigration and finalizeMigration functions, which control critical transitions in the poolState (e.g., from BondingCurve to Migrating, and Migrating to TaxEnforcedAntiFarmer), are protected by the onlyOwner modifier. This grants a single address (the owner) unilateral control over these significant operational changes, posing a centralization risk. A malicious or compromised owner could manipulate the pool state without community consensus.

Fix

Consider implementing a multi-signature wallet for ownership or integrating a timelock mechanism for these critical state-changing functions. This would introduce a delay before changes take effect, allowing for community review and mitigating risks associated with a single point of failure.

Status

Unresolved

Low

Reliance on block.timestamp for Expiration Times

The _liquidateTax function uses block.timestamp to determine if taxExpirationTime or antiFarmerExpirationTime have passed, triggering state changes. While common, block.timestamp can be manipulated by miners within a certain range (up to 900 seconds on Ethereum, similar on BSC). This could allow a miner to slightly front-run or delay a state transition, potentially affecting the timing of tax enforcement or anti-farmer periods.L-01

Issue

The _liquidateTax function uses block.timestamp to determine if taxExpirationTime or antiFarmerExpirationTime have passed, triggering state changes. While common, block.timestamp can be manipulated by miners within a certain range (up to 900 seconds on Ethereum, similar on BSC). This could allow a miner to slightly front-run or delay a state transition, potentially affecting the timing of tax enforcement or anti-farmer periods.

Fix

For critical time-sensitive operations, consider using block.number and calculating time based on average block times, or accept the inherent minor manipulation risk of block.timestamp. Given the context of tax periods, this risk is generally low but worth noting.

Status

Unresolved

Info

Hardcoded maxSupply and Initial Minting

The maxSupply is declared as a public constant with a value of 1e9 ether. During initialization, the entire maxSupply is minted to msg.sender. This design choice means the total supply is fixed and fully controlled by the deployer at the outset. While not a vulnerability, it represents a high degree of centralization in initial token distribution.I-01

Issue

The maxSupply is declared as a public constant with a value of 1e9 ether. During initialization, the entire maxSupply is minted to msg.sender. This design choice means the total supply is fixed and fully controlled by the deployer at the outset. While not a vulnerability, it represents a high degree of centralization in initial token distribution.

Fix

Document this design choice clearly for users and investors. If future decentralization of supply is desired, consider mechanisms for controlled release or distribution beyond the initial deployer's address.

Status

Unresolved

Info

Complex State Machine Logic

The contract implements a multi-state system (PoolState.BondingCurve, Migrating, TaxEnforcedAntiFarmer, TaxEnforced, TaxFree) with intricate transition conditions and corresponding logic in _transfer and _liquidateTax. The PackedPoolState struct also combines multiple variables into a single storage slot. While this can be efficient, the complexity of the state machine increases the surface area for potential logical errors or unexpected interactions between states, even if no specific bug was identified in the available code.I-02

Issue

The contract implements a multi-state system (PoolState.BondingCurve, Migrating, TaxEnforcedAntiFarmer, TaxEnforced, TaxFree) with intricate transition conditions and corresponding logic in _transfer and _liquidateTax. The PackedPoolState struct also combines multiple variables into a single storage slot. While this can be efficient, the complexity of the state machine increases the surface area for potential logical errors or unexpected interactions between states, even if no specific bug was identified in the available code.

Fix

Ensure comprehensive unit and integration tests cover all possible state transitions and edge cases. Consider adding Natspec comments to clearly explain the purpose and conditions for each state and transition.

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 dynamic tax mechanisms and a multi-state pool management system. It utilizes OpenZeppelin's upgradeable contracts for security and maintainability. A critical limitation of this audit is the truncation of the _processTax function, which is central to the token's economic logic and tax liquidation. Without its full implementation, a comprehensive security assessment, particularly regarding reentrancy and external interactions, is not possible. The current analysis identifies a critical missing component, potential reentrancy risk, and centralization concerns.

Technical6/10Medium risk

The contract leverages OpenZeppelin's upgradeable ERC20 and access control patterns, enhancing code security and maintainability (7.2 Code Security). It correctly uses SafeERC20 for external token interactions. However, the provided code is incomplete, specifically missing the implementation of the _processTax function, which is critical for the token's core tax liquidation logic (7.1 Architecture). This omission introduces a significant unknown risk, including potential reentrancy vulnerabilities if _processTax performs external calls (7.2 Code Security).

Governance8/10Low risk

The contract's economic model relies on dynamic tax rates and liquidation thresholds, managed through a multi-state system. The onlyOwner modifier on startMigration and finalizeMigration grants significant control over critical state transitions to a single address (7.3 Access Control). The maxSupply is hardcoded and minted entirely to the deployer, centralizing initial token distribution. The _liquidateTax function's logic, which processes accumulated taxes, is incomplete, preventing a full economic risk assessment (7.4 Economic).

Upgrades4/10Medium risk

The contract is designed as an upgradeable proxy implementation, using OpenZeppelin's Initializable pattern. The _disableInitializers() call in the constructor and the initializer modifier on the initialize function correctly prevent re-initialization (7.7 Upgrades). This setup adheres to standard upgradeability best practices, allowing for future enhancements or bug fixes via proxy upgrades.

Final RecommendationWhat to do about this score

It is imperative to provide the complete source code for the _processTax function to enable a thorough security audit, especially concerning reentrancy and external call safety.

Once the full code is available, a re-audit should be conducted. Consider implementing a timelock for critical owner-controlled functions like startMigration and finalizeMigration to introduce a delay for sensitive operations, enhancing security and transparency. Ensure all external interactions within _processTax are protected against reentrancy.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age7d
Contract0x4f06…7777
Deployer0x510d…638d
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Badge for your website
HOMER CZ 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, 202640Medium
  2. Sep 2, 202613Low

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

Frequently Asked Questions

What is the HOMER contract address?

The HOMER CZ (HOMER) contract on BNB Chain is 0x4f06dba806d66e1caeb37516c0f7a28728067777. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is HOMER CZ a scam?

Quantum Audit's risk score for HOMER CZ is 40/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Locked; Upgradeability: Upgradeable; Honeypot: None found; Buy / sell tax: 0% / 1%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is HOMER liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $60.8K.

Who holds HOMER?

As of Sep 4, 2026, the 10 largest holders own 29.0% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
APRO oracle TokenAT · BNB Chain40Mediumutility tokenUTILITY · BNB Chain40MediumArk Of PandaAOP · BNB Chain40MediumBUDDY - First Crypto DogBUDDY · BNB Chain40MediumBaby Doge CoinBABYDOGE · BNB Chain41MediumBitway TokenBTW · BNB Chain39Medium

Would You Like a More Detailed Audit of HOMER CZ?

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

Get Detailed Audit Is this your token? Publish your own audit on this page