Is VCAT a Scam? New Token Security Check

Security Findings

2 Crit1 High2 Med1 Low1 Info

Critical

Immutable Variables in Upgradeable Contract Constructor Remain Zero in Proxy Context

C-01The `MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` variables are declared as `immutable` and initialized in the constructor of the `FlapTaxTokenV3` implementation contract. In an upgradeable proxy pattern, the constructor of the implementation contract is never called when users interact with the proxy. Consequently, these `immutable` variables will retain their default zero values (0) in the context of the proxy, leading to incorrect or unintended behavior in any logic that relies on them. For example, `initialLiquidationThreshold` is set to `START_LIQ_THRESHOLD` in `initialize`, but if `START_LIQ_THRESHOLD` is 0, this will lead to a 0 liquidation threshold. (Coverage: 7.1 Architecture, 7.7…

IssueThe `MIN_LIQ_THRESHOLD` and `START_LIQ_THRESHOLD` variables are declared as `immutable` and initialized in the constructor of the `FlapTaxTokenV3` implementation contract. In an upgradeable proxy pattern, the constructor of the implementation contract is never called when users interact with the proxy. Consequently, these `immutable` variables will retain their default zero values (0) in the context of the proxy, leading to incorrect or unintended behavior in any logic that relies on them. For example, `initialLiquidationThreshold` is set to `START_LIQ_THRESHOLD` in `initialize`, but if `START_LIQ_THRESHOLD` is 0, this will lead to a 0 liquidation threshold. (Coverage: 7.1 Architecture, 7.7…

Fix`immutable` variables should not be used in upgradeable contracts. Instead, these values should be stored as regular state variables and initialized via the `initialize` function, or set via an `onlyOwner` function after initialization.

StatusUnresolved

Critical

Potential Integer Underflow in Tax Calculation

C-02The `_getTaxWithPoolState` function calculates `tax = (amount * currentPoolState.buyTaxRate) / 10000` or `(amount * currentPoolState.sellTaxRate) / 10000`. The `buyTaxRate` and `sellTaxRate` are `uint16`. If these rates are set to a value greater than `10000` (e.g., 15000 for 150% tax), the calculated `tax` could exceed the `amount` being transferred. Subsequently, in `_taxedTransfer`, the operation `amount - tax` would result in an integer underflow. While Solidity 0.8+ reverts on underflow, this would effectively block all transfers if such a tax rate is configured, rendering the token unusable. (Coverage: 7.2 Code Security, 7.4 Economic)

IssueThe `_getTaxWithPoolState` function calculates `tax = (amount * currentPoolState.buyTaxRate) / 10000` or `(amount * currentPoolState.sellTaxRate) / 10000`. The `buyTaxRate` and `sellTaxRate` are `uint16`. If these rates are set to a value greater than `10000` (e.g., 15000 for 150% tax), the calculated `tax` could exceed the `amount` being transferred. Subsequently, in `_taxedTransfer`, the operation `amount - tax` would result in an integer underflow. While Solidity 0.8+ reverts on underflow, this would effectively block all transfers if such a tax rate is configured, rendering the token unusable. (Coverage: 7.2 Code Security, 7.4 Economic)

FixImplement a check to ensure that `buyTaxRate` and `sellTaxRate` do not exceed `10000` (100%) during their setting or initialization. Alternatively, ensure that `tax` never exceeds `amount` before performing the subtraction, e.g., `uint256 remainingAmount = amount > tax ? amount - tax : 0;`. However, preventing rates > 100% is generally a better design.

StatusUnresolved

High

Critical External Dependencies Are Immutable After Initialization

H-01The addresses for `taxProcessor`, `dividendContract`, `v2Router`, `quoteToken`, and `mainPool` are set exclusively during the `initialize` function and cannot be modified thereafter. These are critical external dependencies for the token's core functionality (tax processing, dividends, liquidity). If any of these external contracts become compromised, deprecated, or require an update (e.g., a new router version, a bug fix in the tax processor), the system would be unable to adapt without a full contract upgrade, potentially leading to a permanent loss of functionality or funds. (Coverage: 7.1 Architecture, 7.6 External, 7.8 Operations)

IssueThe addresses for `taxProcessor`, `dividendContract`, `v2Router`, `quoteToken`, and `mainPool` are set exclusively during the `initialize` function and cannot be modified thereafter. These are critical external dependencies for the token's core functionality (tax processing, dividends, liquidity). If any of these external contracts become compromised, deprecated, or require an update (e.g., a new router version, a bug fix in the tax processor), the system would be unable to adapt without a full contract upgrade, potentially leading to a permanent loss of functionality or funds. (Coverage: 7.1 Architecture, 7.6 External, 7.8 Operations)

FixImplement `onlyOwner` functions to allow the authorized owner to update these critical external dependency addresses. This provides necessary flexibility and resilience against external changes or issues.

StatusUnresolved

Medium

Publicly Triggerable State Transitions and Tax Liquidation

M-01The `_liquidateTax` function, which contains logic for changing the `PoolState` (e.g., from `TaxEnforcedAntiFarmer` to `TaxEnforced` or `TaxFree`) and potentially initiating tax processing, is called internally by `_transfer` when tokens are sent to the `mainPool`. If `mainPool` is a publicly accessible AMM pool, any user can trigger this function by simply transferring tokens to it. This creates a potential for front-running or malicious actors to force state transitions at economically unfavorable times, or to repeatedly trigger the liquidation logic, potentially impacting system stability or gas costs. (Coverage: 7.3 Access Control, 7.4 Economic)

IssueThe `_liquidateTax` function, which contains logic for changing the `PoolState` (e.g., from `TaxEnforcedAntiFarmer` to `TaxEnforced` or `TaxFree`) and potentially initiating tax processing, is called internally by `_transfer` when tokens are sent to the `mainPool`. If `mainPool` is a publicly accessible AMM pool, any user can trigger this function by simply transferring tokens to it. This creates a potential for front-running or malicious actors to force state transitions at economically unfavorable times, or to repeatedly trigger the liquidation logic, potentially impacting system stability or gas costs. (Coverage: 7.3 Access Control, 7.4 Economic)

FixRe-evaluate the trigger mechanism for `_liquidateTax`. Consider restricting its execution to `onlyOwner` or a designated `taxProcessor` role, or implementing a cooldown period or minimum amount threshold to prevent abuse. If public triggering is intended, ensure that the economic implications of such actions are thoroughly modeled and mitigated.

StatusUnresolved

Medium

Centralization of Power with Owner/Deployer

M-02The contract grants significant control to the `owner` role, allowing them to initiate and finalize migration states (`startMigration`, `finalizeMigration`). Furthermore, the entire `maxSupply` of tokens is minted to `msg.sender` (the deployer/initializer) during the `initialize` function. This concentration of power in a single entity (the owner/deployer) introduces a single point of failure. If the owner's private key is compromised, an attacker could manipulate the token's state, potentially leading to economic damage or loss of funds. (Coverage: 7.3 Access Control, 7.4 Economic, 7.5 Governance)

IssueThe contract grants significant control to the `owner` role, allowing them to initiate and finalize migration states (`startMigration`, `finalizeMigration`). Furthermore, the entire `maxSupply` of tokens is minted to `msg.sender` (the deployer/initializer) during the `initialize` function. This concentration of power in a single entity (the owner/deployer) introduces a single point of failure. If the owner's private key is compromised, an attacker could manipulate the token's state, potentially leading to economic damage or loss of funds. (Coverage: 7.3 Access Control, 7.4 Economic, 7.5 Governance)

FixConsider implementing a multi-signature wallet for the `owner` role to distribute control and enhance security. For token distribution, explore more decentralized or time-locked vesting mechanisms rather than minting the entire supply to a single address.

StatusUnresolved

Low

Lack of Explicit Upgrade Authorization in Implementation

L-01While the contract is designed as an upgradeable implementation, the provided code snippet does not include an explicit `_authorizeUpgrade` function, which is a standard component of UUPS proxy patterns to define who can initiate an upgrade. Although the proxy contract itself typically handles upgrade authorization, its absence in the implementation means the implementation contract itself doesn't enforce any specific upgrade policy, relying entirely on the proxy's configuration. This isn't a direct vulnerability in the implementation but highlights a dependency on the proxy's security configuration. (Coverage: 7.7 Upgrades)

IssueWhile the contract is designed as an upgradeable implementation, the provided code snippet does not include an explicit `_authorizeUpgrade` function, which is a standard component of UUPS proxy patterns to define who can initiate an upgrade. Although the proxy contract itself typically handles upgrade authorization, its absence in the implementation means the implementation contract itself doesn't enforce any specific upgrade policy, relying entirely on the proxy's configuration. This isn't a direct vulnerability in the implementation but highlights a dependency on the proxy's security configuration. (Coverage: 7.7 Upgrades)

FixEnsure the proxy contract () has robust and secure upgrade authorization mechanisms, preferably using a multi-signature wallet or a well-tested governance module.

StatusUnresolved

Info

Reliance on `block.timestamp` for Critical Timings

I-01The contract uses `block.timestamp` to manage `taxExpirationTime` and `antiFarmerExpirationTime` for state transitions within the `_liquidateTax` function. While `block.timestamp` is commonly used, miners have a limited ability to manipulate it (typically within a 900-second window on Ethereum, less on faster chains like Base). For critical, high-value, or time-sensitive operations, this manipulation could potentially be exploited by sophisticated attackers to front-run or delay state changes for economic gain. (Coverage: 7.2 Code Security, 7.4 Economic)

IssueThe contract uses `block.timestamp` to manage `taxExpirationTime` and `antiFarmerExpirationTime` for state transitions within the `_liquidateTax` function. While `block.timestamp` is commonly used, miners have a limited ability to manipulate it (typically within a 900-second window on Ethereum, less on faster chains like Base). For critical, high-value, or time-sensitive operations, this manipulation could potentially be exploited by sophisticated attackers to front-run or delay state changes for economic gain. (Coverage: 7.2 Code Security, 7.4 Economic)

FixFor highly time-sensitive or economically critical operations, consider using a time oracle (e.g., Chainlink Keepers or a custom decentralized oracle) rather than `block.timestamp` directly. For state transitions that are not extremely time-critical, `block.timestamp` is generally acceptable, but the potential for minor manipulation should be acknowledged.

StatusUnresolved

Category Ratings

TechnicalMedium5/10

The contract demonstrates good code quality by utilizing OpenZeppelin upgradeable standards and packed structs for gas efficiency. However, critical vulnerabilities exist, including a potential integer underflow in the tax calculation if rates exceed 100%, which could block all transfers (C-02). Additionally, the `_liquidateTax` function, which triggers state changes, can be publicly called by transferring tokens to `mainPool`, creating front-running opportunities (M-01). (Coverage: 7.2 Code Security, 7.3 Access Control, 7.4 Economic)

GovernanceHigh2/10

The contract's economic model incorporates a flexible tax mechanism and state transitions, managed by the owner. A significant risk is the immutability of critical external dependencies like `taxProcessor` and `v2Router` after initialization (H-01), which limits adaptability to external changes. Furthermore, the owner holds substantial power, including control over migration states and initial token supply distribution, posing a centralization risk (M-02). (Coverage: 7.3 Access Control, 7.4 Economic, 7.5 Governance, 7.6 External, 7.8 Operations)

UpgradesMedium6/10

The contract correctly uses OpenZeppelin's upgradeable patterns, including `Initializable` and `_disableInitializers`. However, a critical upgrade safety issue exists where `immutable` variables (`MIN_LIQ_THRESHOLD`, `START_LIQ_THRESHOLD`) are initialized in the constructor (C-01). These values will be zero in the proxy's context, leading to fundamental logic errors. (Coverage: 7.1 Architecture, 7.7 Upgrades)

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

36.9% in top 10

31.9% in wallets5.0% in contracts

Effective Concentration33.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

$251.8K across 9 pairs

PancakeswapVVVanalysed$232.4K AerodromeUSDC$14.7K Uniswap v4USDC$2.9K Uniswap v4USDC$995 Uniswap v4USDC$485 PancakeswapUSDC$122

Show 3 more pairsShow less

Uniswap v4USDC$100 Uniswap v4USDC$24 Uniswap v2USDC$2

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

0xfc3e…87e3

Unlocked LP Held By

0xca57…0807

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

What Raised This Score

9 factors

Top-10 concentration > 30% (36.9% total → 33.9% effective; 31.9% in EOAs, 5.0% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 92% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 92% of DEX liquidity)
Token age < 7 days (early, volatile)
2 Critical finding(s) from audit
1 High finding(s) from audit
2 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

Not Signed In

Is VCAT a Scam?

Security Findings

Immutable Variables in Upgradeable Contract Constructor Remain Zero in Proxy Context

Potential Integer Underflow in Tax Calculation

Critical External Dependencies Are Immutable After Initialization

Publicly Triggerable State Transitions and Tax Liquidation

Centralization of Power with Owner/Deployer

Lack of Explicit Upgrade Authorization in Implementation

Reliance on `block.timestamp` for Critical Timings

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of VCAT?