Quantum Audit Logo

Is Fuse Cat a Scam?

Early-stage security check — honeypot & rug-pull analysis

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

Fuse Cat FUSECAT
0x6821…0212
Ethereum
Not verifiedThis 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 8d ago 1 audit on record New Launch · 13h old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The Fuse Cat Token contract implements a custom ERC-20 token with advanced features including dynamic transaction taxes, anti-bot mechanisms, max transaction/wallet size limits, and an early buying phase. The contract exhibits a high degree of centralization, with the owner possessing extensive control over critical parameters and operational functions. Key technical concerns include a non-standard `balanceOf` override, potential for sandwich attacks on tax swaps, and the use of a global variable for transaction state. The lack of upgradeability means any discovered issues cannot be patched post-deployment.

1 Critical2 High2 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (13h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$1.91M
Liquidity
$285.6K
Price
$0.00711
Token Age
13h
Top 10 Holders
13.5%

Security Findings

1 Crit2 High2 Med1 Low1 Info
Critical

Centralized Control and Extensive Owner Privileges

C-01The contract owner possesses extensive control over critical parameters and operational functions, including setting tax rates, modifying max transaction/wallet sizes, enabling/disabling trading, managing blacklisted addresses, and controlling the early buying phase. This high degree of centralization introduces significant trust assumptions and a single point of failure, allowing the owner to unilaterally alter tokenomics or restrict user access.
IssueThe contract owner possesses extensive control over critical parameters and operational functions, including setting tax rates, modifying max transaction/wallet sizes, enabling/disabling trading, managing blacklisted addresses, and controlling the early buying phase. This high degree of centralization introduces significant trust assumptions and a single point of failure, allowing the owner to unilaterally alter tokenomics or restrict user access.
FixImplement a multi-signature wallet for critical administrative functions to distribute control and reduce the risk of a single point of compromise. Consider introducing a timelock for sensitive parameter changes to provide transparency and allow the community to react to proposed modifications. Explore mechanisms for progressive decentralization over time.
StatusUnresolved
High

Sandwich Attack Vulnerability in Tax Swaps

H-01The `swapExactTokensForETHSupportingFeeOnTransferTokens` function, used for automatic tax collection, is called with `amountOutMin = 0`. This allows malicious actors to execute sandwich attacks by front-running the swap with a buy order and back-running with a sell order, manipulating the price and extracting value. This results in the `_taxWallet` receiving less ETH than expected, impacting the protocol's intended revenue.
IssueThe `swapExactTokensForETHSupportingFeeOnTransferTokens` function, used for automatic tax collection, is called with `amountOutMin = 0`. This allows malicious actors to execute sandwich attacks by front-running the swap with a buy order and back-running with a sell order, manipulating the price and extracting value. This results in the `_taxWallet` receiving less ETH than expected, impacting the protocol's intended revenue.
FixImplement a slippage tolerance by calculating a reasonable `amountOutMin` based on the expected amount and a predefined acceptable slippage percentage. Alternatively, consider using a trusted oracle or a TWAP mechanism to determine a fair price for swaps, or integrate with a DEX aggregator that handles slippage protection.
StatusUnresolved
High

Ambiguous `balanceOf` Override and `tx.origin` Usage

H-02The `balanceOf` function is overridden with complex conditional logic (`_MARTIANSsp` variable) and includes a check for `_isExcludedFromFee[tx.origin]`. This non-standard implementation can lead to unexpected balance reporting for external integrations (e.g., DEXs, wallets) and introduces a dependency on `tx.origin`, which is generally discouraged due to potential phishing risks (though less critical here for fee exclusion).
IssueThe `balanceOf` function is overridden with complex conditional logic (`_MARTIANSsp` variable) and includes a check for `_isExcludedFromFee[tx.origin]`. This non-standard implementation can lead to unexpected balance reporting for external integrations (e.g., DEXs, wallets) and introduces a dependency on `tx.origin`, which is generally discouraged due to potential phishing risks (though less critical here for fee exclusion).
FixSimplify the `balanceOf` function to adhere to standard ERC-20 behavior. If specific addresses need to be excluded from fees, manage this logic within the `_transfer` function rather than altering `balanceOf`. Avoid using `tx.origin` for any critical logic, even for fee exclusion, to prevent potential misinterpretations or vulnerabilities in complex interaction scenarios.
StatusUnresolved
Medium

Dynamic Tax Mechanism Susceptible to Manipulation

M-01The contract implements dynamic buy/sell taxes that reduce after a certain number of transactions (`_buyCount`, `sellCount`) reaches predefined thresholds (`_reduceBuyTaxAt`, `_reduceSellTaxAt`). This mechanism can be gamed by bots or sophisticated users who can execute numerous small transactions to artificially inflate the transaction counts, thereby lowering the taxes for subsequent larger trades and impacting the intended tax revenue model.
IssueThe contract implements dynamic buy/sell taxes that reduce after a certain number of transactions (`_buyCount`, `sellCount`) reaches predefined thresholds (`_reduceBuyTaxAt`, `_reduceSellTaxAt`). This mechanism can be gamed by bots or sophisticated users who can execute numerous small transactions to artificially inflate the transaction counts, thereby lowering the taxes for subsequent larger trades and impacting the intended tax revenue model.
FixRe-evaluate the dynamic tax reduction mechanism. Consider alternative methods for tax reduction that are less susceptible to manipulation, such as time-based reductions, or implement more robust anti-bot measures that specifically target such gaming behavior. Clearly document the intended behavior and potential implications of this mechanism.
StatusUnresolved
Medium

Global Variable for Transaction State (`_SYMBOLgod`)

M-02The `_SYMBOLgod` variable is declared as a global state variable and is used to temporarily store the `amount` within the `transferFrom` function. While its immediate use might mitigate direct reentrancy in this specific context, using a global state variable for local transaction data is poor programming practice. It can lead to subtle bugs, race conditions, or unexpected behavior in more complex scenarios or if the contract's logic is expanded in the future.
IssueThe `_SYMBOLgod` variable is declared as a global state variable and is used to temporarily store the `amount` within the `transferFrom` function. While its immediate use might mitigate direct reentrancy in this specific context, using a global state variable for local transaction data is poor programming practice. It can lead to subtle bugs, race conditions, or unexpected behavior in more complex scenarios or if the contract's logic is expanded in the future.
FixRefactor the `transferFrom` function to use a local variable for the `amount` instead of the global `_SYMBOLgod` variable. This improves code clarity, reduces potential side effects, and adheres to best practices for managing transaction-specific data.
StatusUnresolved
Low

Renounce Ownership Implication

L-01The `renounceOwnership` function allows the owner to transfer ownership to the zero address. Given the extensive owner privileges in this contract, calling this function would effectively make the contract unmanageable, as many critical functions are protected by the `onlyOwner` modifier. This could lead to a 'bricked' contract where no administrative actions can be performed.
IssueThe `renounceOwnership` function allows the owner to transfer ownership to the zero address. Given the extensive owner privileges in this contract, calling this function would effectively make the contract unmanageable, as many critical functions are protected by the `onlyOwner` modifier. This could lead to a 'bricked' contract where no administrative actions can be performed.
FixEnsure the owner fully understands the implications of `renounceOwnership`. If the intention is to decentralize control, a more robust governance mechanism should be implemented rather than simply renouncing ownership. If renouncing is desired, ensure all necessary parameters are immutable or managed by other means before doing so.
StatusUnresolved
Info

Lack of Upgradeability

I-01The contract is not designed with an upgrade proxy pattern (e.g., UUPS, Transparent). This means that the contract's logic is immutable once deployed. Any discovered vulnerabilities, bugs, or desired feature enhancements post-deployment cannot be implemented without deploying a new contract and migrating all assets and users, which is a complex, costly, and risky process.
IssueThe contract is not designed with an upgrade proxy pattern (e.g., UUPS, Transparent). This means that the contract's logic is immutable once deployed. Any discovered vulnerabilities, bugs, or desired feature enhancements post-deployment cannot be implemented without deploying a new contract and migrating all assets and users, which is a complex, costly, and risky process.
FixFor future projects or if long-term adaptability is a requirement, consider implementing an upgradeable proxy pattern. This allows for bug fixes and feature enhancements without requiring a full redeployment and migration, improving the protocol's resilience and longevity.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract utilizes SafeMath for arithmetic operations, enhancing robustness against overflow/underflow (7.2 Code Security). However, the `balanceOf` function includes non-standard conditional logic and `tx.origin` checks, which can lead to unexpected behavior and integration issues (7.2 Code Security). The use of a global variable (`_SYMBOLgod`) for temporary transaction state in `transferFrom` is a poor practice that could introduce subtle bugs or race conditions (7.2 Code Security). Additionally, the automatic tax swap mechanism is vulnerable to sandwich attacks due to `amountOutMin` being set to zero (7.6 External).

GovernanceHigh1/10

The contract exhibits a high degree of centralization, with the owner having extensive control over critical parameters such as tax rates, max transaction/wallet sizes, trading status, and the ability to blacklist addresses (7.3 Access Control, 7.8 Operations). This introduces significant economic risk, as the owner can unilaterally alter tokenomics or restrict trading (7.4 Economic). The dynamic tax mechanism, which reduces taxes after a certain number of transactions, could be gamed by bots to artificially lower rates (7.4 Economic). The lack of decentralized governance means all critical decisions rest with a single entity (7.5 Governance).

UpgradesMedium6/10

The contract is not designed with an upgrade proxy pattern, meaning it is not upgradeable (7.7 Upgrades). Any vulnerabilities discovered post-deployment or desired feature enhancements cannot be implemented without deploying a new contract and migrating assets, which is a complex, costly, and risky process. This lack of flexibility poses a significant long-term risk to the protocol's adaptability and security.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

13.5% in top 10
10.4% in wallets3.1% in contracts
Effective Concentration11.6%

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

$285.6K

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

LP Burned99.1% · ≈ permanent lock
LP Locked99.1% · Null Address

Key Addresses

3 addresses
Deployer
0x3f74…fde5
Unlocked LP Held By
0xf385…5f850x9fa5…f377

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

What Raised This Score

6 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Token age < 24h (brand new — bot activity, unproven)
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 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
SEIHigh RiskDolomite (DOLO)High RiskRedstone (RED)High RiskPinLink (PIN)High RiskSPACE ID (ID)High RiskHarryPotterObamaSonic10Inu (BITCOIN)High Risk

Would You Like a More Detailed Audit of Fuse Cat?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit