Quantum Audit Logo

Is Ethereumcat a Scam?

Honeypot, rug-pull and ownership checks

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

Ethereumcat ETHCAT
0x7777…2bc8
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

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.

1 Critical2 High2 Medium1 Low1 Informational
i Our automated scanner reviewed Ethereumcat (ETHCAT) on Ethereum. 5 of 5 security checks passed — see the full breakdown below.
Volume 24h
$187.0K
Liquidity
$85.2K
Price
$0.0005435
Age
2y
Top 10 Holders
31.6%

Security Findings

1 Crit2 High2 Med1 Low1 Info
Critical

Missing Critical Helper Functions (`min`, `isContract`)

C-01The `_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.
IssueThe `_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.
FixDefine 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`.
StatusUnresolved
High

Centralized Control and Potential for Rug Pull/Honeypot

H-01The 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)
IssueThe 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)
FixConsider 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.
StatusUnresolved
High

Taxed ETH Not Used for Liquidity Provision

H-02The 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)
IssueThe 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)
FixIf 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.
StatusUnresolved
Medium

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

M-01The 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)
IssueThe 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)
FixCarefully 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.
StatusUnresolved
Medium

Reentrancy Risk in `sendETHToFee` if `_taxWallet` is a Contract

M-02The `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)
IssueThe `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)
FixImplement 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.
StatusUnresolved
Low

Lack of Event Emission for Critical Parameter Changes

L-01Several 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)
IssueSeveral 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)
FixEmit 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.
StatusUnresolved
Info

Redundant Use of SafeMath with Solidity 0.8.x

I-01The 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)
IssueThe 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)
FixConsider 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.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

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

GovernanceLow7/10

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

UpgradesLow9/10

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.

Security Checklist

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

Holder Composition

31.6% in top 10
3.5% in wallets28.1% in contracts
Effective Concentration14.7%

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

$88.7K across 2 pairs
Uniswap v2WETHanalysed$85.2K96.0%Uniswap v4USDC$3.6K4.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

LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

3 addresses
Deployer
0x8c4c…d393
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.

What Raised This Score

4 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

Related Audits

6 more on the record
ManyuLow RiskRektLow RiskXEN Crypto (XEN)Low RiskWrapped liquid staked Ether 2.0 (WSTETH)Low RiskHEXLow RiskPepes Dog (ZEUS)Low Risk

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