Is PeiPei Safe? Smart Contract Security Analysis

Security Findings

2 Low3 Info

Low

Incomplete `Ownable` Contract Provided

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

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

FixProvide 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).

StatusUnresolved

Low

Missing NatSpec Documentation

L-02Several 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.

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

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

StatusUnresolved

Info

Use of SafeMath Library

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

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

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

StatusResolved

Info

Adherence to ERC20 Standard

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

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

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

StatusResolved

Info

Internal Mint/Burn Functions

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

IssueThe `_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).

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

StatusResolved

Category Ratings

TechnicalLow10/10

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

GovernanceLow9/10

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.

UpgradesLow10/10

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.

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

39.9% in top 10

27.8% in wallets12.1% in contracts

Effective Concentration32.7%

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

$644.6K across 5 pairs

Uniswap v2WETHanalysed$639.2K Uniswap v3WETH$4.5K Uniswap v4TrumpBucks$612 Uniswap v4USDT$182 Uniswap v4ETH$132

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 Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Key Addresses

5 addresses

Deployer

0xeddd…aafc

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.

What Raised This Score

2 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

Is PeiPei Safe?

Security Findings

Incomplete `Ownable` Contract Provided

Missing NatSpec Documentation

Use of SafeMath Library

Adherence to ERC20 Standard

Internal Mint/Burn Functions

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 PeiPei?