Quantum Audit Logo
Launch App

Honeypot, rug-pull and ownership checks

Is Lego Pepe a Scam?

LEPEEthereum
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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance2/10Upgrades8/10Checks passed5 of 5Findings2 Critical · 2 High · 2 Medium · 2 Low8
SummaryAI Copilot

The LEPE token contract implements an ERC-20 standard with custom tax, anti-whale, and automated liquidity features.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • Liquidity < $10k
  • 2 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 30% (93.7% total → 47.4% effective; 16.5% in EOAs, 77.2% in contracts — moderate)
  • Liquidity < $10k ($8,794 across 1 pairs — easily drained)
  • 2 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 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 Lego Pepe (LEPE) 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
77.2%Contracts16.5%Wallets6.3%Everyone else
77.2%Contracts16.5%Wallets6.3%
ContractsWalletsEveryone elseBubble area = share of supply
93.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking77.2%
  • Walletsanonymous holders, free to sell16.5%
  • Everyone elsethe rest of the supply6.3%
Effective concentrationwhat the score reads47.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$8.8K

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$8.8KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Security Findings

2 Critical2 High2 Medium2 Low
Critical

Centralized Control and Excessive Owner Privileges

The Ownable pattern grants the contract owner extensive control over critical functions and parameters. The owner can modify all tax rates (setInitialBuyTax, setFinalSellTax), transaction limits (setMaxTxAmount, setMaxWalletSize), enable/disable swaps (setSwapEnabled), add/remove addresses from the bots mapping, and update the Uniswap router. This level of centralization allows the owner to significantly alter the token's economics, halt trading, or arbitrarily block users, posing a severe risk of manipulation or malicious action (7.3 Access Control, 7.8 Operations).C-01

Issue

The Ownable pattern grants the contract owner extensive control over critical functions and parameters. The owner can modify all tax rates (setInitialBuyTax, setFinalSellTax), transaction limits (setMaxTxAmount, setMaxWalletSize), enable/disable swaps (setSwapEnabled), add/remove addresses from the bots mapping, and update the Uniswap router. This level of centralization allows the owner to significantly alter the token's economics, halt trading, or arbitrarily block users, posing a severe risk of manipulation or malicious action (7.3 Access Control, 7.8 Operations).

Fix

Implement a multi-signature wallet or a timelock contract for critical administrative functions to introduce a delay before changes take effect, allowing the community to react. Consider gradually decentralizing control over key parameters or limiting the owner's ability to make drastic changes without community consensus.

Status

Unresolved

Critical

Unlocked Liquidity Pool (Rug Pull Risk)

The provided prefill information indicates that the liquidity pool (LP) is 'unlocked'. The addLiquidityETH function is restricted to the owner. This means the owner has the ability to add liquidity to the Uniswap pair and subsequently remove it at any time, effectively performing a 'rug pull' by draining the liquidity and rendering the token worthless. This is a critical economic vulnerability (7.4 Economic).C-02

Issue

The provided prefill information indicates that the liquidity pool (LP) is 'unlocked'. The addLiquidityETH function is restricted to the owner. This means the owner has the ability to add liquidity to the Uniswap pair and subsequently remove it at any time, effectively performing a 'rug pull' by draining the liquidity and rendering the token worthless. This is a critical economic vulnerability (7.4 Economic).

Fix

Immediately lock the liquidity pool tokens with a reputable third-party locker service for a significant duration (e.g., 1-5 years or permanently). Provide verifiable proof of the locked LP to the community to build trust and mitigate this critical risk.

Status

Unresolved

High

Potential Denial of Service (DoS) Vectors

The contract contains several mechanisms that could lead to denial of service: 1. **Swap Failure:** The _transfer function calls swapTokensForEth. If this external call to IUniswapV2Router02 fails (e.g., due to network congestion, router issues, or insufficient amountOutMin), the entire _transfer transaction will revert, potentially blocking all transfers when swapEnabled is true and _taxSwapThreshold is met (7.2 Code Security). 2. **Sell Limit:** The require(sellCount < 3, "Only 3 sells per block!") condition can prevent legitimate users from selling their tokens, especially during periods of high trading volume, leading to frustration and potential losses (7.2 Code Secu…H-01

Issue

The contract contains several mechanisms that could lead to denial of service: 1. **Swap Failure:** The _transfer function calls swapTokensForEth. If this external call to IUniswapV2Router02 fails (e.g., due to network congestion, router issues, or insufficient amountOutMin), the entire _transfer transaction will revert, potentially blocking all transfers when swapEnabled is true and _taxSwapThreshold is met (7.2 Code Security). 2. **Sell Limit:** The require(sellCount < 3, "Only 3 sells per block!") condition can prevent legitimate users from selling their tokens, especially during periods of high trading volume, leading to frustration and potential losses (7.2 Code Secu…

Fix

For swap failures, consider implementing a try-catch block around the external swap call to handle failures gracefully without reverting the entire transfer. For sell limits, re-evaluate the necessity and impact on user experience; if kept, ensure clear communication. For bot/wallet limits, ensure transparent policies and consider community-driven mechanisms for managing such lists.

Status

Unresolved

High

Slippage Vulnerability in Automated Swaps

The swapTokensForEth function calls IUniswapV2Router02.swapExactTokensForETHSupportingFeeOnTransferTokens. This function requires an amountOutMin parameter to protect against slippage. However, the contract passes 0 as amountOutMin, meaning the swap can execute regardless of the output ETH amount. This exposes the automated tax swap to significant slippage, front-running attacks, and potential value loss, especially during volatile market conditions or if a malicious actor manipulates the pool (7.2 Code Security, 7.4 Economic).H-02

Issue

The swapTokensForEth function calls IUniswapV2Router02.swapExactTokensForETHSupportingFeeOnTransferTokens. This function requires an amountOutMin parameter to protect against slippage. However, the contract passes 0 as amountOutMin, meaning the swap can execute regardless of the output ETH amount. This exposes the automated tax swap to significant slippage, front-running attacks, and potential value loss, especially during volatile market conditions or if a malicious actor manipulates the pool (7.2 Code Security, 7.4 Economic).

Fix

Implement a robust mechanism to calculate and enforce a reasonable amountOutMin for the automated swap. This could involve using a price oracle, a fixed percentage slippage tolerance, or allowing the owner to configure a dynamic slippage parameter. This is crucial to protect the value of the collected tax tokens.

Status

Unresolved

Medium

Dynamic and High Tax Rates

The contract implements dynamic buy and sell taxes (_initialBuyTax, _initialSellTax, _finalBuyTax, _finalSellTax) that can be as high as 13% for buys and 12% for sells. These rates can change based on _buyCount thresholds. Such high and variable taxes can be confusing for users, significantly impact trading economics, and potentially deter participation. The owner has full control to modify these rates at any time (7.4 Economic).M-01

Issue

The contract implements dynamic buy and sell taxes (_initialBuyTax, _initialSellTax, _finalBuyTax, _finalSellTax) that can be as high as 13% for buys and 12% for sells. These rates can change based on _buyCount thresholds. Such high and variable taxes can be confusing for users, significantly impact trading economics, and potentially deter participation. The owner has full control to modify these rates at any time (7.4 Economic).

Fix

Clearly communicate the tax structure and its dynamic nature to users. Consider setting more predictable and potentially lower tax rates to encourage trading. If dynamic taxes are essential, ensure the logic is thoroughly tested and transparent. Implement a timelock for changes to tax rates.

Status

Unresolved

Medium

Anti-Bot/Anti-Whale Mechanisms Introduce Centralization

The contract includes bots mapping, _maxTxAmount, and _maxWalletSize to prevent manipulation and large holdings. While intended to protect against malicious actors, these mechanisms introduce significant centralization. The owner can arbitrarily add/remove addresses from the bots list or adjust transaction/wallet limits, potentially blocking legitimate users or manipulating market dynamics. This creates an unfair and unpredictable trading environment (7.3 Access Control, 7.4 Economic).M-02

Issue

The contract includes bots mapping, _maxTxAmount, and _maxWalletSize to prevent manipulation and large holdings. While intended to protect against malicious actors, these mechanisms introduce significant centralization. The owner can arbitrarily add/remove addresses from the bots list or adjust transaction/wallet limits, potentially blocking legitimate users or manipulating market dynamics. This creates an unfair and unpredictable trading environment (7.3 Access Control, 7.4 Economic).

Fix

Carefully evaluate the necessity and implementation of these anti-bot/anti-whale features. If retained, establish clear, transparent criteria for their use and consider community oversight or a timelock for changes. Ensure these mechanisms cannot be easily bypassed or misused by the owner.

Status

Unresolved

Low

Hardcoded Tax Wallet Address

The _taxWallet address is hardcoded in the constructor (`_taxWallet = payable(0x6db1…a6D9);). While there is an onlyOwner function setTaxWallet` to change it, if the owner renounces ownership, this address becomes immutable. If the hardcoded wallet's private key is lost or compromised, the collected tax funds would become inaccessible or vulnerable (7.8 Operations).L-01

Issue

The _taxWallet address is hardcoded in the constructor (`_taxWallet = payable();). While there is an onlyOwner function setTaxWallet` to change it, if the owner renounces ownership, this address becomes immutable. If the hardcoded wallet's private key is lost or compromised, the collected tax funds would become inaccessible or vulnerable (7.8 Operations).

Fix

Ensure the _taxWallet is a secure, multi-signature wallet. If ownership is to be renounced, ensure the _taxWallet is set to a robust, community-controlled or immutable address beforehand. Consider making the initial _taxWallet configurable during deployment rather than hardcoded.

Status

Unresolved

Low

Lack of Event Emission for Critical Parameter Changes

Many onlyOwner functions that modify critical contract parameters (e.g., setInitialBuyTax, setFinalSellTax, setReduceBuyTaxAt, setPreventSwapBefore, setTaxSwapThreshold, setMaxTaxSwap, setBots, setSwapEnabled) do not emit corresponding events. Without events, it is difficult for off-chain monitoring systems, users, and block explorers to track changes to the contract's behavior and economic parameters, reducing transparency and auditability (7.8 Operations).L-02

Issue

Many onlyOwner functions that modify critical contract parameters (e.g., setInitialBuyTax, setFinalSellTax, setReduceBuyTaxAt, setPreventSwapBefore, setTaxSwapThreshold, setMaxTaxSwap, setBots, setSwapEnabled) do not emit corresponding events. Without events, it is difficult for off-chain monitoring systems, users, and block explorers to track changes to the contract's behavior and economic parameters, reducing transparency and auditability (7.8 Operations).

Fix

Emit specific events for all functions that modify critical contract state variables. This enhances transparency, allows for easier monitoring, and improves the overall auditability of the contract's operational history.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The LEPE token contract implements an ERC-20 standard with custom tax, anti-whale, and automated liquidity features. While utilizing SafeMath for arithmetic safety, the contract exhibits critical centralization risks due to extensive owner privileges, including the ability to control all economic parameters and potentially rug-pull liquidity. Several denial-of-service vectors and a lack of slippage protection in automated swaps also pose significant risks to users.

Technical4/10Medium risk

The contract utilizes SafeMath to prevent common integer overflow/underflow issues and implements a lockTheSwap modifier to mitigate reentrancy during automated token swaps (7.2 Code Security). However, the complex _transfer logic introduces several denial-of-service vectors, such as potential transaction reverts if the automated swap fails or if the sellCount limit is reached (7.2 Code Security). Additionally, the lack of explicit slippage protection in swapExactTokensForETHSupportingFeeOnTransferTokens exposes the automated swap to front-running and value loss (7.2 Code Security).

Governance2/10High risk

The contract employs an Ownable access control pattern, granting the deployer extensive control over critical parameters like tax rates, transaction limits, and the ability to block addresses (7.3 Access Control). This high degree of centralization, coupled with the reported unlocked liquidity pool, presents a critical rug-pull risk (7.4 Economic). The dynamic and potentially high tax rates (e.g., 13% initial buy tax) can create an unpredictable economic environment for users (7.4 Economic).

Upgrades8/10Low risk

The LEPE contract is not designed with an upgradeable proxy pattern, meaning its core logic cannot be directly modified after deployment (7.7 Upgrades). While this prevents direct code upgrades, the Ownable pattern allows the owner to significantly alter the contract's economic behavior and operational parameters through various administrative functions (7.8 Operations). This provides a form of 'soft upgradeability' for critical settings, but without the ability to fix core logic bugs.

Final RecommendationWhat to do about this score

Given the critical risks identified, particularly the unlocked liquidity pool and extensive owner control, it is strongly recommended that potential users exercise extreme caution.

The project team should consider implementing a timelock for critical owner functions and locking liquidity to build trust. Furthermore, the automated swap mechanism requires robust slippage protection to prevent value loss during execution. For long-term security and decentralization, explore options to gradually reduce owner privileges or transition to a community-governed model. Ensure all critical parameter changes emit events for transparency and off-chain monitoring.

Contract & Record

1 audit on record
TypeRouter, Token
NetworkEthereum
Token age1y
Contract0x396c…b623
Deployer0x6db1…a6d9
Badge for your website
Lego Pepe security record badge

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
  1. Aug 14, 202661Medium

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

Related Audits

6 more on the recordAll audits
HarryPotterObamaSonic10InuBITCOIN · Ethereum61MediumGraph TokenGRT · Ethereum61MediumGnosis TokenGNO · Ethereum61MediumInterfoldFOLD · Ethereum61MediumTokenFiTOKEN · Ethereum61MediumANyONe ProtocolANYONE · Ethereum61Medium

Would You Like a More Detailed Audit of Lego 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 Is this your token? Publish your own audit on this page