Quantum Audit Logo

Is Ping Safe?

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

Ping PING
0xd85c…9d46
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 High1 Medium1 Informational
Volume 24h
$9.2K
Liquidity
$356.9K
Price
$0.0006368
Token Age
10mo
Top 10 Holders
51.5%

Security Findings

1 High1 Med1 Info
High

Critical State if Liquidity Deployment Fails

H-01The `_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.
IssueThe `_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.
FixImplement 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.
StatusUnresolved
Medium

Fixed Initial Liquidity Parameters

M-01The `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.
IssueThe `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.
FixEvaluate 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.
StatusUnresolved
Info

Redundant Ownable Inheritance

I-01The `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.
IssueThe `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.
FixRemove 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceHigh1/10

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

UpgradesLow8/10

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.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

51.5% in top 10
16.6% in wallets35.0% in contracts
Effective Concentration30.6%

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

$368.9K across 18 pairs
Uniswap v4USDCanalysed$356.9K96.7%Uniswap v4ETH$4.9K1.3%Uniswap v3USDC$2.8K0.7%AerodromeWETH$2.3K0.6%Uniswap v4USDC$5900.2%Uniswap v4ETH$3990.1%
Show 4 more pairsShow less
Uniswap v4USDC$2790.1%Uniswap v3WETH$2770.1%Hydrex CLAMMUSDC$2610.1%Uniswap v4USDC$1550.0%

The 8 remaining pairs hold $172 between them and are not listed.

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

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0xdbd1…a43e
Unlocked LP Held By
0xd85c…9d460xde9d…108d0xd2e3…6375

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

What Raised This Score

6 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

Related Audits

6 more on the record
Metronome Synth ETH (MSETH)High RiskOpenUSDT (OUSDT)High RiskVenice Token (VVV)High RiskAvantis (AVNT)High RiskSupergemma4-26b-multimodal (SUPERGEMMA)High RiskACUHigh Risk

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