Is pepeCoin a Scam? Security Analysis

Security Findings

1 High1 Med1 Low2 Info

High

Locked Ether Due to Renounced Ownership

H-01The `withdraw()` function, which allows the contract owner to retrieve Ether, is protected by the `onlyOwner` modifier. According to the provided prefill data, the contract ownership has been renounced (`ownership_renounced: true`). This means the `_owner` address is set to `address(0)`, making the `onlyOwner` modifier always revert. Consequently, any Ether accidentally or intentionally sent to the contract will be permanently locked and inaccessible.

IssueThe `withdraw()` function, which allows the contract owner to retrieve Ether, is protected by the `onlyOwner` modifier. According to the provided prefill data, the contract ownership has been renounced (`ownership_renounced: true`). This means the `_owner` address is set to `address(0)`, making the `onlyOwner` modifier always revert. Consequently, any Ether accidentally or intentionally sent to the contract will be permanently locked and inaccessible.

FixEnsure that no Ether is sent to this contract. If the contract was intended to hold or manage Ether, a redeployment with a revised withdrawal mechanism (e.g., a multi-signature wallet or a mechanism that allows anyone to trigger a withdrawal to a predefined address) would be necessary before renouncing ownership.

StatusUnresolved

Medium

Centralized Token Distribution

M-01The entire `_totalSupply` of `pepeCoin` is minted to the contract deployer (`msg.sender`) in the constructor. This results in a highly centralized initial token distribution, where one address holds 100% of the token supply. Such centralization can lead to significant market manipulation risks, as the single holder has disproportionate control over the token's liquidity and price.

IssueThe entire `_totalSupply` of `pepeCoin` is minted to the contract deployer (`msg.sender`) in the constructor. This results in a highly centralized initial token distribution, where one address holds 100% of the token supply. Such centralization can lead to significant market manipulation risks, as the single holder has disproportionate control over the token's liquidity and price.

FixFor future projects, consider implementing a more decentralized initial token distribution strategy, such as a fair launch, liquidity bootstrapping pool, or a vesting schedule for team tokens, to promote broader ownership and reduce centralization risks.

StatusUnresolved

Low

Unused `_tokenPrice` Variable

L-01The contract includes a state variable `_tokenPrice` along with `setTokenPrice()` and `getTokenPrice()` functions. However, this `_tokenPrice` variable is not integrated into any core token logic, such as calculating transfer fees, enabling token purchases, or influencing any other economic mechanism within the contract. It serves no functional purpose, and its value is immutable due to renounced ownership.

IssueThe contract includes a state variable `_tokenPrice` along with `setTokenPrice()` and `getTokenPrice()` functions. However, this `_tokenPrice` variable is not integrated into any core token logic, such as calculating transfer fees, enabling token purchases, or influencing any other economic mechanism within the contract. It serves no functional purpose, and its value is immutable due to renounced ownership.

FixRemove the `_tokenPrice` variable and its associated functions (`setTokenPrice`, `getTokenPrice`) if they are not intended to be used for any on-chain logic. This will reduce contract complexity, save gas, and prevent potential confusion for users or external systems that might misinterpret its purpose.

StatusUnresolved

Info

Missing Event for State Change

I-01The `setTokenPrice()` function modifies the `_tokenPrice` state variable but does not emit an event to signal this change. While this function is currently unusable due to renounced ownership, if it were callable, the absence of an event would make it difficult for off-chain applications, block explorers, or monitoring tools to track changes to this parameter.

IssueThe `setTokenPrice()` function modifies the `_tokenPrice` state variable but does not emit an event to signal this change. While this function is currently unusable due to renounced ownership, if it were callable, the absence of an event would make it difficult for off-chain applications, block explorers, or monitoring tools to track changes to this parameter.

FixFor any function that modifies critical state variables, it is a best practice to emit an event. If `setTokenPrice` were to be functional, consider adding an event like `TokenPriceUpdated(uint256 oldPrice, uint256 newPrice)` to improve transparency and off-chain observability.

StatusUnresolved

Info

Lack of Emergency Pause Mechanism

I-02The contract lacks a mechanism to pause critical operations, such as token transfers or burning, in case of an emergency (e.g., discovery of a critical vulnerability, major exploit, or market instability). While not strictly a vulnerability, a pause mechanism is a common security best practice for tokens to provide a temporary emergency stop.

IssueThe contract lacks a mechanism to pause critical operations, such as token transfers or burning, in case of an emergency (e.g., discovery of a critical vulnerability, major exploit, or market instability). While not strictly a vulnerability, a pause mechanism is a common security best practice for tokens to provide a temporary emergency stop.

FixConsider implementing a pause mechanism (e.g., using OpenZeppelin's `Pausable` contract) that can be triggered by a trusted entity (e.g., a multi-signature wallet or a governance contract). This would allow for a temporary halt of operations to address unforeseen issues, although this would require a redeployment given the current contract's non-upgradeable nature and renounced ownership.

StatusUnresolved

Category Ratings

TechnicalLow9/10

The contract leverages battle-tested OpenZeppelin contracts for ERC20 and Ownable functionalities, ensuring standard compliance and robust implementation of core token operations (7.2 Code Security). Arithmetic operations are handled safely using `unchecked` blocks where appropriate, preventing overflow/underflow. However, a significant technical issue arises from the renounced ownership: the `withdraw()` function, being `onlyOwner`, becomes unusable, leading to any Ether sent to the contract being permanently locked (7.3 Access Control, 7.8 Operations). The `_tokenPrice` variable is also present but unused in any core logic.

GovernanceLow9/10

The token features a fixed total supply and a burn mechanism, providing some predictability and deflationary potential. However, the primary economic risk stems from the highly centralized initial token distribution, with 100% of the supply minted to the deployer, creating potential for market manipulation (7.4 Economic). The `_tokenPrice` variable is misleading as it has no functional impact on the token's economics within the contract, and its value is immutable due to renounced ownership (7.5 Governance).

UpgradesLow10/10

The contract is not designed with an upgrade mechanism (e.g., proxy pattern), which inherently eliminates risks associated with upgradeability, such as proxy misconfigurations or malicious upgrade paths (7.7 Upgrades). The trade-off is that any discovered critical bugs or desired feature enhancements cannot be implemented without a complete redeployment and migration, which can be costly and disruptive.

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

38.7% in top 10

27.1% in wallets11.7% in contracts

Effective Concentration31.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

$1.92M across 4 pairs

Uniswap v2WETHanalysed$1.92M 0x460b…eFfEWETH$5.0K SupernovaWETH$109

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 Locked99.2% · Null Address, UNCX

Top-1 Unlocked Holder0.6%

Lock Expiry2092 (verified ≥ 1 year) · UNCX V2

Key Addresses

7 addresses

Deployer

0xcfbe…264f

Unlocked LP Held By

0x0ee7…051e0x16a7…67cc0xf558…2cf40xb3ac…68a00x0000…8a900x1f2f…f387

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

What Raised This Score

4 factors

Top-10 concentration > 30% (38.7% total → 31.7% effective; 27.1% in EOAs, 11.7% in contracts — moderate)
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

Is pepeCoin a Scam?

Security Findings

Locked Ether Due to Renounced Ownership

Centralized Token Distribution

Unused `_tokenPrice` Variable

Missing Event for State Change

Lack of Emergency Pause Mechanism

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of pepeCoin?