Honeypot, rug-pull and ownership checks

Is Pepes Dog a Scam?

ZEUS

Ethereum

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

18/ 100

Low RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical7/10 Governance7/10 Upgrades9/10 Checks passed5 of 5 Findings1 Critical · 1 High · 1 Medium · 2 Low · 1 Info6

SummaryAI Copilot

The ZEUS token contract implements an ERC-20 standard with taxation and automated liquidity features.

Read the full analysis

What raised the score

Top-10 concentration > 30%
1 Critical finding(s) from audit
1 High finding(s) from audit
1 Medium finding(s) from audit
2 Low finding(s) from audit

Exact 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

Our automated scanner reviewed Pepes Dog (ZEUS) on Ethereum. 5 of 5 security checks passed — see the full breakdown below.

Security Checklist

as of audit · Sep 45 of 5 checks passed

Contract verifiedVerified

OwnershipRenounced

MintNo mint

Liquidity lockLocked

UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

45.4%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking24.9%
Walletsanonymous holders, free to sell20.5%
Everyone elsethe rest of the supply54.6%

Effective concentrationwhat the score reads30.4%

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$200.2K 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$198.7KShare of depth99.3%

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

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.

Security Findings

1 Critical1 High1 Medium2 Low1 Info

Critical

Missing Critical Owner Functions and Renounced Ownership

The 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…C-01

Issue

Fix

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

Status

Unresolved

High

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

The _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.H-01

Issue

Fix

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

Status

Unresolved

Medium

Unused State Variables

The 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.M-01

Issue

Fix

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

Status

Unresolved

Low

Hardcoded and Shared Fee Wallets

The _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.L-01

Issue

The _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.

Fix

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

Status

Unresolved

Low

Complex Tax Logic in `_transfer`

The _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.L-02

Issue

Fix

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

Status

Unresolved

Info

Unnecessary `unicode` Prefix for String Literals

The _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.I-01

Issue

Fix

Remove the unicode prefix from string literals that only contain ASCII characters to adhere to common Solidity coding practices and slightly reduce bytecode size.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

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.

Technical7/10Low risk

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

Governance7/10Low risk

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

Upgrades9/10Low risk

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.

Final RecommendationWhat to do about this score

It is strongly recommended to complete the contract code by implementing all missing owner-controlled functions for critical parameters such as taxes, transaction limits, transfer enablement, and Uniswap router/pair configuration.

The sendETHToFee function must be fully implemented and thoroughly audited to ensure proper distribution of collected ETH and prevent funds from being locked. Given that ownership has been renounced, any missing administrative functions cannot be called, rendering the contract unmanageable. Future deployments should ensure all necessary administrative functions are present and tested before renouncing ownership.

Contract & Record

1 audit on record

TypeRouter, Token

NetworkEthereum

Token age1y

Contract0x0f7d…ccc8

Deployer0xba89…6515

Badge for your website

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

Sep 4, 202618Low
Aug 11, 202613Low

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

Frequently Asked Questions

What is the ZEUS contract address?

The Pepes Dog (ZEUS) contract on Ethereum is 0x0f7dc5d02cc1e1f5ee47854d534d332a1081ccc8. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.