Is Clawd Safe? Smart Contract Security Analysis

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Audit History

1 audit on record

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

The Clawd token contract implements a standard ERC-20 token with advanced tax, anti-bot, and automated liquidity features. While it incorporates some security best practices like SafeMath and reentrancy guards, it exhibits significant centralization risks due to extensive owner privileges. Critical issues include the potential for honeypot scenarios and the risk of permanently locking accidentally sent ETH. The complexity of the tax logic also introduces potential for unintended behavior.

Final Recommendation: To mitigate the identified risks, it is strongly recommended to implement a timelock for all sensitive owner-controlled functions, or transfer ownership to a multi-signature wallet, to reduce centralization and prevent malicious or accidental actions. A `receive()` or `fallback()` function should be added to prevent ETH from being permanently locked if sent directly to the contract. The tax calculation logic should be simplified and thoroughly documented to enhance clarity and reduce the potential for errors. Additionally, ensure all critical state changes emit appropriate events for transparency and off-chain monitoring.

Category Ratings

TechnicalLow

7/10

7.1 Architecture: The contract follows a standard ERC-20 token architecture with added tax and anti-bot mechanisms. 7.2 Code Security: It utilizes SafeMath for arithmetic operations and a `lockTheSwap` modifier to prevent reentrancy during liquidity swaps. However, the absence of a `receive()` or `f

GovernanceMedium

6/10

7.4 Economic: The token's economic model includes dynamic buy/sell taxes, max transaction limits, and anti-whale measures. These features are highly configurable by the owner. 7.5 Governance: The owner possesses extensive control, including the ability to modify all tax rates, enable/disable tr

UpgradesLow

9/10

7.7 Upgrades: The contract is not designed with upgradeability in mind, meaning its logic is immutable once deployed. This eliminates risks associated with proxy patterns or upgrade mechanisms, ensuring the current implementation remains fixed. There are no upgrade-specific vulnerabilities.

LP Distribution

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

What Raised This Score

6 factors

Top-10 concentration > 30% (50.6% total → 33.0% effective; 21.2% in EOAs, 29.3% in contracts — moderate)
Liquidity < $50k ($10,225 across 1 pairs — thin market)
1 Critical finding(s) from audit
1 High finding(s) from audit
1 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 Findings

5 total

1 Critical 1 High 1 Medium 1 Low 1 Info

C-01CriticalUnresolved

Extreme Centralization and Potential Honeypot Vector

The contract owner possesses extensive control over critical parameters and functionalities, including the ability to: set all tax rates (buy, sell, transfer), enable/disable trading, enable/disable automatic liquidity swaps, set max transaction and wallet size limits, and add/remove addresses from the `bots` mapping (effectively blacklisting them). This level of control allows the owner to manipulate trading conditions, potentially creating a honeypot scenario where users can buy but are prevented from selling (e.g., by setting sell tax to 100% or blacklisting specific addresses). This poses a severe risk to user funds and trust in the protocol.

Recommendation: Implement a timelock for all sensitive owner-controlled functions (e.g., setting taxes, modifying trading status, updating bot list) to introduce a delay before changes take effect. Consider transferring ownership to a multi-signature wallet to distribute control and require consensus for critical operations. Clearly communicate the extent of owner privileges to users.

H-01HighUnresolved

Missing `receive()` or `fallback()` Function - Stuck ETH

The contract does not implement a `receive()` or `fallback()` payable function. This means that if any Ether is sent directly to the contract address without calling a specific payable function (e.g., `addLiquidityETH`), it will be permanently locked within the contract and become irrecoverable. While the contract is designed to handle ETH through specific functions, accidental direct transfers are a common occurrence.

Recommendation: Add a `receive() external payable {}` function to the contract to allow it to accept direct Ether transfers. If direct ETH transfers are not intended, consider adding a `fallback() external payable { revert("ETH not accepted"); }` to explicitly prevent them and inform users.

M-01MediumUnresolved

Complex and Potentially Ambiguous Tax Logic

The `_transfer` function contains multiple conditional blocks for calculating `taxAmount` based on `_buyCount`, `from`, and `to` addresses. The interaction between the general `if(_buyCount==0)` / `if(_buyCount>0)` blocks and the specific `if (from == uniswapV2Pair)` (buy) / `if(to == uniswapV2Pair)` (sell) blocks is complex and could lead to unintended tax applications or make the logic difficult to reason about. For instance, the `_buyCount==0` and `_buyCount>0` conditions might be overridden by the buy/sell specific conditions, leading to confusion.

Recommendation: Refactor the `_transfer` function's tax calculation logic to be clearer and more modular. Use a single, well-defined flow for determining the applicable tax based on the transaction type (buy, sell, general transfer). Add comprehensive inline comments and external documentation to explain the exact tax application rules under different scenarios.

L-01LowUnresolved

Lack of Event Emission for Critical State Changes

The contract defines events such as `MaxTxAmountUpdated` and `TransferTaxUpdated`, but these events are not emitted when the corresponding state variables (`_maxTxAmount`, `_transferTax`) are modified by the owner. This lack of event emission hinders off-chain monitoring, transparency, and the ability for external applications or users to track critical changes to the token's parameters.

Recommendation: Ensure that all functions that modify critical state variables (e.g., `setMaxTxAmount`, `setTransferTax`, `setInitialBuyTax`, `setFinalBuyTax`, etc.) emit appropriate events to signal these changes. This improves transparency and allows for better off-chain tracking and auditing.

I-01InformationalUnresolved

Unused State Variables

The state variables `sellCount` and `lastSellBlock` are declared within the contract but are not utilized anywhere in the provided source code. This suggests either incomplete functionality, vestigial code from a previous iteration, or a potential oversight.

Recommendation: Review the purpose of `sellCount` and `lastSellBlock`. If they are intended for future functionality, ensure they are properly implemented. If they are no longer needed, remove them to reduce contract size and improve code clarity.

Frequently Asked Questions

Is Clawd a scam?

Based on the provided security data, Clawd (CLAWD) exhibits several characteristics that mitigate common scam patterns. The contract is verified, ownership is renounced, and no mint function exists, preventing arbitrary token creation or owner control. Liquidity is locked, mitigating rug pull risks. These factors contribute to its assessed low-risk profile (0/100), indicating a reduced likelihood of a technical scam via contract manipulation. However, due diligence beyond technical aspects is always recommended.

Is Clawd safe to buy?

While Clawd (CLAWD) presents a low technical risk score (0/100) due to its verified contract, renounced ownership, absence of a mint function, and locked liquidity, no investment is entirely without risk. Key factors to consider include the top 10 holders controlling 36.2% of the supply, which could lead to market volatility if large positions are moved. Furthermore, the relatively low liquidity ($26,326) compared to daily volume ($116,947) suggests potential for price impact on larger trades. Investors should conduct their own research.

Has Clawd been audited?

The provided data confirms that the Clawd (CLAWD) contract is verified on the Ethereum blockchain. Contract verification means its source code is publicly available and matches the deployed bytecode, allowing anyone to inspect it. However, verification is distinct from a formal security audit by a specialized third-party firm, which involves a deeper, expert review for vulnerabilities, logical flaws, and potential attack vectors.

Is Clawd Safe? CLAWD