Quantum Audit Logo

Is Clawd Safe?

On-chain security analysis — is it a scam or legit?

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

Clawd CLAWD
0x29bb…1bcd
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 18d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

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.

1 Critical1 High1 Medium1 Low1 Informational
Volume 24h
$4.8K
Liquidity
$20.4K
Price
$0.00006962
Token Age
1mo
Top 10 Holders
41.7%

Security Findings

1 Crit1 High1 Med1 Low1 Info
Critical

Extreme Centralization and Potential Honeypot Vector

C-01The 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.
IssueThe 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.
FixImplement 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.
StatusUnresolved
High

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

H-01The 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.
IssueThe 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.
FixAdd 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.
StatusUnresolved
Medium

Complex and Potentially Ambiguous Tax Logic

M-01The `_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.
IssueThe `_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.
FixRefactor 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.
StatusUnresolved
Low

Lack of Event Emission for Critical State Changes

L-01The 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.
IssueThe 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.
FixEnsure 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.
StatusUnresolved
Info

Unused State Variables

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

Category Ratings

TechnicalLow7/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 `fallback()` function means any ETH sent directly to the contract will be permanently locked. The tax calculation logic within the `_transfer` function is overly complex, increasing the risk of subtle bugs or misinterpretation. 7.3 Access Control: The `Ownable` pattern is used, granting the owner extensive control over critical parameters. 7.6 External: Integration with Uniswap V2 is standard.

GovernanceLow7/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 trading, and blacklist addresses via the `bots` mapping. This high degree of centralization presents a significant economic risk, as the owner could potentially manipulate trading conditions (e.g., setting high sell taxes) to the detriment of users, creating a honeypot scenario. 7.8 Operations: Operational control is entirely centralized with the owner, requiring a high degree of trust.

UpgradesLow9/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.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

41.7% in top 10
21.1% in wallets20.6% in contracts
Effective Concentration29.3%

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

$20.4K

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

1 addresses
Deployer
0xebc6…2fab

What Raised This Score

6 factors
  • Top-10 concentration > 20% (41.7% total → 29.3% effective; 21.1% in EOAs, 20.6% in contracts — mild)
  • Liquidity < $50k ($20,436 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

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.

Related Audits

6 more on the record
Kekius Maximus (KEKIUS)Medium RiskFuseMedium RiskSPECTRE AI (SPECTRE)Medium RiskShiba Inu (SHIB)Medium RiskGrand Theft Auto VI (GTAVI)Medium RiskUnipeg (UPEG)Medium Risk

Would You Like a More Detailed Audit of Clawd?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit