Quantum Audit Logo
Launch App

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

Is VenusCoin Safe?

VENUSCOINBNB 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
SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a dynamic tax mechanism and multiple operational states.

Read the full analysis
What raised the score
  • Proxy contract
  • Non-standard proxy storage
  • Top-10 concentration > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • Token age < 30 days
  • 1 Critical finding(s) from audit
  • 2 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% (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

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
34.2%Contracts12.2%Wallets53.6%Everyone else
34.2%Contracts12.2%53.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
46.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking34.2%
  • Walletsanonymous holders, free to sell12.2%
  • Everyone elsethe rest of the supply53.6%
Effective concentrationwhat the score reads25.9%
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$59.8K across 3 pairs
LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$59.7KShare of depth99.9%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x14e5…be4a

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

Security Findings

1 Critical2 High1 Medium1 Low1 Info
Critical

Missing Critical Logic in _liquidateTax Function

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

Issue

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

Fix

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

Status

Unresolved

High

Potential Reentrancy Vulnerability in _liquidateTax

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

Issue

The _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.

Fix

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

Status

Unresolved

High

Centralization Risk via Owner Privileges

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

Issue

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

Fix

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

Status

Unresolved

Medium

Fixed Economic Parameters Post-Initialization

Key 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.M-01

Issue

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

Fix

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

Status

Unresolved

Low

Potential for Stuck Tax Funds

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

Issue

The _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.

Fix

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

Status

Unresolved

Info

Gas Considerations for _liquidateTax on Every Transfer

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

Issue

The _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.

Fix

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

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

Technical5/10Medium risk

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.

Governance4/10Medium risk

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.

Upgrades3/10High risk

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.

Final RecommendationWhat to do about this score

Prioritize the completion and thorough audit of the _processTax function, as its absence is a critical blocker for a full security assessment.

Implement robust reentrancy guards, such as the Checks-Effects-Interactions pattern or OpenZeppelin's ReentrancyGuard, for all external calls within _liquidateTax and _processTax. Consider implementing a multi-signature wallet or time-locks for critical owner-controlled functions to mitigate centralization risks. Evaluate the necessity of fixed economic parameters and consider adding owner-controlled functions to adjust them if flexibility is desired.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age8d
Contract0x5460…7777
Deployer0x5fe8…690c
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Badge for your website
VenusCoin 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, 202677High
  2. Aug 13, 202661Medium

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

Frequently Asked Questions

What is the VENUSCOIN contract address?

The VenusCoin contract on BNB Chain is 0x5460b5e88799d27bbdf8a210926c17dec18d7777. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is VenusCoin a scam?

Quantum Audit's risk score for VenusCoin is 77/100 (High 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: Not locked; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is VENUSCOIN liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $59.8K.

Who holds VENUSCOIN?

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

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 Is this your token? Publish your own audit on this page