Quantum Audit Logo

Is VenusCoin Safe?

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

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

VenusCoin VENUSCOIN
0x5460…7777
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a dynamic tax mechanism and multiple operational states. It leverages OpenZeppelin's upgradeable contracts for security and maintainability. However, a critical portion of the `_liquidateTax` function, specifically the `_processTax` implementation, is missing from the provided source, which prevents a complete security assessment of the core economic logic. Additionally, potential reentrancy vectors and significant owner privileges were identified.

1 Critical2 High1 Medium1 Low1 Informational
Volume 24h
$100.7K
Liquidity
$59.7K
Price
$0.000154
Token Age
8d
Top 10 Holders
46.4%

Security Findings

1 Crit2 High1 Med1 Low1 Info
Critical

Missing Critical Logic in `_liquidateTax` Function

C-01The provided source code for the `_liquidateTax` function is truncated, specifically omitting the implementation of `_processTax(taxAmount)` and subsequent logic. The `_processTax` function is crucial for handling collected taxes and is central to the token's economic model. Without its full implementation, a comprehensive security assessment of the contract's core functionality, including potential vulnerabilities like reentrancy, denial-of-service, or economic exploits, is impossible.
IssueThe provided source code for the `_liquidateTax` function is truncated, specifically omitting the implementation of `_processTax(taxAmount)` and subsequent logic. The `_processTax` function is crucial for handling collected taxes and is central to the token's economic model. Without its full implementation, a comprehensive security assessment of the contract's core functionality, including potential vulnerabilities like reentrancy, denial-of-service, or economic exploits, is impossible.
FixProvide the complete and final source code for the `_liquidateTax` function, including the `_processTax` implementation and any related external contracts (e.g., `ITaxProcessor`, `IDividend`). A full audit cannot be completed without this critical component.
StatusUnresolved
High

Potential Reentrancy Vulnerability in `_liquidateTax`

H-01The `_liquidateTax` function, called on every `_transfer`, makes an external call to `_processTax(taxAmount)`. While a `notLiquidating` flag is used as a local reentrancy guard within `_liquidateTax` to prevent `_processTax` from being called multiple times in a single execution, it does not prevent reentrancy into other functions of the `FlapTaxTokenV3` contract. If `_processTax` (or any contract it interacts with) can call back into `FlapTaxTokenV3` (e.g., by initiating another `transfer`), it could lead to unexpected state changes, double-spending, or other exploits before the initial `_transfer` completes.
IssueThe `_liquidateTax` function, called on every `_transfer`, makes an external call to `_processTax(taxAmount)`. While a `notLiquidating` flag is used as a local reentrancy guard within `_liquidateTax` to prevent `_processTax` from being called multiple times in a single execution, it does not prevent reentrancy into other functions of the `FlapTaxTokenV3` contract. If `_processTax` (or any contract it interacts with) can call back into `FlapTaxTokenV3` (e.g., by initiating another `transfer`), it could lead to unexpected state changes, double-spending, or other exploits before the initial `_transfer` completes.
FixImplement a robust reentrancy guard mechanism, such as OpenZeppelin's `ReentrancyGuard` or the Checks-Effects-Interactions pattern, for all external calls within `_liquidateTax` and the `_processTax` function. Ensure that all state changes occur before any external calls are made.
StatusUnresolved
High

Centralization Risk via Owner Privileges

H-02The `startMigration` and `finalizeMigration` functions, which control critical `PoolState` transitions (e.g., from `BondingCurve` to `Migrating` and then to `TaxEnforcedAntiFarmer`), are protected by the `onlyOwner` modifier. This grants a single address (the owner) significant power to unilaterally change the token's operational state and economic behavior, potentially impacting all token holders and the protocol's functionality.
IssueThe `startMigration` and `finalizeMigration` functions, which control critical `PoolState` transitions (e.g., from `BondingCurve` to `Migrating` and then to `TaxEnforcedAntiFarmer`), are protected by the `onlyOwner` modifier. This grants a single address (the owner) significant power to unilaterally change the token's operational state and economic behavior, potentially impacting all token holders and the protocol's functionality.
FixConsider decentralizing control over critical state transitions. This could involve implementing a multi-signature wallet for the owner address, introducing a time-lock for sensitive operations, or integrating a decentralized governance mechanism to approve such changes.
StatusUnresolved
Medium

Fixed Economic Parameters Post-Initialization

M-01Key economic parameters such as `buyTaxRate`, `sellTaxRate`, `antiFarmerDuration`, and `taxDuration` are set exclusively during the `initialize` function and cannot be modified thereafter. While `taxExpirationTime` and `antiFarmerExpirationTime` are updated based on these durations, the base rates and durations themselves are immutable. This lack of flexibility means the protocol cannot adapt to changing market conditions, correct misconfigurations, or adjust its economic model without a full contract upgrade.
IssueKey economic parameters such as `buyTaxRate`, `sellTaxRate`, `antiFarmerDuration`, and `taxDuration` are set exclusively during the `initialize` function and cannot be modified thereafter. While `taxExpirationTime` and `antiFarmerExpirationTime` are updated based on these durations, the base rates and durations themselves are immutable. This lack of flexibility means the protocol cannot adapt to changing market conditions, correct misconfigurations, or adjust its economic model without a full contract upgrade.
FixEvaluate whether these parameters should be fixed. If flexibility is desired, consider implementing owner-controlled functions to update these parameters, potentially with time-locks or multi-signature approvals to ensure secure and transparent changes.
StatusUnresolved
Low

Potential for Stuck Tax Funds

L-01The `_taxedTransfer` function sends collected tax amounts to `address(this)`. These funds are intended to be processed by `_processTax` within `_liquidateTax`. However, if the conditions for `_liquidateTax` to call `_processTax` are never met (e.g., `liquidationThreshold` is too high, or `taxExpirationTime` is not reached), or if `_processTax` itself fails, accumulated tax tokens could remain in the contract indefinitely, becoming inaccessible.
IssueThe `_taxedTransfer` function sends collected tax amounts to `address(this)`. These funds are intended to be processed by `_processTax` within `_liquidateTax`. However, if the conditions for `_liquidateTax` to call `_processTax` are never met (e.g., `liquidationThreshold` is too high, or `taxExpirationTime` is not reached), or if `_processTax` itself fails, accumulated tax tokens could remain in the contract indefinitely, becoming inaccessible.
FixEnsure that the conditions for `_processTax` to be called are robust and will eventually be met. Consider implementing an emergency function, callable by the owner or governance, to sweep stuck funds from the contract in unforeseen circumstances, with appropriate safeguards.
StatusUnresolved
Info

Gas Considerations for `_liquidateTax` on Every Transfer

I-01The `_liquidateTax` function is invoked at the beginning of every `_transfer` operation. Depending on the complexity of the `_processTax` function (which is currently missing) and the frequency of state transitions or tax processing, this could lead to increased gas costs for every token transfer. While this design ensures tax processing is consistently checked, it might impact user experience or transaction costs under high network congestion or if `_processTax` is resource-intensive.
IssueThe `_liquidateTax` function is invoked at the beginning of every `_transfer` operation. Depending on the complexity of the `_processTax` function (which is currently missing) and the frequency of state transitions or tax processing, this could lead to increased gas costs for every token transfer. While this design ensures tax processing is consistently checked, it might impact user experience or transaction costs under high network congestion or if `_processTax` is resource-intensive.
FixOnce `_processTax` is implemented, thoroughly test its gas consumption. If gas costs become a concern, consider optimizing the `_liquidateTax` logic or `_processTax` implementation, or explore alternative mechanisms for triggering tax processing (e.g., a dedicated `processTax` function that can be called periodically by an authorized entity).
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The contract utilizes OpenZeppelin's upgradeable ERC20 and access control patterns, which generally contribute to robust code security (7.2). The use of `SafeERC20` and packed structs (`PackedPoolState`) demonstrates good practices for safety and gas efficiency. However, a critical vulnerability exists due to the missing `_processTax` implementation within `_liquidateTax`, which is central to the token's functionality and security (7.1). Furthermore, the `_liquidateTax` function, which is called on every transfer, presents a reentrancy risk if `_processTax` makes external calls that can re-enter the token contract.

GovernanceMedium4/10

The contract's economic model relies heavily on a multi-state system (`PoolState`) and a tax mechanism. The owner has significant control over state transitions via `startMigration` and `finalizeMigration` (7.3), which can alter the token's transfer behavior and tax application. While this provides operational flexibility, it introduces centralization risk (7.5). The initial tax rates and durations are fixed post-initialization, limiting adaptability to market changes without an upgrade (7.4). The economic integrity is critically dependent on the unseen `_processTax` function, which handles collected taxes.

UpgradesHigh3/10

The contract is designed as an upgradeable proxy implementation, correctly using OpenZeppelin's `Initializable` pattern, `_disableInitializers()` in the constructor, and `initializer` modifier (7.7). This allows for future enhancements and bug fixes. Immutable variables are correctly handled in the constructor. Standard upgrade considerations, such as careful storage layout management to prevent collisions in future versions, remain important.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source

Holder Composition

46.4% in top 10
12.2% in wallets34.2% in contracts
Effective Concentration25.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

$59.8K across 3 pairs
Pancakeswap v2XAUtanalysed$59.7K99.9%Pancakeswap v3USDT$510.1%Uniswap v2USDT$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

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x5fe8…690c
Unlocked LP Held By
0x14e5…be4a

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

What Raised This Score

11 factors
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Top-10 concentration > 20% (46.4% total → 25.9% effective; 12.2% in EOAs, 34.2% in contracts — mild)
  • 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)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • Token age < 30 days (still settling)
  • 1 Critical finding(s) from audit
  • 2 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
SpaceX (SPCXB)Critical RiskLorenzo Governance Token (BANK)Critical RiskBedrock (BR)Critical RiskCysic Token (CYS)Critical RiskBased Token (BASED)Critical RiskZypher Token (POP)Critical Risk

Would You Like a More Detailed Audit of VenusCoin?

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

Get Detailed Audit