Is 牛来 Safe? Smart Contract Security Analysis

Security Findings

3 Med1 Low1 Info

Medium

Reentrancy Risk in External Calls within `_processTax`

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

IssueThe `_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.

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

StatusUnresolved

Medium

Centralized Control by Owner

M-02The `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.

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

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

StatusUnresolved

Medium

Potential Storage Collisions in Upgrades

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

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

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

StatusUnresolved

Low

Gas Cost Implications of `_liquidateTax` on Every Transfer

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

IssueThe `_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.

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

StatusUnresolved

Info

High Initial Tax Rates Possible

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

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

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

StatusUnresolved

Category Ratings

TechnicalLow9/10

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

GovernanceLow9/10

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

UpgradesMedium4/10

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

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

Holder Composition

40.0% in top 10

8.9% in wallets31.1% in contracts

Effective Concentration21.4%

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

$2.90M across 10 pairs

Pancakeswap v2QQQBanalysed$1.39M Pancakeswap v3USDT$977.7K Pancakeswap v3USDT$294.1K UniswapUSDT$223.7K Pancakeswap v2WBNB$10.6K Uniswap v2USDT$185

Show 4 more pairsShow less

Pancakeswap v2USDT$102 Pancakeswap v2MarsCoin$27 Pancakeswap v3Cake$23 Uniswap v2WBNB$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 Holder18.8%

Top-3 Unlocked38.1%

Key Addresses

11 addresses

Deployer

0x6af3…679e

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.

What Raised This Score

7 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

Final Recommendation

AI Copilot

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

Read the verdictHide

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

TypeFlapTaxTokenV3

Audit History

1 audit on record

Aug 304Sep 433

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

Is 牛来 Safe?

Security Findings

Reentrancy Risk in External Calls within `_processTax`

Centralized Control by Owner

Potential Storage Collisions in Upgrades

Gas Cost Implications of `_liquidateTax` on Every Transfer

High Initial Tax Rates Possible

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of 牛来?