Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is Pikachu Safe?

PIKACHUEthereum
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
SummaryAI Copilot

The PikachuToken contract implements a standard ERC-20 token with basic functionalities including transfer, approval, and burning.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Top-10 concentration > 20%
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 20% (54.9% total → 29.3% effective; 12.3% in EOAs, 42.7% in contracts — mild)

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

Security Checklist

as of audit · Sep 44 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
42.7%Contracts12.3%Wallets45.1%Everyone else
42.7%Contracts12.3%45.1%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
54.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking42.7%
  • Walletsanonymous holders, free to sell12.3%
  • Everyone elsethe rest of the supply45.1%
Effective concentrationwhat the score reads29.3%
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$104.3K

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$104.3KShare of depth100.0%
LP Burned99.9% · ≈ permanent lock
LP Locked99.9%
Unlocked LP held by
0x424c…d4070x8751…19d20xf4af…136f0x1ca4…40c70x2b25…64820xce97…56f30xe851…b19e0x0720…4b740x7c0a…7a75

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

Security Findings

3 Info
Info

Use of Older Solidity Compiler Version

The contract is compiled with pragma solidity ^0.5.0. While SafeMath is used to mitigate integer overflow/underflow, newer Solidity versions (e.8.x) include built-in overflow/underflow checks, making SafeMath redundant and potentially reducing gas costs. Newer compilers also offer various security improvements and optimizations.I-01

Issue

The contract is compiled with pragma solidity ^0.5.0. While SafeMath is used to mitigate integer overflow/underflow, newer Solidity versions (e.8.x) include built-in overflow/underflow checks, making SafeMath redundant and potentially reducing gas costs. Newer compilers also offer various security improvements and optimizations.

Fix

Consider using a more recent and actively maintained Solidity compiler version (e.g., ^0.8.0) for new deployments. This would allow for the removal of the SafeMath library, simplifying the code and leveraging the compiler's native safety features.

Status

Unresolved

Info

Lack of Administrative Control and Upgradeability

The PikachuToken contract does not implement any administrative roles (e.g., Ownable, AccessControl) or upgradeability patterns (e.g., UUPS, Transparent Proxies). This means that after deployment, no entity can pause transfers, mint additional tokens, modify contract parameters, or fix potential bugs. This design choice ensures immutability and decentralization but removes any flexibility for future management or emergency responses.I-02

Issue

The PikachuToken contract does not implement any administrative roles (e.g., Ownable, AccessControl) or upgradeability patterns (e.g., UUPS, Transparent Proxies). This means that after deployment, no entity can pause transfers, mint additional tokens, modify contract parameters, or fix potential bugs. This design choice ensures immutability and decentralization but removes any flexibility for future management or emergency responses.

Fix

Confirm that the project's long-term vision aligns with a fully immutable and decentralized token. If future administrative actions (e.g., pausing, minting, burning, parameter changes) or bug fixes are ever anticipated, a robust access control and/or upgradeability mechanism should be integrated into the design.

Status

Unresolved

Info

Payable Constructor with ETH Transfer

The contract's constructor is declared payable and immediately transfers any received msg.value to a feeReceiver address. While this functionality is explicit, it is an unusual pattern for a standard ERC-20 token constructor, which typically focuses solely on token initialization. This could potentially lead to confusion for deployers or unintended ETH transfers if not fully understood.I-03

Issue

The contract's constructor is declared payable and immediately transfers any received msg.value to a feeReceiver address. While this functionality is explicit, it is an unusual pattern for a standard ERC-20 token constructor, which typically focuses solely on token initialization. This could potentially lead to confusion for deployers or unintended ETH transfers if not fully understood.

Fix

Ensure that the purpose of the payable constructor and the immediate ETH transfer to feeReceiver is clearly documented and communicated to anyone deploying or interacting with the contract. If this functionality is not strictly necessary for the token's core purpose, consider removing the payable keyword and the ETH transfer logic from the constructor.

Status

Unresolved

Analysis

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

The PikachuToken contract implements a standard ERC-20 token with basic functionalities including transfer, approval, and burning. It utilizes the SafeMath library to prevent integer overflow/underflow vulnerabilities. The contract is designed for immutability with no administrative roles or upgrade mechanisms. The overall risk level is assessed as Low due to its simplicity and robust use of SafeMath, though the use of an older Solidity compiler version is noted.

Technical10/10Low risk

The technical architecture (7.1) of PikachuToken is straightforward, adhering to the ERC-20 standard. Code security (7.2) is enhanced by the consistent use of the SafeMath library, effectively mitigating integer overflow and underflow risks in all arithmetic operations. Access control (7.3) is minimal, with no administrative roles, ensuring a decentralized and immutable token. However, the contract is compiled with Solidity ^0.5.0, an older version, which, while functional with SafeMath, lacks some security features and optimizations present in newer compilers.

Governance6/10Medium risk

The economic model (7.4) of PikachuToken is simple, representing a fixed-supply token after initial minting in the constructor. There are no complex economic mechanisms such as staking, lending, or rebase functions. Governance (7.5) is entirely absent, meaning there are no owner-controlled functions, multisig, or DAO structures for post-deployment management. This design choice implies a fully decentralized and immutable token, which eliminates governance-related attack vectors but also removes any possibility for future administrative intervention.

Upgrades7/10Low risk

The PikachuToken contract is not designed with any upgradeability mechanisms (7.7). It is a standard, non-proxy implementation, meaning its logic is immutable once deployed. This eliminates all risks associated with upgradeability, such as proxy implementation vulnerabilities or governance failures during upgrades. However, it also means that any discovered bugs or desired feature changes cannot be implemented without deploying a new contract.

Final RecommendationWhat to do about this score

It is recommended to consider migrating to a more recent Solidity compiler version (e.g., 0.8.x) for future projects, as it offers built-in overflow/underflow checks and other security enhancements.

While the current implementation is robust due to SafeMath, newer versions provide a more secure and efficient development environment. Additionally, ensure that the design choice of having no administrative control or upgradeability aligns with the long-term vision for the token, as this immutability prevents any future modifications or emergency interventions.

Contract & Record

1 audit on record
TypePikachuToken
NetworkEthereum
Token age5y
Contract0xe09f…86bf
Deployer0x54f7…5ff0
Badge for your website
Pikachu 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 17, 20260Low

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

Would You Like a More Detailed Audit of Pikachu?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page