Quantum Audit Logo

Is BasedPepe a Scam?

Honeypot, rug-pull and ownership checks

BasedPepe PEPE
0x52b4…777d
Base
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
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The audit covers an ERC20 token contract, likely 'BasedPepe', which appears to be based on OpenZeppelin's robust ERC20 implementation. The provided code snippet is truncated, preventing a full assessment of the `permit` functionality and any custom minting/burning logic. The core ERC20 functions demonstrate strong security practices, but the incomplete view necessitates caution regarding unexamined sections.

1 High2 Medium2 Informational
i Our automated scanner reviewed BasedPepe (PEPE) on Base. 5 of 5 security checks passed — see the full breakdown below.
Volume 24h
$68.4K
Liquidity
$363.3K
Price
$0.0000000066
Age
2y
Top 10 Holders
28.7%

Security Findings

1 High2 Med2 Info
High

Incomplete ERC20Permit Implementation Assessment

H-01The provided code snippet includes the `IERC20Permit` interface and the `ECDSA` library, indicating an intention to implement ERC20 Permit functionality. However, the actual `permit` function, `nonces` mapping, and `DOMAIN_SEPARATOR` calculation are truncated. Without the full implementation, it's impossible to verify critical security aspects such as proper replay protection (e.g., using `nonces` and `deadline`), correct signature validation, and protection against front-running attacks. An improperly implemented `permit` function could lead to unauthorized token transfers.
IssueThe provided code snippet includes the `IERC20Permit` interface and the `ECDSA` library, indicating an intention to implement ERC20 Permit functionality. However, the actual `permit` function, `nonces` mapping, and `DOMAIN_SEPARATOR` calculation are truncated. Without the full implementation, it's impossible to verify critical security aspects such as proper replay protection (e.g., using `nonces` and `deadline`), correct signature validation, and protection against front-running attacks. An improperly implemented `permit` function could lead to unauthorized token transfers.
FixProvide the complete source code for the `permit` function and related components. Ensure that the `permit` function correctly implements EIP-2612 standards, including robust replay protection using `nonces`, a `deadline` parameter to prevent stale signatures, and accurate `DOMAIN_SEPARATOR` calculation. Conduct thorough testing of the `permit` functionality.
StatusUnresolved
Medium

Unverified Access Control for Mint/Burn Functions

M-01The abstract `ERC20` contract includes internal `_mint` and `_burn` functions. While these are internal, it is common for concrete ERC20 implementations to expose them via public functions. The provided code snippet does not show any public `mint` or `burn` functions, nor their associated access control mechanisms. If these functions are exposed without proper access control (e.g., only callable by a designated owner or governance), it could lead to unauthorized supply manipulation, impacting the token's economic stability (7.3 Access Control, 7.4 Economic). The prefill indicates `ownership_renounced: true`, which would imply no single owner for such functions.
IssueThe abstract `ERC20` contract includes internal `_mint` and `_burn` functions. While these are internal, it is common for concrete ERC20 implementations to expose them via public functions. The provided code snippet does not show any public `mint` or `burn` functions, nor their associated access control mechanisms. If these functions are exposed without proper access control (e.g., only callable by a designated owner or governance), it could lead to unauthorized supply manipulation, impacting the token's economic stability (7.3 Access Control, 7.4 Economic). The prefill indicates `ownership_renounced: true`, which would imply no single owner for such functions.
FixIf public `mint` or `burn` functions exist, ensure they are protected by robust access control mechanisms, such as `onlyOwner` or a multi-signature wallet, or a decentralized governance system. If the token is intended to have a fixed supply, ensure these functions are not exposed publicly or are only callable during initial deployment/setup.
StatusUnresolved
Medium

Reliance on Truncated Code for Security Guarantees

M-02The audit is based on a truncated contract source code. Critical sections, particularly the full implementation of `ERC20Permit` and any custom logic extending the `ERC20` abstract contract, are missing. This prevents a comprehensive security assessment and introduces uncertainty regarding potential vulnerabilities in the unexamined parts of the codebase. Any security guarantees provided are limited to the visible code (7.2 Code Security).
IssueThe audit is based on a truncated contract source code. Critical sections, particularly the full implementation of `ERC20Permit` and any custom logic extending the `ERC20` abstract contract, are missing. This prevents a comprehensive security assessment and introduces uncertainty regarding potential vulnerabilities in the unexamined parts of the codebase. Any security guarantees provided are limited to the visible code (7.2 Code Security).
FixAlways provide the complete and final source code for all contracts intended for deployment. A full audit requires access to the entire codebase to ensure all potential attack vectors and vulnerabilities are thoroughly analyzed.
StatusUnresolved
Info

Robust ERC20 Base Implementation

I-01The core ERC20 implementation closely follows established patterns, likely from OpenZeppelin, which is a widely audited and trusted library. This includes proper handling of balances, allowances, transfers, and total supply. The use of Solidity 0.8.x provides default arithmetic overflow/underflow checks, and `unchecked` blocks are appropriately used where safety is guaranteed, mitigating common integer manipulation vulnerabilities (7.2 Code Security).
IssueThe core ERC20 implementation closely follows established patterns, likely from OpenZeppelin, which is a widely audited and trusted library. This includes proper handling of balances, allowances, transfers, and total supply. The use of Solidity 0.8.x provides default arithmetic overflow/underflow checks, and `unchecked` blocks are appropriately used where safety is guaranteed, mitigating common integer manipulation vulnerabilities (7.2 Code Security).
FixMaintain adherence to well-vetted libraries and best practices for core functionalities. Continue to leverage Solidity's safety features and use `unchecked` blocks judiciously.
StatusResolved
Info

Use of Custom Errors for Clarity

I-02The contract utilizes custom errors (e.g., `ERC20InsufficientBalance`, `ERC20InvalidSender`) instead of `require` statements with string messages. This is a best practice in modern Solidity development as it reduces gas costs for failed transactions and provides clearer, more structured error information to off-chain applications (7.2 Code Security).
IssueThe contract utilizes custom errors (e.g., `ERC20InsufficientBalance`, `ERC20InvalidSender`) instead of `require` statements with string messages. This is a best practice in modern Solidity development as it reduces gas costs for failed transactions and provides clearer, more structured error information to off-chain applications (7.2 Code Security).
FixContinue to use custom errors throughout the codebase for improved gas efficiency and better error handling.
StatusResolved

Category Ratings

TechnicalLow9/10

The technical architecture leverages a well-established ERC20 standard, similar to OpenZeppelin's implementation, which is a significant strength (7.1 Architecture). The code uses Solidity 0.8.x, benefiting from default overflow/underflow checks, and explicitly uses `unchecked` blocks where arithmetic safety is guaranteed, enhancing code security (7.2 Code Security). Custom error types are used for clearer error handling. However, the provided code is truncated, specifically omitting the full `ERC20Permit` implementation and any potential public `_mint` or `_burn` functions, which prevents a complete assessment of access control (7.3 Access Control) and potential front-running vectors.

GovernanceLow9/10

The economic model of a standard ERC20 token is generally straightforward (7.4 Economic). However, the presence of `_mint` and `_burn` internal functions implies the possibility of a mutable supply. Without the full contract, it's unclear if these are exposed publicly and, if so, what access control (7.3 Access Control) or governance mechanisms (7.5 Governance) are in place. The prefill indicates `ownership_renounced: true`, which suggests a fixed supply or community-controlled minting, but this cannot be confirmed from the provided snippet. Any centralized control over supply could introduce economic risk.

UpgradesLow10/10

The contract is not identified as a proxy and does not appear to implement any upgradeability patterns (7.7 Upgrades). This means the contract is immutable once deployed, which eliminates upgrade-related risks but also prevents future modifications or bug fixes without a new deployment and migration.

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

28.7% in top 10
14.7% in wallets14.1% in contracts
Effective Concentration20.3%

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

$468.4K across 13 pairs
Uniswap v3WETHanalysed$363.3K77.5%Quickswap v4WETH$99.9K21.3%AerodromeWETH$5.3K1.1%AerodromeUSDC$20.0%PancakeswapWETH$20.0%SushiswapWETH$20.0%
Show 4 more pairsShow less
Uniswap v4FRLZ$10.0%AerodromeWETH$10.0%Uniswap v4NULL$10.0%Uniswap v4USDC$00.0%

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.3% · TeamFinance
Top-1 Unlocked Holder0.4%

Key Addresses

10 addresses
Deployer
0x525f…6428
Unlocked LP Held By
0xffbf…ab9b0xfeee…2fb80xa86a…166e0x1d95…80520x30f6…31940x048e…34c40xcaea…fd760x3bd2…17b10x3378…c3ae

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

What Raised This Score

3 factors
  • Top-10 concentration > 20% (28.7% total → 20.3% effective; 14.7% in EOAs, 14.1% in contracts — mild)
  • 1 High finding(s) from audit
  • 2 Medium 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
Briun Armstrung (BRIUN)Low RiskVEIL Token (VEIL)Low RiskCoinye West (COINYE)Low RiskDebtReliefBot (DRB)Low RiskToshiLow RiskRUSSELLLow Risk

Would You Like a More Detailed Audit of BasedPepe?

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

Get Detailed Audit