Quantum Audit Logo
Launch App

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

Is Ping Safe?

PINGBase
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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance1/10Upgrades8/10Checks passed6 of 7Findings1 High · 1 Medium · 1 Info3
SummaryAI Copilot

The Ping token contract implements ERC20 functionality with EIP-2612-like authorization and a controlled minting mechanism.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • Liquidity not locked
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
Exact factors
  • Top-10 concentration > 30% (51.5% total → 30.6% effective; 16.6% in EOAs, 35.0% in contracts — moderate)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • LP top1 unlocked holder = 100.0% (exit-liquidity risk, pool = 97% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (exit-liquidity risk, pool = 97% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium 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 46 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
35.0%Contracts16.6%Wallets48.5%Everyone else
35.0%Contracts16.6%Wallets48.5%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
51.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking35.0%
  • Walletsanonymous holders, free to sell16.6%
  • Everyone elsethe rest of the supply48.5%
Effective concentrationwhat the score reads30.6%
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$368.9K across 18 pairs
Show 4 more pairs

The 8 remaining pairs hold $172 between them and are not listed. The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$356.9KShare of depth96.7%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xd85c…9d460xde9d…108d0xd2e3…6375

Security Findings

1 High1 Medium1 Info
High

Critical State if Liquidity Deployment Fails

The _initializePoolAndDeployLiquidity function is called automatically when _mintCount reaches MAX_MINT_COUNT. If this function, which involves external calls to Uniswap V4 IPoolManager and IPositionManager, fails for any reason (e.g., insufficient funds, network issues, or unexpected hook behavior), the _mintCount will already be updated, and MAX_MINT_COUNT will be reached. This prevents further minting and leaves the contract in a state where the intended liquidity was not deployed, potentially rendering the token illiquid or unusable as intended. There is no retry mechanism or emergency fallback to deploy liquidity manually.H-01

Issue

The _initializePoolAndDeployLiquidity function is called automatically when _mintCount reaches MAX_MINT_COUNT. If this function, which involves external calls to Uniswap V4 IPoolManager and IPositionManager, fails for any reason (e.g., insufficient funds, network issues, or unexpected hook behavior), the _mintCount will already be updated, and MAX_MINT_COUNT will be reached. This prevents further minting and leaves the contract in a state where the intended liquidity was not deployed, potentially rendering the token illiquid or unusable as intended. There is no retry mechanism or emergency fallback to deploy liquidity manually.

Fix

Implement robust error handling and a recovery mechanism for liquidity deployment. Consider adding a _liquidityDeployed flag that is only set upon successful deployment, and allow the MINTER_ROLE or DEFAULT_ADMIN_ROLE to re-attempt deployment if it initially fails, or to manually deploy liquidity if the automatic process is stuck. This could involve a separate callable function for the admin to trigger liquidity deployment if the automatic one fails.

Status

Unresolved

Medium

Fixed Initial Liquidity Parameters

The POOL_SEED_AMOUNT, PAYMENT_SEED, SQRT_PRICE_PAYMENT_TOKEN_FIRST, and SQRT_PRICE_PING_FIRST are set as immutable variables in the constructor. These parameters dictate the initial liquidity provision and price for the Uniswap V4 pool. While immutability provides certainty, fixing these values at deployment means there is no flexibility to adjust them based on market conditions or unforeseen circumstances leading up to the liquidity deployment event (which occurs only after MAX_MINT_COUNT is reached). This could result in suboptimal initial liquidity, significant impermanent loss, or an unfavorable initial price for the token.M-01

Issue

The POOL_SEED_AMOUNT, PAYMENT_SEED, SQRT_PRICE_PAYMENT_TOKEN_FIRST, and SQRT_PRICE_PING_FIRST are set as immutable variables in the constructor. These parameters dictate the initial liquidity provision and price for the Uniswap V4 pool. While immutability provides certainty, fixing these values at deployment means there is no flexibility to adjust them based on market conditions or unforeseen circumstances leading up to the liquidity deployment event (which occurs only after MAX_MINT_COUNT is reached). This could result in suboptimal initial liquidity, significant impermanent loss, or an unfavorable initial price for the token.

Fix

Evaluate if these parameters truly need to be immutable. If flexibility is desired, consider making them configurable by a trusted role (e.g., DEFAULT_ADMIN_ROLE) before liquidity deployment, or implement a mechanism to allow the owner to adjust liquidity post-deployment if initial conditions are not met. This would allow for better adaptation to market dynamics.

Status

Unresolved

Info

Redundant Ownable Inheritance

The Ping contract inherits both AccessControl and Ownable. While AccessControl is used for defining MINTER_ROLE and DEFAULT_ADMIN_ROLE, the Ownable inheritance adds an owner() function and transferOwnership()/renounceOwnership() methods that are not explicitly used or integrated with the AccessControl roles. This creates a slight redundancy and potential for confusion regarding the primary access control mechanism, although _grantRole(DEFAULT_ADMIN_ROLE, msg.sender) effectively makes the deployer the admin.I-01

Issue

The Ping contract inherits both AccessControl and Ownable. While AccessControl is used for defining MINTER_ROLE and DEFAULT_ADMIN_ROLE, the Ownable inheritance adds an owner() function and transferOwnership()/renounceOwnership() methods that are not explicitly used or integrated with the AccessControl roles. This creates a slight redundancy and potential for confusion regarding the primary access control mechanism, although _grantRole(DEFAULT_ADMIN_ROLE, msg.sender) effectively makes the deployer the admin.

Fix

Remove the Ownable inheritance if AccessControl is intended to be the sole access control mechanism. Ensure that all owner-like functionalities are managed through DEFAULT_ADMIN_ROLE or other specific roles defined in AccessControl to maintain a single, clear access control model.

Status

Unresolved

Analysis

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

The Ping token contract implements ERC20 functionality with EIP-2612-like authorization and a controlled minting mechanism. It integrates with Uniswap V4 for automatic liquidity deployment upon reaching a maximum mint count. While leveraging OpenZeppelin libraries for core functionalities and access control, a critical vulnerability exists in the liquidity deployment process, which lacks robust error handling, potentially leaving the token illiquid. Additionally, fixed initial liquidity parameters introduce economic inflexibility.

Technical8/10Low risk

The contract leverages OpenZeppelin libraries for ERC20, AccessControl, and EIP712, enhancing code security and adherence to standards (7.2 Code Security). The EIP-2612-like authorization mechanism with nonces and time-based validity is well-implemented, preventing replay attacks (7.2 Code Security). However, a critical vulnerability exists where the automatic Uniswap V4 liquidity deployment, triggered upon reaching MAX_MINT_COUNT, lacks robust error handling (7.6 External, 7.8 Operations). If this external call fails, the token's intended liquidity provision could be permanently stalled, rendering the token illiquid.

Governance1/10High risk

The contract utilizes AccessControl with MINTER_ROLE and DEFAULT_ADMIN_ROLE, granting the deployer significant control over token minting and administrative functions (7.3 Access Control, 7.5 Governance). The batchMint function includes checks for MAX_MINT_COUNT and txHashes to prevent over-minting and double-spending, contributing to economic stability (7.4 Economic). A key economic risk is the immutability of initial liquidity parameters (POOL_SEED_AMOUNT, SQRT_PRICE_PAYMENT_TOKEN_FIRST). These fixed values, set at deployment, cannot be adjusted to dynamic market conditions, potentially leading to suboptimal liquidity provision or unfavorable initial pricing when the pool is finally created (7.4 Economic).

Upgrades8/10Low risk

The Ping contract is implemented as a standard, non-upgradeable contract (7.7 Upgrades). It does not utilize any proxy patterns (e.g., UUPS, Transparent) or other upgradeability mechanisms. This design choice eliminates upgrade-related risks such as proxy misconfigurations, storage collisions, or insecure upgrade paths. However, it also means that any discovered vulnerabilities or desired feature enhancements would require a complete redeployment and migration of assets.

Final RecommendationWhat to do about this score

Prioritize implementing robust error handling and a recovery mechanism for the Uniswap V4 liquidity deployment process.

This is crucial to ensure the token's intended functionality and prevent it from becoming illiquid if the initial deployment fails. Additionally, review the immutability of initial liquidity parameters to determine if a more flexible approach, allowing for adjustments by a trusted role, would better serve the protocol's long-term economic health.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age10mo
Contract0xd85c…9d46
Deployer0xdbd1…a43e
Badge for your website
Ping 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, 202650Medium
  2. Sep 3, 202671High

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

Frequently Asked Questions

What is the PING contract address?

The Ping contract on Base is 0xd85c31854c2b0fb40aaa9e2fc4da23c21f829d46. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Ping a scam?

Quantum Audit's risk score for Ping is 50/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is PING liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $368.9K.

Who holds PING?

As of Sep 4, 2026, the 10 largest holders own 51.5% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Metronome Synth ETHMSETH · Base50MediumOpenUSDTOUSDT · Base50MediumCATALYSTBase50MediumGROOVEBase50MediumVenice TokenVVV · Base51MediumAvantisAVNT · Base49Medium

Would You Like a More Detailed Audit of Ping?

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