Quantum Audit Logo

Is Pepes Dog a Scam?

Honeypot, rug-pull and ownership checks

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

Pepes Dog ZEUS
0x0f7d…ccc8
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The ZEUS token contract implements an ERC-20 standard with taxation and automated liquidity features. However, the provided code is incomplete, critically lacking owner-controlled functions for managing key operational parameters. Furthermore, with ownership renounced, the contract's dynamic features are entirely unmanageable, severely impacting its operability and security posture. The absence of the `sendETHToFee` function also poses a significant risk of collected funds being locked.

1 Critical1 High1 Medium2 Low1 Informational
i Our automated scanner reviewed Pepes Dog (ZEUS) on Ethereum. 5 of 5 security checks passed — see the full breakdown below.
Volume 24h
$1.4K
Liquidity
$198.7K
Price
$0.000000002
Age
1y
Top 10 Holders
45.4%

Security Findings

1 Crit1 High1 Med2 Low1 Info
Critical

Missing Critical Owner Functions and Renounced Ownership

C-01The contract lacks essential `onlyOwner` functions to manage critical parameters such as `_buyTax`, `_sellTax`, `_maxTxAmount`, `_maxWalletSize`, `_taxSwapThreshold`, `_maxTaxSwap`, `enableTransfers`, `swapEnabled`, `uniswapV2Router`, `uniswapV2Pair`, and the `_isExcludedFromFee` list. Given that `ownership_renounced` is true, the `owner()` address is `address(0)`. This means even if these functions were present, they could not be called, rendering the contract's dynamic features completely unmanageable and immutable. This severely limits operational flexibility and makes it impossible to adapt to market conditions or fix misconfigurations, effectively bricking the contract's administrative…
IssueThe contract lacks essential `onlyOwner` functions to manage critical parameters such as `_buyTax`, `_sellTax`, `_maxTxAmount`, `_maxWalletSize`, `_taxSwapThreshold`, `_maxTaxSwap`, `enableTransfers`, `swapEnabled`, `uniswapV2Router`, `uniswapV2Pair`, and the `_isExcludedFromFee` list. Given that `ownership_renounced` is true, the `owner()` address is `address(0)`. This means even if these functions were present, they could not be called, rendering the contract's dynamic features completely unmanageable and immutable. This severely limits operational flexibility and makes it impossible to adapt to market conditions or fix misconfigurations, effectively bricking the contract's administrative…
FixBefore deployment, ensure all necessary administrative functions are implemented with `onlyOwner` access control. These functions should allow the owner to configure and update critical parameters. If ownership is to be renounced, it must only occur after all parameters are correctly set and verified, and the contract is fully operational as intended. For this deployed contract, this issue is unresolvable due to renounced ownership.
StatusUnresolved
High

Centralization Risk in Fee Distribution (Missing `sendETHToFee` Implementation)

H-01The `_transfer` function calls `sendETHToFee(address(this).balance)` after a token swap to distribute collected ETH. However, the implementation of the `sendETHToFee` function is not provided in the contract code. If this function is missing or incorrectly implemented, any ETH collected from token swaps will become permanently stuck in the contract, leading to a loss of funds intended for the dev, marketing, and airdrop wallets.
IssueThe `_transfer` function calls `sendETHToFee(address(this).balance)` after a token swap to distribute collected ETH. However, the implementation of the `sendETHToFee` function is not provided in the contract code. If this function is missing or incorrectly implemented, any ETH collected from token swaps will become permanently stuck in the contract, leading to a loss of funds intended for the dev, marketing, and airdrop wallets.
FixImplement the `sendETHToFee` function to securely transfer collected ETH to the designated fee wallets (`_devWallet`, `_marketingWallet`, `_airdropWallet`). Ensure proper checks and error handling are in place. The function should use `call` with a gas limit to prevent reentrancy issues from recipient contracts.
StatusUnresolved
Medium

Unused State Variables

M-01The state variables `transferDelayEnabled` and `tradingOpen` are declared as public but are never referenced or used within the contract's logic. This indicates either dead code, incomplete feature implementation, or a misunderstanding of the contract's intended functionality, potentially misleading users about its capabilities.
IssueThe state variables `transferDelayEnabled` and `tradingOpen` are declared as public but are never referenced or used within the contract's logic. This indicates either dead code, incomplete feature implementation, or a misunderstanding of the contract's intended functionality, potentially misleading users about its capabilities.
FixRemove unused state variables to reduce contract size and improve clarity. If these variables are intended for future features, ensure they are fully implemented and integrated into the contract's logic, or explicitly mark them as reserved for future use.
StatusUnresolved
Low

Hardcoded and Shared Fee Wallets

L-01The `_marketingWallet` and `_airdropWallet` addresses are hardcoded to the same address (0xBA89…6515). This means funds intended for two potentially distinct purposes (marketing and airdrops) will be directed to a single entity. Additionally, these addresses are hardcoded and cannot be changed post-deployment, limiting flexibility for future operational adjustments.
IssueThe `_marketingWallet` and `_airdropWallet` addresses are hardcoded to the same address (). This means funds intended for two potentially distinct purposes (marketing and airdrops) will be directed to a single entity. Additionally, these addresses are hardcoded and cannot be changed post-deployment, limiting flexibility for future operational adjustments.
FixIf marketing and airdrop funds are intended for separate management, use distinct wallet addresses. Consider implementing `onlyOwner` functions to allow the owner to update these wallet addresses, providing greater flexibility and adaptability for long-term project management.
StatusUnresolved
Low

Complex Tax Logic in `_transfer`

L-02The `_transfer` function contains multiple nested `if` conditions for calculating `taxAmount` and applying exclusions. While the logic appears to correctly handle tax exemptions for excluded addresses and internal transfers, the complexity increases the cognitive load and potential for subtle bugs or unexpected behavior during future modifications or audits.
IssueThe `_transfer` function contains multiple nested `if` conditions for calculating `taxAmount` and applying exclusions. While the logic appears to correctly handle tax exemptions for excluded addresses and internal transfers, the complexity increases the cognitive load and potential for subtle bugs or unexpected behavior during future modifications or audits.
FixRefactor the tax calculation logic to improve readability and maintainability. Consider using a helper function or a more structured approach to determine the final `taxAmount` based on transfer conditions and exclusion status. Thoroughly test all tax scenarios to ensure correct behavior.
StatusUnresolved
Info

Unnecessary `unicode` Prefix for String Literals

I-01The `_name` and `_symbol` string literals use the `unicode` prefix (e.g., `unicode"Pepes Dog"`). This prefix is typically used for strings containing non-ASCII characters. For standard ASCII strings, the `unicode` prefix is unnecessary and can be omitted without affecting functionality.
IssueThe `_name` and `_symbol` string literals use the `unicode` prefix (e.g., `unicode"Pepes Dog"`). This prefix is typically used for strings containing non-ASCII characters. For standard ASCII strings, the `unicode` prefix is unnecessary and can be omitted without affecting functionality.
FixRemove the `unicode` prefix from string literals that only contain ASCII characters to adhere to common Solidity coding practices and slightly reduce bytecode size.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract utilizes `SafeMath` for arithmetic safety and includes a `lockTheSwap` modifier to prevent reentrancy during liquidity operations (7.2 Code Security). However, the provided code is severely incomplete, missing critical `onlyOwner` functions to configure essential parameters like taxes, transaction limits, and the Uniswap router/pair (7.3 Access Control). The absence of the `sendETHToFee` function also creates a high risk of collected ETH becoming permanently inaccessible (7.2 Code Security, 7.8 Operations). Additionally, some state variables are declared but unused, indicating incomplete development (7.2 Code Security).

GovernanceLow7/10

The tokenomics include high buy (23%) and sell (25%) taxes, along with max transaction and wallet size limits, which are common anti-whale mechanisms (7.4 Economic). However, the inability to modify these parameters post-deployment due to missing owner functions, compounded by renounced ownership, presents a critical governance and economic risk (7.5 Governance). The `_marketingWallet` and `_airdropWallet` are hardcoded to the same address, limiting flexibility and transparency for fund allocation (7.4 Economic, 7.8 Operations).

UpgradesLow9/10

The contract is not designed with an upgrade mechanism (e.g., proxy pattern), meaning its logic is immutable once deployed (7.7 Upgrades). This eliminates upgrade-related risks but also means any identified vulnerabilities or necessary feature changes cannot be addressed without a new deployment.

Security Checklist

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

Holder Composition

45.4% in top 10
20.5% in wallets24.9% in contracts
Effective Concentration30.4%

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

$200.2K across 2 pairs
Uniswap v2WETHanalysed$198.7K99.3%Uniswap v4ETH$1.4K0.7%

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
0xba89…6515
Unlocked LP Held By
0x4ab8…c4f00xc143…17c3

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

What Raised This Score

5 factors
  • Top-10 concentration > 30% (45.4% total → 30.4% effective; 20.5% in EOAs, 24.9% in contracts — moderate)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 2 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
Asteroid Shiba (ASTEROID)Low RiskEthereumcat (ETHCAT)Low RiskTsutsuji the Cate (CATE)Medium RiskManyuLow RiskRektLow RiskXEN Crypto (XEN)Low Risk

Would You Like a More Detailed Audit of Pepes Dog?

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

Get Detailed Audit