Quantum Audit Logo

Is PepeCat a Scam?

Early-stage security check — honeypot & rug-pull analysis

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

PepeCat PCAT
0x503d…3180
Ethereum
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 today 1 audit on record New Launch · 19h old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The RobinVistaToken contract serves as an ERC20 token implementation for a proxy, utilizing OpenZeppelin's battle-tested ERC20 library. The contract includes a robust initialization mechanism for proxy deployment, preventing re-initialization. However, the design centralizes significant control in the hands of the initializer, who receives the entire initial token supply and becomes the sole entity capable of setting critical pool parameters. While the core ERC20 functionality is secure due to OpenZeppelin's implementation, the centralized control points introduce a notable governance and economic risk.

1 High2 Low2 Informational
! Early-stage analysis. This token has limited on-chain history (19h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$202.6K
Liquidity
$27.7K
Price
$0.00005301
Token Age
19h
Top 10 Holders
51.0%

Security Findings

1 High2 Low2 Info
High

Centralized Control over Initial Supply and Pool Configuration

H-01The `initialize` function grants `msg.sender` (the address that calls `initialize` on the proxy) the ability to mint the entire `totalSupply_` to themselves. Additionally, this same address is set as the `factory`, which is the only address permitted to call `setPool` to configure critical `poolId` and `baseToken` parameters. This design centralizes significant control in a single entity, creating a single point of failure and potential for misuse or compromise. If the initializer's private key is compromised, the entire token supply and critical pool configurations could be at risk.
IssueThe `initialize` function grants `msg.sender` (the address that calls `initialize` on the proxy) the ability to mint the entire `totalSupply_` to themselves. Additionally, this same address is set as the `factory`, which is the only address permitted to call `setPool` to configure critical `poolId` and `baseToken` parameters. This design centralizes significant control in a single entity, creating a single point of failure and potential for misuse or compromise. If the initializer's private key is compromised, the entire token supply and critical pool configurations could be at risk.
FixImplement a more decentralized approach for managing the initial token supply and the `factory` role. Consider the following: 1. **Initial Supply:** Mint the initial supply to a multi-signature wallet, a timelock contract, or a predefined distribution contract instead of directly to `msg.sender`. 2. **Factory Role:** Assign the `factory` role to a multi-signature wallet or a governance contract rather than a single EOA. This would require multiple approvals for critical `setPool` operations.…
StatusUnresolved
Low

Missing Events for Critical Setup Functions

L-01The `initialize` and `setPool` functions, which perform critical one-time setup operations for the token and its associated pool, do not emit any events. While state variables are updated, the absence of explicit events makes it harder for off-chain systems (e.g., block explorers, indexers, monitoring tools) to track and verify these crucial configuration changes transparently and efficiently.
IssueThe `initialize` and `setPool` functions, which perform critical one-time setup operations for the token and its associated pool, do not emit any events. While state variables are updated, the absence of explicit events makes it harder for off-chain systems (e.g., block explorers, indexers, monitoring tools) to track and verify these crucial configuration changes transparently and efficiently.
FixEmit events for the `initialize` and `setPool` functions to provide clear, auditable records of these critical operations. For example: - `event Initialized(address indexed initializer, address indexed deployer, uint256 totalSupply);` - `event PoolSet(bytes32 indexed poolId, address indexed baseToken);` Emitting events enhances transparency, simplifies off-chain monitoring, and improves the overall auditability of the contract's lifecycle.
StatusUnresolved
Low

Unused `deployer` State Variable

L-02The `deployer` state variable is set once during the `initialize` function but is never read or used anywhere else in the contract's logic. While it might be intended for informational purposes, storing an unused variable consumes gas during deployment and state storage, and adds unnecessary complexity to the contract's state.
IssueThe `deployer` state variable is set once during the `initialize` function but is never read or used anywhere else in the contract's logic. While it might be intended for informational purposes, storing an unused variable consumes gas during deployment and state storage, and adds unnecessary complexity to the contract's state.
FixIf the `deployer` variable serves no functional purpose within the contract's logic, consider removing it to optimize gas costs and simplify the contract's state. If it is intended purely for informational purposes, consider emitting it in an `Initialized` event instead of storing it as a state variable.
StatusUnresolved
Info

Constructor Initialization with `address(0xdead)`

I-01The contract's constructor initializes the `factory` variable to `address(0xdead)`. This is a common and effective pattern used in proxy implementation contracts to prevent accidental or malicious direct initialization of the implementation contract itself. Since the proxy's constructor is not called, the `initialize` function's check `if (factory != address(0))` correctly ensures that initialization only occurs once via the proxy.
IssueThe contract's constructor initializes the `factory` variable to `address(0xdead)`. This is a common and effective pattern used in proxy implementation contracts to prevent accidental or malicious direct initialization of the implementation contract itself. Since the proxy's constructor is not called, the `initialize` function's check `if (factory != address(0))` correctly ensures that initialization only occurs once via the proxy.
FixNo action required. This is a secure and standard practice for proxy implementations.
StatusUnresolved
Info

Safe Use of `unchecked` Blocks in ERC20 Standard Library

I-02The OpenZeppelin `ERC20` contract utilizes `unchecked` blocks for arithmetic operations such as `_balances[from] = fromBalance - value;` and `_balances[to] += value;`. These `unchecked` blocks are safely implemented because preceding conditional checks (e.g., `if (fromBalance < value)`) prevent underflow for subtractions, and overflows for additions are generally accepted for token balances given the `uint256` maximum value. This design choice optimizes gas costs without compromising security due to careful preceding logic.
IssueThe OpenZeppelin `ERC20` contract utilizes `unchecked` blocks for arithmetic operations such as `_balances[from] = fromBalance - value;` and `_balances[to] += value;`. These `unchecked` blocks are safely implemented because preceding conditional checks (e.g., `if (fromBalance < value)`) prevent underflow for subtractions, and overflows for additions are generally accepted for token balances given the `uint256` maximum value. This design choice optimizes gas costs without compromising security due to careful preceding logic.
FixNo action required. This is a well-audited and secure pattern within the OpenZeppelin library.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract leverages OpenZeppelin's ERC20 implementation, which is a strong foundation for code security (7.2 Code Security), mitigating common vulnerabilities like reentrancy and integer overflows. The initialization logic for the proxy is well-designed, using `address(0xdead)` in the constructor and a `factory != address(0)` check to ensure single initialization (7.1 Architecture). However, the `initialize` function grants the caller the ability to mint the entire `totalSupply_` to themselves, and the `factory` role, which can set `poolId` and `baseToken` once, is also assigned to this caller (7.3 Access Control). This centralization of control is a primary technical risk.

GovernanceHigh1/10

The economic model and governance structure present a high risk due to significant centralization (7.4 Economic, 7.5 Governance). The `initialize` function allows the `msg.sender` to mint the entire initial token supply to their address, creating a single point of control over the token's distribution. Furthermore, this same address becomes the `factory`, which is the only entity permitted to call `setPool` to define the `poolId` and `baseToken` once. This design means a single address holds complete control over the initial token supply and critical integration parameters, posing a substantial risk if compromised or misused.

UpgradesMedium6/10

The contract is designed as an implementation for a proxy, which inherently supports upgradeability (7.7 Upgrades). The `initialize` function includes a robust re-initialization guard (`if (factory != address(0)) revert AlreadyInitialized();`), and the constructor sets `factory = address(0xdead)` to prevent direct initialization of the implementation contract, which is a standard and effective pattern for proxy implementations. This setup ensures that the contract can be safely upgraded without compromising its state or re-initialization integrity.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

51.0% in top 10
14.5% in wallets36.5% in contracts
Effective Concentration29.1%

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

$29.0K across 7 pairs
Uniswap v4PEPEanalysed$27.7K95.4%Uniswap v4ETH$1.1K3.7%Uniswap v4USDC$1590.5%Uniswap v4ETH$830.3%Uniswap v4USDC$50.0%Uniswap v4USDC$10.0%
Show 1 more pairShow less
Uniswap v4USDT$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

Top-1 Unlocked Holder83.0%
Top-3 Unlocked100.0%

Key Addresses

3 addresses
Deployer
0xdf76…a6a2
Unlocked LP Held By
0x576c…0fa10xf6c3…fecd

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

What Raised This Score

9 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 20% (51.0% total → 29.1% effective; 14.5% in EOAs, 36.5% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($28,997 across 7 pairs — thin market)
  • LP top1 unlocked holder = 83.0% (independent LP — depth risk, pool = 95% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 95% of DEX liquidity)
  • Token age < 24h (brand new — bot activity, unproven)
  • 1 High 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
Helix Token (HLX)High RiskEuler (EUL)High RiskQuant (QNT)High RiskNeuralAI (NEURAL)High RiskMorphoHigh RiskBeamHigh Risk

Would You Like a More Detailed Audit of PepeCat?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit