Quantum Audit Logo
Launch App

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

Is PeiPei Safe?

PEIPEIEthereum
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
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical10/10Governance9/10Upgrades10/10Checks passed7 of 7Findings2 Low · 3 Info5
SummaryAI Copilot

The audit of the provided ERC20 token contract reveals a well-structured implementation adhering to the ERC20 standard, utilizing SafeMath for arithmetic safety.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • 2 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 30% (39.9% total → 32.7% effective; 27.8% in EOAs, 12.1% in contracts — moderate)
  • 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

Security Checklist

as of audit · Sep 47 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
12.1%Contracts27.8%Wallets60.1%Everyone else
12.1%27.8%Wallets60.1%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
39.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking12.1%
  • Walletsanonymous holders, free to sell27.8%
  • Everyone elsethe rest of the supply60.1%
Effective concentrationwhat the score reads32.7%
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$644.6K across 5 pairs

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$639.2KShare of depth99.2%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address
Unlocked LP held by
0x37f8…ecbf0xb3ac…68a00x0000…8a900xbcde…57f7

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

Security Findings

2 Low3 Info
Low

Incomplete Ownable Contract Provided

The provided source code for the Ownable contract is truncated. This prevents a full security assessment of its implementation, including verification of standard access control patterns, potential owner-controlled functions, and the impact of the ownership_renounced: true prefill information. Without the complete code, it's impossible to confirm the exact privileges of the owner or the implications of ownership renunciation.L-01

Issue

The provided source code for the Ownable contract is truncated. This prevents a full security assessment of its implementation, including verification of standard access control patterns, potential owner-controlled functions, and the impact of the ownership_renounced: true prefill information. Without the complete code, it's impossible to confirm the exact privileges of the owner or the implications of ownership renunciation.

Fix

Provide the complete and verified source code for all inherited contracts, especially Ownable, to allow for a comprehensive security audit of access control mechanisms (7.3 Access Control) and governance implications (7.5 Governance).

Status

Unresolved

Low

Missing NatSpec Documentation

Several functions within the contract, particularly internal and private helper functions, lack comprehensive NatSpec documentation. This can hinder understanding of the contract's logic, especially for future maintainers or auditors, and may lead to misinterpretations or errors during upgrades or integrations.L-02

Issue

Several functions within the contract, particularly internal and private helper functions, lack comprehensive NatSpec documentation. This can hinder understanding of the contract's logic, especially for future maintainers or auditors, and may lead to misinterpretations or errors during upgrades or integrations.

Fix

Add detailed NatSpec comments for all functions, especially those that are public, external, or implement complex logic. This includes @param, @return, and @notice tags to clearly describe their purpose, parameters, and return values.

Status

Unresolved

Info

Use of SafeMath Library

The contract correctly utilizes the SafeMath library for all arithmetic operations (addition, subtraction, multiplication, division, modulo). This effectively prevents integer overflow and underflow vulnerabilities (7.2 Code Security), which are common pitfalls in Solidity development.I-01

Issue

The contract correctly utilizes the SafeMath library for all arithmetic operations (addition, subtraction, multiplication, division, modulo). This effectively prevents integer overflow and underflow vulnerabilities (7.2 Code Security), which are common pitfalls in Solidity development.

Fix

Maintain the consistent use of SafeMath or Solidity's native checked arithmetic (available in Solidity 0.8.0 and above) for all arithmetic operations to ensure robust handling of numerical values.

Status

Resolved

Info

Adherence to ERC20 Standard

The contract implements the ERC20 standard correctly, including all required functions (totalSupply, balanceOf, transfer, allowance, approve, transferFrom) and events (Transfer, Approval). This ensures compatibility with various DeFi protocols and wallets (7.6 External).I-02

Issue

The contract implements the ERC20 standard correctly, including all required functions (totalSupply, balanceOf, transfer, allowance, approve, transferFrom) and events (Transfer, Approval). This ensures compatibility with various DeFi protocols and wallets (7.6 External).

Fix

Continue to adhere strictly to established ERC standards to maintain broad compatibility and interoperability within the EVM ecosystem.

Status

Resolved

Info

Internal Mint/Burn Functions

The _mint and _burn functions are declared as internal virtual. This design choice means that the ERC20 contract itself does not expose public minting or burning capabilities. Any such functionality would need to be explicitly implemented in a derived contract, allowing for controlled inflation/deflation mechanisms (7.4 Economic).I-03

Issue

The _mint and _burn functions are declared as internal virtual. This design choice means that the ERC20 contract itself does not expose public minting or burning capabilities. Any such functionality would need to be explicitly implemented in a derived contract, allowing for controlled inflation/deflation mechanisms (7.4 Economic).

Fix

If public minting or burning is intended in a derived contract, ensure that these functions are protected by appropriate access control mechanisms (e.g., only callable by a trusted role or governance) to prevent unauthorized token supply manipulation.

Status

Resolved

Analysis

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

The audit of the provided ERC20 token contract reveals a well-structured implementation adhering to the ERC20 standard, utilizing SafeMath for arithmetic safety. The contract includes internal minting and burning functions, which are not publicly exposed by the ERC20 contract itself. A significant limitation is the truncation of the Ownable contract, preventing a full assessment of its access control mechanisms. However, the prefill data indicates that ownership has been renounced, which, if accurate, mitigates centralized control risks. Overall, the contract presents a Low risk profile.

Technical10/10Low risk

The contract demonstrates good technical architecture (7.1 Architecture) by implementing the ERC20 standard and utilizing the SafeMath library, which prevents common integer overflow/underflow vulnerabilities (7.2 Code Security). The code is generally clear and follows common Solidity patterns. However, the Ownable contract is truncated, which limits a full assessment of its access control implementation (7.3 Access Control).

Governance9/10Low risk

The contract's economic model (7.4 Economic) is based on a standard ERC20 token with internal minting and burning capabilities. The provided prefill indicates that ownership has been renounced, which significantly reduces centralized governance risk (7.5 Governance) by preventing a single entity from controlling administrative functions, assuming the Ownable contract was standard and its owner could control such functions. There are no explicit governance mechanisms within the ERC20 contract itself, and its economic stability relies on the fixed supply after renunciation, if no other contract can mint.

Upgrades10/10Low risk

The contract is not designed as an upgradeable proxy (7.7 Upgrades), meaning its logic cannot be changed after deployment. This eliminates upgrade-related risks such as proxy initialization issues or storage collisions. Any future changes would require a new deployment and migration.

Final RecommendationWhat to do about this score

Ensure that the full source code for all inherited contracts, especially Ownable, is available for a complete security assessment.

Implement comprehensive NatSpec documentation for all public and external functions to improve code clarity and maintainability. Verify the on-chain state of ownership renunciation to confirm the absence of centralized control.

Contract & Record

1 audit on record
TypeToken
NetworkEthereum
Token age2y
Contract0x3ffe…5790
Deployer0xeddd…aafc
Badge for your website
PeiPei 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. Sep 4, 20260Low

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

Related Audits

6 more on the recordAll audits
AsteroidEthereum0LowAmerica PacPAC · Ethereum0LowJerry The Turtle By Matt FurieJYAI · Ethereum0LowNon-Playable CoinNPC · Ethereum0LowYee TokenYEE · Ethereum0LowPikachuEthereum0Low

Would You Like a More Detailed Audit of PeiPei?

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