Is Randy Safe? Smart Contract Security Analysis

Security Findings

2 High2 Med1 Info

High

Reentrancy Vulnerability in `_liquidateTax`

H-01The `_liquidateTax` function performs an external call to `_processTax(taxAmount)` on the `taxProcessor` contract. Before this call, `currentPoolState.notLiquidating` is set to `false`, and after the call, it is reset to `true`. If the `taxProcessor` contract is malicious or compromised, it could re-enter `_liquidateTax` or other functions in `FlapTaxTokenV3` before `notLiquidating` is reset. This could lead to unexpected state changes, double-spending of collected taxes, or other malicious actions. This is a classic reentrancy pattern (7.2 Code Security, 7.6 External).

IssueThe `_liquidateTax` function performs an external call to `_processTax(taxAmount)` on the `taxProcessor` contract. Before this call, `currentPoolState.notLiquidating` is set to `false`, and after the call, it is reset to `true`. If the `taxProcessor` contract is malicious or compromised, it could re-enter `_liquidateTax` or other functions in `FlapTaxTokenV3` before `notLiquidating` is reset. This could lead to unexpected state changes, double-spending of collected taxes, or other malicious actions. This is a classic reentrancy pattern (7.2 Code Security, 7.6 External).

FixImplement a reentrancy guard (e.g., OpenZeppelin's `ReentrancyGuard`) on the `_liquidateTax` function or ensure that all state changes related to `notLiquidating` are completed *before* any external calls are made. Alternatively, consider a 'checks-effects-interactions' pattern.

StatusUnresolved

High

Incorrect `taxExpirationTime` Calculation in `finalizeMigration`

H-02In the `finalizeMigration` function, the `taxExpirationTime` is updated with `currentPoolState.taxExpirationTime + block.timestamp`. The `currentPoolState.taxExpirationTime` is initialized with `params.taxDuration` in `initialize`. Adding `block.timestamp` to an already set duration (which is likely intended to be a future timestamp) will result in an incorrect and potentially extremely long or unintended expiration time. This logic error could lead to taxes being enforced for a much longer period than intended, impacting the token's economic model (7.4 Economic, 7.2 Code Security).

IssueIn the `finalizeMigration` function, the `taxExpirationTime` is updated with `currentPoolState.taxExpirationTime + block.timestamp`. The `currentPoolState.taxExpirationTime` is initialized with `params.taxDuration` in `initialize`. Adding `block.timestamp` to an already set duration (which is likely intended to be a future timestamp) will result in an incorrect and potentially extremely long or unintended expiration time. This logic error could lead to taxes being enforced for a much longer period than intended, impacting the token's economic model (7.4 Economic, 7.2 Code Security).

FixThe `taxExpirationTime` should be set to `block.timestamp + params.taxDuration` (or a similar calculation based on the intended duration from the current time) in `finalizeMigration`, not `currentPoolState.taxExpirationTime + block.timestamp`. Review the intended behavior for `taxExpirationTime` and correct the calculation accordingly.

StatusUnresolved

Medium

Significant Centralized Control by Owner

M-01The `owner` role has extensive control over critical contract functions, including `startMigration` and `finalizeMigration`, which dictate the transition between different `PoolState`s. The owner also controls the `taxProcessor` and `dividendContract` addresses through initialization parameters. While this may be intended for initial setup and operational flexibility, it introduces a single point of failure and trust. A compromised owner key could lead to unauthorized state changes or manipulation of the token's economic model (7.3 Access Control, 7.5 Governance).

IssueThe `owner` role has extensive control over critical contract functions, including `startMigration` and `finalizeMigration`, which dictate the transition between different `PoolState`s. The owner also controls the `taxProcessor` and `dividendContract` addresses through initialization parameters. While this may be intended for initial setup and operational flexibility, it introduces a single point of failure and trust. A compromised owner key could lead to unauthorized state changes or manipulation of the token's economic model (7.3 Access Control, 7.5 Governance).

FixConsider implementing a multi-signature wallet for the `owner` role to reduce the risk associated with a single point of compromise. As the protocol matures, explore decentralizing control through a governance mechanism or time-locked operations for critical functions.

StatusUnresolved

Medium

Potential Integer Overflow in `uint48`/`uint64` Expiration Times

M-02The `taxExpirationTime` (uint64) and `antiFarmerExpirationTime` (uint48) variables store timestamps. Calculations like `block.timestamp + antiFarmerDuration` (where `antiFarmerDuration` is `uint256`) could potentially result in values exceeding the maximum capacity of `uint48` or `uint64` if the durations are extremely long. While `block.timestamp` itself is typically within `uint48` range for many years, adding a very large `antiFarmerDuration` could cause an overflow, leading to incorrect expiration times (7.2 Code Security, 7.4 Economic).

IssueThe `taxExpirationTime` (uint64) and `antiFarmerExpirationTime` (uint48) variables store timestamps. Calculations like `block.timestamp + antiFarmerDuration` (where `antiFarmerDuration` is `uint256`) could potentially result in values exceeding the maximum capacity of `uint48` or `uint64` if the durations are extremely long. While `block.timestamp` itself is typically within `uint48` range for many years, adding a very large `antiFarmerDuration` could cause an overflow, leading to incorrect expiration times (7.2 Code Security, 7.4 Economic).

FixEnsure that `antiFarmerDuration` and `taxDuration` parameters are constrained to values that, when added to `block.timestamp`, will not exceed the maximum values of `uint48` or `uint64`. Alternatively, consider using `uint256` for all timestamp-related variables if extremely long durations (beyond ~136 years for `uint48` or ~584 billion years for `uint64`) are a design requirement, or implement explicit overflow checks.

StatusUnresolved

Info

High Complexity in `_liquidateTax` and Pool State Machine

I-01The `_liquidateTax` function is invoked on every transfer to `mainPool` and is responsible for multiple state transitions, tax processing, and liquidation logic. The overall `PoolState` machine, with its five distinct states and various transition conditions, adds significant complexity to the contract. Complex logic increases the surface area for potential bugs and makes auditing and reasoning about the contract's behavior more challenging (7.1 Architecture, 7.2 Code Security).

IssueThe `_liquidateTax` function is invoked on every transfer to `mainPool` and is responsible for multiple state transitions, tax processing, and liquidation logic. The overall `PoolState` machine, with its five distinct states and various transition conditions, adds significant complexity to the contract. Complex logic increases the surface area for potential bugs and makes auditing and reasoning about the contract's behavior more challenging (7.1 Architecture, 7.2 Code Security).

FixConsider refactoring `_liquidateTax` into smaller, more focused functions to improve readability and maintainability. Thoroughly document the state machine transitions and their conditions to ensure clarity and prevent unintended behavior. Implement comprehensive unit tests for all state transitions and tax calculation scenarios.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract utilizes OpenZeppelin's upgradeable standards for ERC20 and access control, demonstrating a commitment to established patterns (7.1 Architecture). The tax calculation logic is generally sound, and packed storage is used for efficiency (7.2 Code Security). However, a significant reentrancy vulnerability exists in the `_liquidateTax` function due to an external call to `_processTax` without a reentrancy guard, potentially allowing malicious re-entry before state updates are complete. Additionally, the calculation of `taxExpirationTime` in `finalizeMigration` is incorrect, leading to an unintended and potentially exploitable duration (7.2 Code Security).

GovernanceMedium4/10

The contract implements a multi-state system for tax enforcement and migration, with `onlyOwner` functions controlling key state transitions (`startMigration`, `finalizeMigration`) (7.5 Governance). This provides centralized control over the token's operational phases. The economic model involves dynamic buy/sell taxes and a liquidation mechanism for collected taxes (7.4 Economic). A potential issue exists where `uint48`/`uint64` expiration times could overflow if `antiFarmerDuration` or `taxExpirationTime` are set to extremely large values, although this is less likely with typical durations (7.4 Economic).

UpgradesMedium4/10

The contract is designed as an upgradeable proxy using OpenZeppelin's `Initializable` pattern (7.7 Upgrades). The constructor correctly calls `_disableInitializers()`, and the `initialize` function sets up the contract state appropriately. This adherence to established upgradeability patterns minimizes common upgrade-related risks.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

Holder Composition

40.2% in top 10

16.6% in wallets23.6% in contracts

Effective Concentration26.0%

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

$48.6K across 2 pairs

Pancakeswap v2NVDABanalysed$48.6K Pancakeswap v3USDT$14

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 Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

2 addresses

Deployer

0x7eaf…4837

Unlocked LP Held By

0xc502…1e28

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

What Raised This Score

10 factors

Proxy contract (upgradeable — admin can replace logic)
Non-standard proxy storage (Etherscan-confirmed)
Top-10 concentration > 20% (40.2% total → 26.0% effective; 16.6% in EOAs, 23.6% in contracts — mild)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Liquidity < $50k ($48,629 across 2 pairs — thin market)
LP top1 unlocked holder = 100.0% (independent LP — depth risk)
LP top3 unlocked holders = 100.0% (independent LP — depth risk)
Token age < 30 days (still settling)
2 High finding(s) from audit
2 Medium 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 Randy Safe?

Security Findings

Reentrancy Vulnerability in `_liquidateTax`

Incorrect `taxExpirationTime` Calculation in `finalizeMigration`

Significant Centralized Control by Owner

Potential Integer Overflow in `uint48`/`uint64` Expiration Times

High Complexity in `_liquidateTax` and Pool State Machine

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 Randy?