Quantum Audit Logo
Launch App

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

Is 牛来 Safe?

BNB 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 is an upgradeable ERC20 token incorporating dynamic tax mechanisms and state management.

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
  • Token age < 30 days
  • 3 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% (40.0% total → 21.4% effective; 8.9% in EOAs, 31.1% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Token age < 30 days (still settling)
  • 3 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 45 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
31.1%Contracts8.9%Wallets60.0%Everyone else
31.1%Contracts8.9%60.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
40.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking31.1%
  • Walletsanonymous holders, free to sell8.9%
  • Everyone elsethe rest of the supply60.0%
Effective concentrationwhat the score reads21.4%
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$2.90M across 10 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$1.39MShare of depth48.0%
Top-1 Unlocked Holder18.8%
Top-3 Unlocked38.1%
Unlocked LP held by
0xb26e…a6f30xd957…4afc0xe295…1bc60x2913…bb1d0xb969…15f40xed24…2db20x6698…62010x8fdb…e3fe0x0be7…7c7c0x146e…0031

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

Security Findings

3 Medium1 Low1 Info
Medium

Reentrancy Risk in External Calls within _processTax

The _liquidateTax function uses a notLiquidating flag as a reentrancy guard for its own execution. However, the _processTax function, which is called within _liquidateTax and is expected to make external calls to taxProcessor and dividendContract, is truncated in the provided code. Without the full implementation, it's unclear if these external calls are adequately protected against reentrancy, potentially allowing malicious re-entries into other parts of the system or leading to unexpected state changes or fund manipulation.M-01

Issue

The _liquidateTax function uses a notLiquidating flag as a reentrancy guard for its own execution. However, the _processTax function, which is called within _liquidateTax and is expected to make external calls to taxProcessor and dividendContract, is truncated in the provided code. Without the full implementation, it's unclear if these external calls are adequately protected against reentrancy, potentially allowing malicious re-entries into other parts of the system or leading to unexpected state changes or fund manipulation.

Fix

Provide the complete implementation of the _processTax function for a thorough security review. Ensure that all external calls within _processTax are made with appropriate reentrancy guards (e.g., Checks-Effects-Interactions pattern, OpenZeppelin's ReentrancyGuard) to prevent malicious re-entries.

Status

Unresolved

Medium

Centralized Control by Owner

The onlyOwner modifier on startMigration and finalizeMigration grants significant power to a single address to transition the contract's operational state. These state changes directly impact tax application and token behavior, introducing a single point of failure and trust. A compromised owner key could lead to unauthorized state changes and potential economic manipulation.M-02

Issue

The onlyOwner modifier on startMigration and finalizeMigration grants significant power to a single address to transition the contract's operational state. These state changes directly impact tax application and token behavior, introducing a single point of failure and trust. A compromised owner key could lead to unauthorized state changes and potential economic manipulation.

Fix

Consider implementing a multi-signature wallet for the owner role to distribute control and reduce the risk of a single point of failure. Alternatively, introduce a time-lock mechanism for critical state-changing functions to provide a window for community review or emergency intervention.

Status

Unresolved

Medium

Potential Storage Collisions in Upgrades

The contract is designed as an upgradeable proxy implementation. The PackedPoolState struct is used for multiple state variables. Future upgrades that modify the layout of this struct (e.g., changing variable types, adding/removing variables) or the order of state variables in the contract without careful consideration of storage slot management could lead to storage collisions and data corruption, potentially bricking the contract or leading to loss of funds.M-03

Issue

The contract is designed as an upgradeable proxy implementation. The PackedPoolState struct is used for multiple state variables. Future upgrades that modify the layout of this struct (e.g., changing variable types, adding/removing variables) or the order of state variables in the contract without careful consideration of storage slot management could lead to storage collisions and data corruption, potentially bricking the contract or leading to loss of funds.

Fix

Adhere strictly to the storage layout rules for upgradeable contracts. When modifying structs or adding new state variables in future versions, ensure that new variables are appended to the end of the storage layout and that existing variable types or order are not changed. Utilize tools like hardhat-upgrades or truffle-upgrades to detect storage layout incompatibilities during development.

Status

Unresolved

Low

Gas Cost Implications of _liquidateTax on Every Transfer

The _liquidateTax function is invoked at the beginning of every _transfer operation. While its core logic is conditionally executed (only for transfers to mainPool under specific conditions), this unconditional call adds a small, constant gas overhead to all transfers. For transfers that trigger the full liquidation process, the gas cost could be significantly higher, potentially impacting user experience and network congestion.L-01

Issue

The _liquidateTax function is invoked at the beginning of every _transfer operation. While its core logic is conditionally executed (only for transfers to mainPool under specific conditions), this unconditional call adds a small, constant gas overhead to all transfers. For transfers that trigger the full liquidation process, the gas cost could be significantly higher, potentially impacting user experience and network congestion.

Fix

Consider refactoring the _liquidateTax call to be more conditional, perhaps only calling it when to == mainPool or when a specific flag indicates a potential need for liquidation, rather than on every transfer. Alternatively, ensure that the _processTax function is highly optimized for gas efficiency.

Status

Unresolved

Info

High Initial Tax Rates Possible

The buyTaxRate and sellTaxRate are uint16 values set during initialization, allowing for rates up to 655.35% (65535/10000). While there are no setters to change these rates post-initialization, the ability to set such extremely high rates initially could render the token economically unviable or lead to user distrust if misconfigured. This is a configuration risk rather than a code vulnerability.I-01

Issue

The buyTaxRate and sellTaxRate are uint16 values set during initialization, allowing for rates up to 655.35% (65535/10000). While there are no setters to change these rates post-initialization, the ability to set such extremely high rates initially could render the token economically unviable or lead to user distrust if misconfigured. This is a configuration risk rather than a code vulnerability.

Fix

Ensure that the initial buyTaxRate and sellTaxRate are set to economically sensible values during deployment. Clearly communicate the chosen tax rates to users to manage expectations and maintain transparency.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The FlapTaxTokenV3 contract is an upgradeable ERC20 token incorporating dynamic tax mechanisms and state management. It leverages OpenZeppelin's upgradeable contracts for security and maintainability. The audit identified several medium-severity issues related to potential reentrancy in external calls, centralized owner control over critical state transitions, and upgrade safety concerns regarding storage collisions. Additionally, minor issues include gas cost implications and configuration risks for initial tax rates. A significant portion of the _processTax function was truncated, limiting a full security assessment of its critical logic.

Technical9/10Low risk

The contract demonstrates good practices by using OpenZeppelin's upgradeable contracts and SafeERC20 for external token interactions (7.2 Code Security). The PackedPoolState struct helps optimize storage. However, the truncated _processTax function presents an unknown risk, particularly regarding reentrancy in its external calls (7.2 Code Security). Additionally, the _liquidateTax function is called on every transfer, potentially increasing gas costs for users (7.8 Operations).

Governance9/10Low risk

The contract implements a centralized ownership model, with the onlyOwner role having significant control over critical state transitions like startMigration and finalizeMigration (7.3 Access Control, 7.5 Governance). This allows the owner to directly influence tax application and token behavior. While initial tax rates are fixed, the design permits setting extremely high rates during initialization, which could impact economic viability if misconfigured (7.4 Economic).

Upgrades4/10Medium risk

The contract is designed for upgradeability using OpenZeppelin's Initializable pattern, correctly disabling initializers in the constructor and using the initializer modifier. However, the use of a custom PackedPoolState struct for multiple state variables introduces a risk of storage collisions if its layout or the order of state variables is altered in future upgrades without careful storage slot management (7.7 Upgrades).

Final RecommendationWhat to do about this score

Prioritize a full review of the _processTax function's complete implementation to ensure all external calls are robustly protected against reentrancy and other vulnerabilities.

Implement a multi-signature wallet or time-locked governance for critical owner-controlled functions to mitigate centralized control risks and enhance decentralization. For future upgrades, meticulously plan storage slot management, especially for custom structs, to prevent data corruption. Consider optimizing the _liquidateTax call to reduce gas overhead on non-relevant transfers.

Contract & Record

1 audit on record
TypeFlapTaxTokenV3
NetworkBNB Chain
Token age16d
Contract0xbeea…7777
Deployer0x6af3…679e
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Badge for your website
牛来 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, 202633Low
  2. Aug 30, 20264Low

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

Frequently Asked Questions

What is the 牛来 contract address?

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

Is 牛来 a scam?

Quantum Audit's risk score for 牛来 is 33/100 (Low 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; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is 牛来 liquidity locked?

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

Who holds 牛来?

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

Would You Like a More Detailed Audit of 牛来?

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