Quantum Audit Logo
Launch App

Honeypot, rug-pull and ownership checks

Is Ethereumcat a Scam?

ETHCATEthereum
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
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance7/10Upgrades9/10Checks passed7 of 7Findings1 Critical · 2 High · 2 Medium · 1 Low · 1 Info7
SummaryAI Copilot

The ETHCAT token contract implements custom taxation, anti-bot, and anti-whale mechanisms.

Read the full analysis
What raised the score
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • 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

Our automated scanner reviewed Ethereumcat (ETHCAT) on Ethereum. 7 of 7 security checks passed — see the full breakdown below.

Security Checklist

as of audit · Sep 47 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
28.1%Contracts3.5%68.4%Everyone else
28.1%Contracts68.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
31.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking28.1%
  • Walletsanonymous holders, free to sell3.5%
  • Everyone elsethe rest of the supply68.4%
Effective concentrationwhat the score reads14.7%
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$88.7K across 2 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$85.2KShare of depth96.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address
Unlocked LP held by
0xf385…5f850xbb4b…1795

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

Security Findings

1 Critical2 High2 Medium1 Low1 Info
Critical

Missing Critical Helper Functions (min, isContract)

The _transfer function attempts to call min(amount,min(contractTokenBalance,_maxTaxSwap)) and require(!isContract(to)). However, neither a min function nor an isContract function is defined within the provided contract text or its inherited contracts. This will result in a compilation error or a runtime error if the contract were to be deployed, rendering the contract non-functional. This is a fundamental flaw in the contract's logic and implementation.C-01

Issue

The _transfer function attempts to call min(amount,min(contractTokenBalance,_maxTaxSwap)) and require(!isContract(to)). However, neither a min function nor an isContract function is defined within the provided contract text or its inherited contracts. This will result in a compilation error or a runtime error if the contract were to be deployed, rendering the contract non-functional. This is a fundamental flaw in the contract's logic and implementation.

Fix

Define and implement the min and isContract helper functions correctly within the contract or ensure they are imported from a reliable library. For min, consider using Math.min from OpenZeppelin's SafeCast or implementing a simple internal helper. For isContract, a common pattern involves checking address(account).code.length > 0.

Status

Unresolved

High

Centralized Control and Potential for Rug Pull/Honeypot

The contract owner, via the Ownable pattern, possesses extensive control over critical parameters. This includes the ability to modify buy/sell tax rates (_initialBuyTax, _finalBuyTax), transaction limits (_maxTxAmount), wallet size limits (_maxWalletSize), and manage the isExile list. Such broad control allows the owner to effectively block transfers, set sell taxes to 100%, or prevent specific users from trading, creating a significant risk of a rug pull or honeypot scenario. (7.3 Access Control, 7.4 Economic)H-01

Issue

The contract owner, via the Ownable pattern, possesses extensive control over critical parameters. This includes the ability to modify buy/sell tax rates (_initialBuyTax, _finalBuyTax), transaction limits (_maxTxAmount), wallet size limits (_maxWalletSize), and manage the isExile list. Such broad control allows the owner to effectively block transfers, set sell taxes to 100%, or prevent specific users from trading, creating a significant risk of a rug pull or honeypot scenario. (7.3 Access Control, 7.4 Economic)

Fix

Consider decentralizing control over critical parameters, perhaps through a multi-signature wallet or a time-locked governance mechanism. If full decentralization is not feasible, implement time-locks for sensitive parameter changes to provide users with a warning period. Clearly document the owner's capabilities and potential risks to users.

Status

Unresolved

High

Taxed ETH Not Used for Liquidity Provision

The contract's swapTokensForEth function converts collected tax tokens into ETH. However, the subsequent sendETHToFee function immediately transfers this ETH to the _taxWallet (which is the owner's address by default). This design means that the ETH generated from transaction taxes is not used to provide or reinforce liquidity on the Uniswap pair, but rather directly accrues to the owner. This can lead to a lack of sustainable liquidity growth and is a common characteristic of tokens designed for quick profit extraction rather than long-term stability. (7.4 Economic)H-02

Issue

The contract's swapTokensForEth function converts collected tax tokens into ETH. However, the subsequent sendETHToFee function immediately transfers this ETH to the _taxWallet (which is the owner's address by default). This design means that the ETH generated from transaction taxes is not used to provide or reinforce liquidity on the Uniswap pair, but rather directly accrues to the owner. This can lead to a lack of sustainable liquidity growth and is a common characteristic of tokens designed for quick profit extraction rather than long-term stability. (7.4 Economic)

Fix

If the intention is to support liquidity, modify the sendETHToFee logic to direct a portion or all of the collected ETH to add liquidity to the Uniswap pair. Clearly communicate the destination of collected taxes to token holders. If the current design is intentional, ensure this is transparently disclosed to all potential investors.

Status

Unresolved

Medium

Denial of Service via Anti-Bot/Anti-Whale Mechanisms

The contract implements several anti-bot and anti-whale mechanisms, including _maxTxAmount, _maxWalletSize, caCount (limiting sells per block), and the isExile mapping. While intended to prevent malicious activity, these features can also be used to intentionally or unintentionally block legitimate user transfers or sales. For example, caCount limits the number of sells per block, which could lead to a denial of service for sellers during periods of high trading volume, preventing them from exiting positions. (7.2 Code Security, 7.3 Access Control)M-01

Issue

The contract implements several anti-bot and anti-whale mechanisms, including _maxTxAmount, _maxWalletSize, caCount (limiting sells per block), and the isExile mapping. While intended to prevent malicious activity, these features can also be used to intentionally or unintentionally block legitimate user transfers or sales. For example, caCount limits the number of sells per block, which could lead to a denial of service for sellers during periods of high trading volume, preventing them from exiting positions. (7.2 Code Security, 7.3 Access Control)

Fix

Carefully review the thresholds and limits for all anti-bot/anti-whale mechanisms. Consider dynamic adjustments or more sophisticated algorithms that differentiate between malicious and legitimate activity. Ensure that these mechanisms do not inadvertently create a denial of service for regular users. Provide clear documentation on how these features operate and their potential impact on trading.

Status

Unresolved

Medium

Reentrancy Risk in sendETHToFee if _taxWallet is a Contract

The sendETHToFee function sends address(this).balance to _taxWallet using a direct call. While _taxWallet is initialized to the owner's address (likely an EOA), the owner has the ability to change _taxWallet to any address. If _taxWallet is changed to a malicious contract, it could re-enter the ETHCAT contract during the call operation. Although the lockTheSwap modifier protects the automated swap logic, sendETHToFee itself performs an external call that could be exploited if the recipient is a reentrant contract, potentially leading to unexpected state changes or fund manipulation. (7.2 Code Security)M-02

Issue

The sendETHToFee function sends address(this).balance to _taxWallet using a direct call. While _taxWallet is initialized to the owner's address (likely an EOA), the owner has the ability to change _taxWallet to any address. If _taxWallet is changed to a malicious contract, it could re-enter the ETHCAT contract during the call operation. Although the lockTheSwap modifier protects the automated swap logic, sendETHToFee itself performs an external call that could be exploited if the recipient is a reentrant contract, potentially leading to unexpected state changes or fund manipulation. (7.2 Code Security)

Fix

Implement a reentrancy guard specifically for the sendETHToFee function, or ensure that _taxWallet can only be set to an EOA. If _taxWallet must be a contract, ensure it is a trusted, audited contract that does not contain reentrancy vulnerabilities. Consider using the Checks-Effects-Interactions pattern more strictly for all external calls.

Status

Unresolved

Low

Lack of Event Emission for Critical Parameter Changes

Several critical parameters, such as _initialBuyTax, _finalBuyTax, _maxTxAmount, _maxWalletSize, _taxSwapThreshold, _maxTaxSwap, caCount, caToggle, swapEnabled, tradingOpen, and _preventSwapBefore can be changed by the owner without emitting corresponding events. This lack of transparency makes it difficult for users, off-chain monitoring systems, and block explorers to track changes to the contract's economic and operational parameters, reducing trust and auditability. (7.8 Operations)L-01

Issue

Several critical parameters, such as _initialBuyTax, _finalBuyTax, _maxTxAmount, _maxWalletSize, _taxSwapThreshold, _maxTaxSwap, caCount, caToggle, swapEnabled, tradingOpen, and _preventSwapBefore can be changed by the owner without emitting corresponding events. This lack of transparency makes it difficult for users, off-chain monitoring systems, and block explorers to track changes to the contract's economic and operational parameters, reducing trust and auditability. (7.8 Operations)

Fix

Emit specific events whenever critical parameters are modified. Each event should include the old and new values of the parameter, along with the address of the caller. This enhances transparency, allows for better monitoring, and improves the overall auditability of the contract's state changes.

Status

Unresolved

Info

Redundant Use of SafeMath with Solidity 0.8.x

The contract uses pragma solidity 0.8.26, which automatically includes built-in overflow and underflow checks for all arithmetic operations. The explicit use of the SafeMath library, while not harmful, is redundant in this Solidity version. It adds unnecessary code complexity and slightly increases gas costs due to additional function calls. (7.2 Code Security)I-01

Issue

The contract uses pragma solidity 0.8.26, which automatically includes built-in overflow and underflow checks for all arithmetic operations. The explicit use of the SafeMath library, while not harmful, is redundant in this Solidity version. It adds unnecessary code complexity and slightly increases gas costs due to additional function calls. (7.2 Code Security)

Fix

Consider removing the SafeMath library and relying on Solidity's native overflow/underflow checks for cleaner and more gas-efficient code. Ensure that all arithmetic operations are thoroughly tested regardless of whether SafeMath is used.

Status

Unresolved

Analysis

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

The ETHCAT token contract implements custom taxation, anti-bot, and anti-whale mechanisms. While these features aim to control token dynamics, the contract exhibits critical functional flaws due to missing helper functions, significant centralization risks, and an economic model where transaction taxes are not used to support liquidity. The owner retains extensive control over critical parameters, posing a substantial risk of manipulation or a rug pull.

Technical6/10Medium risk

The contract utilizes SafeMath for arithmetic operations, which is a positive for preventing integer overflows/underflows, though redundant in Solidity 0.8.x. However, the provided code snippet is critically incomplete, lacking definitions for min and isContract functions, which would prevent compilation or cause runtime errors (7.2 Code Security). The sendETHToFee function, while protected by lockTheSwap during automated swaps, could still be vulnerable to reentrancy if the _taxWallet is set to a malicious contract (7.2 Code Security). Anti-bot and anti-whale mechanisms, such as _maxTxAmount and caCount, introduce potential denial-of-service vectors for legitimate users (7.2 Code Security).

Governance7/10Low risk

The contract is highly centralized, with the owner possessing extensive control over critical parameters such as tax rates, transaction limits, wallet size limits, and the ability to exile addresses (7.3 Access Control). This level of control creates a significant risk of a rug pull or honeypot scenario, where the owner could manipulate taxes or block transfers to their advantage (7.4 Economic). Crucially, the ETH generated from transaction taxes is sent directly to the owner's wallet instead of being used to provide liquidity, undermining sustainable liquidity growth (7.4 Economic). The anti-bot/anti-whale mechanisms, while intended to protect, can also be misused to block legitimate trading (7.4 Economic).

Upgrades9/10Low risk

The ETHCAT contract is a standard, non-upgradeable token implementation. There are no proxy patterns or upgrade mechanisms present, meaning the contract's logic cannot be altered after deployment (7.7 Upgrades). This eliminates upgrade-specific risks but also means any discovered vulnerabilities or desired feature changes would require a new contract deployment and migration.

Final RecommendationWhat to do about this score

Address the critical functional issues by ensuring all called helper functions (min, isContract) are properly defined and implemented.

Re-evaluate the economic model to ensure transparency and sustainability, particularly regarding the use of collected taxes. Implement robust access control mechanisms, potentially introducing multi-signature wallets or time-locks for critical parameter changes. Enhance transparency by emitting events for all significant state changes, allowing users to monitor contract behavior. Thoroughly test all anti-bot and anti-whale features to prevent unintended denial of service for legitimate users.

Contract & Record

1 audit on record
TypeRouter, Token
NetworkEthereum
Token age2y
Contract0x7777…2bc8
Deployer0x8c4c…d393
Badge for your website
Ethereumcat 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, 202614Low
  2. Aug 30, 202615Low

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

Related Audits

6 more on the recordAll audits
ManyuEthereum13LowRektEthereum13LowXEN CryptoXEN · Ethereum13LowEngramEthereum15LowSpaceXSIEthereum15LowWrapped liquid staked Ether 2.0WSTETH · Ethereum12Low

Would You Like a More Detailed Audit of Ethereumcat?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page