Quantum Audit Logo

Is Lego Pepe a Scam?

Honeypot, rug-pull and ownership checks

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

Lego Pepe LEPE
0x396c…b623
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

2 Critical2 High2 Medium2 Low
i Our automated scanner reviewed Lego Pepe (LEPE) on Ethereum. 5 of 5 security checks passed — see the full breakdown below.
Volume 24h
$38.6K
Liquidity
$8.8K
Price
$0.
Age
1y
Top 10 Holders
93.7%

Security Findings

2 Crit2 High2 Med2 Low
Critical

Centralized Control and Excessive Owner Privileges

C-01The `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).
IssueThe `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).
FixImplement 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.
StatusUnresolved
Critical

Unlocked Liquidity Pool (Rug Pull Risk)

C-02The 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).
IssueThe 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).
FixImmediately 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.
StatusUnresolved
High

Potential Denial of Service (DoS) Vectors

H-01The 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…
IssueThe 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…
FixFor 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.
StatusUnresolved
High

Slippage Vulnerability in Automated Swaps

H-02The `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).
IssueThe `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).
FixImplement 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.
StatusUnresolved
Medium

Dynamic and High Tax Rates

M-01The 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).
IssueThe 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).
FixClearly 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.
StatusUnresolved
Medium

Anti-Bot/Anti-Whale Mechanisms Introduce Centralization

M-02The 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).
IssueThe 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).
FixCarefully 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.
StatusUnresolved
Low

Hardcoded Tax Wallet Address

L-01The `_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).
IssueThe `_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).
FixEnsure 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.
StatusUnresolved
Low

Lack of Event Emission for Critical Parameter Changes

L-02Many `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).
IssueMany `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).
FixEmit 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.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

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

GovernanceHigh2/10

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

UpgradesLow8/10

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.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

93.7% in top 10
16.5% in wallets77.2% in contracts
Effective Concentration47.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

$8.8K

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 Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

1 addresses
Deployer
0x6db1…a6d9

What Raised This Score

6 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

Related Audits

6 more on the record
HarryPotterObamaSonic10Inu (BITCOIN)High RiskGraph Token (GRT)High RiskGnosis Token (GNO)High RiskInterfold (FOLD)High RiskTokenFi (TOKEN)High RiskANyONe Protocol (ANYONE)High Risk

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