Quantum Audit Logo

Is Pepe a Scam?

Honeypot, rug-pull and ownership checks

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

Pepe PEPE
0x25d8…bb00
BNB Chain
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 10d ago 1 audit on record
Executive SummaryAI Copilot

The PepeToken contract is an Omnichain Fungible Token (OFT) implementation utilizing LayerZero Labs' OFTWithFee standard. The contract itself is minimal, primarily inheriting functionality from well-established and audited LayerZero libraries and OpenZeppelin's Ownable. The primary security considerations stem from the inherent centralization of control granted to the contract owner (a 5/8 multisig) over critical cross-chain parameters and the reliance on the external LayerZero endpoint. While the code quality is high and standard patterns are followed, the extensive administrative privileges introduce significant governance and economic risks.

1 High1 Medium1 Low2 Informational
i Our automated scanner reviewed Pepe (PEPE) on BNB Chain. 2 of 5 security checks passed — see the full breakdown below.
Volume 24h
$176.6K
Liquidity
$275.4K
Price
$0.0000034
Age
3y
Top 10 Holders
21.8%

Security Findings

High

Centralized Control Over Critical Cross-Chain Parameters

H-01The contract owner (a 5/8 multisig) possesses extensive control over critical LayerZero configurations and token transfer parameters. Functions such as `setTrustedRemote`, `setTrustedRemoteAddress`, `setFeeBP`, `setFeeWallet`, `setMinDstGas`, `setPrecrime`, and various LayerZero endpoint configurations (`setConfig`, `setSendVersion`, `setReceiveVersion`, `forceResumeReceive`) are exclusively callable by the owner. A compromise of the multisig or a malicious owner could lead to severe consequences, including redirecting cross-chain token transfers to attacker-controlled addresses, setting exorbitant fees, or blocking legitimate transactions.
IssueThe contract owner (a 5/8 multisig) possesses extensive control over critical LayerZero configurations and token transfer parameters. Functions such as `setTrustedRemote`, `setTrustedRemoteAddress`, `setFeeBP`, `setFeeWallet`, `setMinDstGas`, `setPrecrime`, and various LayerZero endpoint configurations (`setConfig`, `setSendVersion`, `setReceiveVersion`, `forceResumeReceive`) are exclusively callable by the owner. A compromise of the multisig or a malicious owner could lead to severe consequences, including redirecting cross-chain token transfers to attacker-controlled addresses, setting exorbitant fees, or blocking legitimate transactions.
FixWhile the use of a multisig mitigates single-point-of-failure, the broad scope of owner privileges remains a significant centralization risk. Implement robust operational security for the multisig, including strict key management, multi-factor authentication, and thorough review processes for all administrative transactions. Consider exploring decentralized governance mechanisms or time-locks for highly sensitive parameter changes in future iterations, if feasible within the LayerZero framework.
StatusUnresolved
Medium

Reliance on External LayerZero Endpoint Security

M-01The PepeToken contract, as an OFT, is fundamentally dependent on the security, availability, and correct functioning of the LayerZero endpoint (`lzEndpoint`). All cross-chain communication and token transfers rely on this external infrastructure (7.6 External). Any vulnerabilities, compromises, or operational issues within the LayerZero endpoint itself could directly impact the integrity and functionality of the PepeToken's cross-chain capabilities, potentially leading to loss of funds or denial of service for users.
IssueThe PepeToken contract, as an OFT, is fundamentally dependent on the security, availability, and correct functioning of the LayerZero endpoint (`lzEndpoint`). All cross-chain communication and token transfers rely on this external infrastructure (7.6 External). Any vulnerabilities, compromises, or operational issues within the LayerZero endpoint itself could directly impact the integrity and functionality of the PepeToken's cross-chain capabilities, potentially leading to loss of funds or denial of service for users.
FixWhile direct control over the LayerZero endpoint is not possible, it is crucial to monitor LayerZero's official security announcements, audits, and operational status. Maintain a robust incident response plan for scenarios involving LayerZero endpoint disruptions or compromises. Users should be aware of the inherent risks associated with relying on external bridging infrastructure.
StatusUnresolved
Low

Potential for Misconfiguration of LayerZero Parameters

L-01The owner has the ability to configure various LayerZero-specific parameters, such as `minDstGas` and `trustedRemote` addresses. Incorrectly setting these parameters, for example, by providing an insufficient `minDstGas` value, could lead to failed cross-chain transactions and wasted gas. Similarly, an incorrect `trustedRemote` address could result in tokens being bridged to an unintended or non-existent contract on a destination chain, leading to irrecoverable loss of funds.
IssueThe owner has the ability to configure various LayerZero-specific parameters, such as `minDstGas` and `trustedRemote` addresses. Incorrectly setting these parameters, for example, by providing an insufficient `minDstGas` value, could lead to failed cross-chain transactions and wasted gas. Similarly, an incorrect `trustedRemote` address could result in tokens being bridged to an unintended or non-existent contract on a destination chain, leading to irrecoverable loss of funds.
FixEstablish clear, documented procedures for setting and updating all LayerZero-related parameters. Implement a rigorous testing and verification process for any new configurations before deploying them to production. Ensure that `trustedRemote` addresses are double-checked against official LayerZero documentation or known deployments. Consider implementing off-chain monitoring to alert if `minDstGas` values are set too low or too high relative to typical transaction costs.
StatusUnresolved
Info

No Upgradeability Mechanism

I-01The PepeToken contract is deployed directly and does not utilize a proxy pattern (e.g., UUPS, Transparent) for upgradeability (7.7 Upgrades). This means that the contract's logic is immutable after deployment. While this eliminates risks associated with upgrade mechanisms themselves, it implies that any future bug fixes, feature enhancements, or protocol changes would necessitate deploying an entirely new contract and migrating all existing tokens, which can be a complex and disruptive process for users and the ecosystem.
IssueThe PepeToken contract is deployed directly and does not utilize a proxy pattern (e.g., UUPS, Transparent) for upgradeability (7.7 Upgrades). This means that the contract's logic is immutable after deployment. While this eliminates risks associated with upgrade mechanisms themselves, it implies that any future bug fixes, feature enhancements, or protocol changes would necessitate deploying an entirely new contract and migrating all existing tokens, which can be a complex and disruptive process for users and the ecosystem.
FixThis is a design choice. If future upgradeability is desired, consider implementing a proxy pattern for new deployments. For the current contract, acknowledge the immutability and plan for potential migration strategies if significant changes become necessary.
StatusUnresolved
Info

Reliance on Third-Party LayerZero Libraries

I-02The PepeToken contract heavily relies on external, third-party libraries from LayerZero Labs (e.g., `OFTWithFee`, `LzApp`) and OpenZeppelin (`Ownable`). The security and correctness of the entire system are contingent upon the integrity and absence of vulnerabilities within these imported contracts. While these libraries are generally well-audited and widely used, any undiscovered vulnerabilities in them could directly impact the PepeToken contract.
IssueThe PepeToken contract heavily relies on external, third-party libraries from LayerZero Labs (e.g., `OFTWithFee`, `LzApp`) and OpenZeppelin (`Ownable`). The security and correctness of the entire system are contingent upon the integrity and absence of vulnerabilities within these imported contracts. While these libraries are generally well-audited and widely used, any undiscovered vulnerabilities in them could directly impact the PepeToken contract.
FixRegularly review security advisories and updates from LayerZero Labs and OpenZeppelin. Ensure that the deployed versions of these libraries are the most secure and up-to-date. While direct auditing of these extensive libraries is beyond the scope of this report, staying informed about their security posture is crucial.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The technical architecture (7.1 Architecture) is sound, leveraging the standard LayerZero OFT pattern for cross-chain token transfers. The code (7.2 Code Security) is minimal and primarily relies on battle-tested LayerZero Labs and OpenZeppelin libraries, which generally exhibit high code quality. No direct reentrancy, integer overflow/underflow, or other common EVM vulnerabilities were identified within the custom logic. The contract correctly implements the `Ownable` pattern for administrative functions (7.3 Access Control).

GovernanceMedium4/10

The contract's owner (a 5/8 multisig) holds significant centralized control over critical parameters (7.5 Governance). This includes the ability to set trusted remote addresses for cross-chain communication, configure LayerZero endpoint versions, set minimum destination gas limits, and define transfer fees and the fee wallet (7.4 Economic). A compromise of the multisig or a malicious owner could lead to severe consequences, such as redirecting funds, blocking cross-chain transfers, or manipulating fees. The `setPrecrime` function also grants the owner the ability to designate an address that can potentially block messages, which is a powerful control.

UpgradesMedium4/10

The PepeToken contract is not designed as an upgradeable proxy (7.7 Upgrades). This means that its logic cannot be modified after deployment. While this eliminates risks associated with upgrade mechanisms (e.g., proxy misconfigurations, logic bugs in upgradeable contracts), any future changes or bug fixes would require deploying a new contract and migrating tokens, which can be a complex and disruptive process.

Security Checklist

Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

8.8% in wallets13.0% in contracts
Effective Concentration14.0%

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

Show 4 more pairsShow less

The 14 remaining pairs hold $548 between them and are not listed.

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

Top-1 Unlocked Holder81.0%
Top-3 Unlocked88.1%

Key Addresses

Deployer
0x58e0…2adc
Unlocked LP Held By
0x556b…d59e0xaaf2…a6010x5c71…39c90x467b…71320xbc7a…3e710x5574…9a450x4df4…92eb0x8fc1…af4b0xe348…dd090x8da0…846d

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

What Raised This Score

  • Ownership NOT renounced — strong Multisig (5-of-8)
  • Mintable supply — no cap found, dilution unbounded
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 81.0% (independent LP — depth risk, pool = 79% of DEX liquidity)
  • LP top3 unlocked holders = 88.1% (independent LP — depth risk, pool = 79% of DEX liquidity)
  • 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

Related Audits

CRYSTAL STONESHigh RiskEthereum Token (ETH)High RiskUSELESS COIN (USELESS)High RiskBSquared Token (B2)High RiskBrokHigh Risko1.exchange (O)High Risk

Would You Like a More Detailed Audit of Pepe?

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

Get Detailed Audit