Quantum Audit Logo

Is Pepe a Scam?

Honeypot, rug-pull and ownership checks

Pepe PEPE
0x25d8…bb00
Arbitrum
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.
Last checked today 1 audit on record
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The PepeToken contract is an Omnichain Fungible Token (OFT) built on LayerZero, inheriting from OFTWithFee and LzApp. It enables cross-chain token transfers. The contract leverages the LayerZero protocol for its core messaging and security. While the architecture is standard for LayerZero applications and benefits from a multisig owner, significant control over critical bridge parameters remains centralized. The contract's security is highly dependent on the LayerZero protocol itself and the correct configuration of trusted remotes. The full source code for the inherited OFTWithFee contract was not provided for a comprehensive review of token-specific logic.

1 High1 Medium1 Low2 Informational
i Our automated scanner reviewed Pepe (PEPE) on Arbitrum. 2 of 5 security checks passed — see the full breakdown below.
Volume 24h
$40.4K
Liquidity
$47.7K
Price
$0.000004986
Age
3y
Top 10 Holders
22.2%

Security Findings

High

Centralized Control Over Critical LayerZero Parameters

H-01The `onlyOwner` modifier protects critical functions such as `setTrustedRemote`, `setTrustedRemoteAddress`, `setMinDstGas`, `setPrecrime`, and LayerZero configuration settings. While the owner is a multisig (5/8), this still represents a significant centralization of power. A compromised owner key (or enough keys in the multisig) could misconfigure the bridge, leading to funds being sent to incorrect addresses, denial of service, or even spoofing of messages from untrusted sources if `trustedRemoteLookup` is set maliciously. This directly impacts 7.3 Access Control, 7.6 External, and 7.8 Operations.
IssueThe `onlyOwner` modifier protects critical functions such as `setTrustedRemote`, `setTrustedRemoteAddress`, `setMinDstGas`, `setPrecrime`, and LayerZero configuration settings. While the owner is a multisig (5/8), this still represents a significant centralization of power. A compromised owner key (or enough keys in the multisig) could misconfigure the bridge, leading to funds being sent to incorrect addresses, denial of service, or even spoofing of messages from untrusted sources if `trustedRemoteLookup` is set maliciously. This directly impacts 7.3 Access Control, 7.6 External, and 7.8 Operations.
FixEnsure the multisig owner's operational security is of the highest standard. Consider exploring decentralized governance mechanisms for critical parameter changes in the future, or implement time-locks for highly sensitive operations to provide a window for community review or emergency intervention.
StatusUnresolved
Medium

Dependency on LayerZero Protocol Security

M-01The `PepeToken` contract relies entirely on the security and correct functioning of the LayerZero protocol and its endpoint. Any vulnerabilities or exploits within the LayerZero infrastructure itself (e.g., issues with message delivery, endpoint security, or oracle mechanisms used by LayerZero) could directly impact the security and integrity of the `PepeToken` and its cross-chain transfers. This is an inherent external risk (7.6 External).
IssueThe `PepeToken` contract relies entirely on the security and correct functioning of the LayerZero protocol and its endpoint. Any vulnerabilities or exploits within the LayerZero infrastructure itself (e.g., issues with message delivery, endpoint security, or oracle mechanisms used by LayerZero) could directly impact the security and integrity of the `PepeToken` and its cross-chain transfers. This is an inherent external risk (7.6 External).
FixMonitor LayerZero security announcements and audits closely. Maintain a robust incident response plan that accounts for potential LayerZero-level vulnerabilities. While this is an external dependency, understanding its risks is crucial for the overall security posture.
StatusUnresolved
Low

Lack of Emergency Pause/Circuit Breaker for Token Transfers

L-01While `LzApp` has a `precrime` address and `forceResumeReceive` for LayerZero messaging, there isn't a direct mechanism within the `PepeToken` or `OFTWithFee` (as far as visible) to pause or halt token transfers or cross-chain operations in an emergency (e.g., if a major vulnerability is discovered in the token logic or LayerZero). This could lead to continued exploitation during an incident, impacting 7.2 Code Security and 7.8 Operations.
IssueWhile `LzApp` has a `precrime` address and `forceResumeReceive` for LayerZero messaging, there isn't a direct mechanism within the `PepeToken` or `OFTWithFee` (as far as visible) to pause or halt token transfers or cross-chain operations in an emergency (e.g., if a major vulnerability is discovered in the token logic or LayerZero). This could lead to continued exploitation during an incident, impacting 7.2 Code Security and 7.8 Operations.
FixConsider implementing a pause mechanism (e.g., using OpenZeppelin's `Pausable` contract) within the `OFTWithFee` contract that can halt token transfers and cross-chain sends. This would provide a critical circuit breaker for emergency situations, controlled by the multisig owner.
StatusUnresolved
Info

Incomplete OFTWithFee Implementation for Audit

I-01The provided code snippet for `PepeToken` imports `OFTWithFee` but does not include its source. This prevents a full security analysis of the token's core logic, including its fee mechanism, token transfer functions, and how it implements `_blockingLzReceive`. Potential vulnerabilities related to token handling, fee calculation, or reentrancy in `OFTWithFee` cannot be assessed. This impacts 7.1 Architecture, 7.2 Code Security, and 7.4 Economic.
IssueThe provided code snippet for `PepeToken` imports `OFTWithFee` but does not include its source. This prevents a full security analysis of the token's core logic, including its fee mechanism, token transfer functions, and how it implements `_blockingLzReceive`. Potential vulnerabilities related to token handling, fee calculation, or reentrancy in `OFTWithFee` cannot be assessed. This impacts 7.1 Architecture, 7.2 Code Security, and 7.4 Economic.
FixFor a comprehensive audit, provide the full source code of all inherited contracts, especially `OFTWithFee`, to allow for a complete security assessment of the token's core functionality.
StatusUnresolved
Info

Immutable LayerZero Endpoint Address

I-02The `lzEndpoint` address is set as `immutable` in the constructor. While this is standard practice for LayerZero applications, it means the endpoint address cannot be changed post-deployment. If LayerZero were to upgrade its endpoint contract or if a critical vulnerability required a new endpoint deployment, the `PepeToken` contract would need to be redeployed to point to the new address, incurring significant operational overhead and requiring token migration. This impacts 7.1 Architecture and 7.8 Operations.
IssueThe `lzEndpoint` address is set as `immutable` in the constructor. While this is standard practice for LayerZero applications, it means the endpoint address cannot be changed post-deployment. If LayerZero were to upgrade its endpoint contract or if a critical vulnerability required a new endpoint deployment, the `PepeToken` contract would need to be redeployed to point to the new address, incurring significant operational overhead and requiring token migration. This impacts 7.1 Architecture and 7.8 Operations.
FixAcknowledge this design constraint. While not a direct vulnerability, it's important to understand the implications for future upgrades or changes to the LayerZero infrastructure. Plan for potential token migration scenarios in the long term.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract leverages the well-audited LayerZero `LzApp` framework, providing robust cross-chain messaging capabilities with built-in security features like `trustedRemoteLookup` for source verification (7.1 Architecture). The use of `Ownable` for critical configuration functions ensures that only authorized entities can modify bridge parameters (7.3 Access Control). However, the contract's security is highly dependent on the LayerZero endpoint's integrity and the correct configuration of `trustedRemote` addresses (7.6 External). The absence of the `OFTWithFee` source code prevents a full assessment of token-specific logic and potential reentrancy vectors (7.2 Code Security).

GovernanceMedium6/10

The ownership is managed by a multisig (5/8), which enhances security by requiring multiple approvals for critical operations like setting trusted remotes or LayerZero configurations (7.5 Governance). This distributed control mitigates the risk of a single point of failure or malicious actor. Despite the multisig, significant power remains centralized with the owner, allowing them to unilaterally set crucial bridge parameters such as `trustedRemoteLookup` and `minDstGas` (7.3 Access Control). Misconfiguration or a compromised multisig could lead to economic risks like incorrect fee settings or unauthorized cross-chain transfers (7.4 Economic).

UpgradesMedium4/10

The contract is not designed to be upgradeable, which eliminates the risks associated with proxy patterns, such as upgradeability bugs or malicious upgrade implementations (7.7 Upgrades). This provides a fixed and immutable codebase for users. However, the lack of upgradeability means that any discovered vulnerabilities or necessary feature enhancements would require a complete redeployment of the contract and a migration of tokens, leading to significant operational overhead and potential disruption (7.7 Upgrades). This also applies to potential LayerZero endpoint upgrades, as the `lzEndpoint` is immutable.

Security Checklist

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

Holder Composition

7.6% in wallets14.6% in contracts
Effective Concentration13.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

Show 2 more pairsShow less

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 Holder23.0%
Top-3 Unlocked48.8%

Key Addresses

Deployer
0x58e0…2adc
Unlocked LP Held By
0xe426…9e840x5a9a…b64e0x273d…801c0x6a1e…a98f0xe898…dd210x45d8…5dfb0x9899…46a10x9934…06110x2284…84970xcbd4…0827

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
  • 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

ChainLink Token (LINK)Medium RiskWrapped liquid staked Ether 2.0 (WSTETH)Medium RiskAave Token (AAVE)Medium RiskRAINMedium RiskBoopMedium RiskAutonomi (ANT)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