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.

On-chain security analysis — is it a scam or legit?
Is 牛来 Safe?
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 →The FlapTaxTokenV3 contract is an upgradeable ERC20 token incorporating dynamic tax mechanisms and state management.
Read the full analysis- 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 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking31.1%
- Walletsanonymous holders, free to sell8.9%
- Everyone elsethe rest of the supply60.0%
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- Pancakeswap v2QQQBAnalysed$1.39M48.0%
- Pancakeswap v3USDT$977.7K33.8%
- Pancakeswap v3USDT$294.1K10.2%
- UniswapUSDT$223.7K7.7%
- Pancakeswap v2WBNB$10.6K0.4%
- Uniswap v2USDT$1850.0%
Show 4 more pairs
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xb26e…a6f30xd957…4afc0xe295…1bc60x2913…bb1d0xb969…15f40xed24…2db20x6698…62010x8fdb…e3fe0x0be7…7c7c0x146e…0031No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
MediumReentrancy 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
_processTaxIssue
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
MediumCentralized 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
MediumPotential 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
LowGas 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
_liquidateTax on Every TransferIssue
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
InfoHigh 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 4The 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).
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).
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).
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
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 4, 202633Low
- 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