Is HOMER CZ (HOMER) Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 High1 Med1 Low2 Info

Critical

Missing Critical Function Implementation (`_processTax`)

C-01The 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.

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

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

StatusUnresolved

High

Potential Reentrancy in `_liquidateTax`

H-01The `_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.

IssueThe `_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.

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

StatusUnresolved

Medium

Centralized Control Over Pool State Transitions

M-01The `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.

IssueThe `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.

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

StatusUnresolved

Low

Reliance on `block.timestamp` for Expiration Times

L-01The `_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.

IssueThe `_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.

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

StatusUnresolved

Info

Hardcoded `maxSupply` and Initial Minting

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

IssueThe `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.

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

StatusUnresolved

Info

Complex State Machine Logic

I-02The 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.

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

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

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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

GovernanceLow8/10

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

UpgradesMedium4/10

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.

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

29.0% in top 10

16.3% in wallets12.7% in contracts

Effective Concentration21.4%

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

$60.8K across 2 pairs

Pancakeswap v2WBNBanalysed$60.8K Uniswap v2USDT$1

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

0x510d…638d

What Raised This Score

8 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

Is HOMER CZ Safe?

Security Findings

Missing Critical Function Implementation (`_processTax`)

Potential Reentrancy in `_liquidateTax`

Centralized Control Over Pool State Transitions

Reliance on `block.timestamp` for Expiration Times

Hardcoded `maxSupply` and Initial Minting

Complex State Machine Logic

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of HOMER CZ?