Is Pikachu Safe? Smart Contract Security Analysis

Security Findings

3 Info

Info

Use of Older Solidity Compiler Version

I-01The 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.

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

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

StatusUnresolved

Info

Lack of Administrative Control and Upgradeability

I-02The 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.

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

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

StatusUnresolved

Info

Payable Constructor with ETH Transfer

I-03The 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.

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

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

StatusUnresolved

Category Ratings

TechnicalLow10/10

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.

GovernanceMedium6/10

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.

UpgradesLow7/10

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.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

54.9% in top 10

12.3% in wallets42.7% in contracts

Effective Concentration29.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

$104.3K

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 Burned99.9% · ≈ permanent lock

LP Locked99.9%

Key Addresses

10 addresses

Deployer

0x54f7…5ff0

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.

What Raised This Score

2 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

Is Pikachu Safe?

Security Findings

Use of Older Solidity Compiler Version

Lack of Administrative Control and Upgradeability

Payable Constructor with ETH Transfer

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Pikachu?