Quantum Audit Logo

Is Paimon Polymarket SPV Token a Scam?

Early-stage security check — honeypot & rug-pull analysis

Is this your token? Publish your own audit on this page →

Paimon Polymarket SPV Token PPOLY
0x1d80…7fe6
BNB Chain
Not verifiedThis 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 today 1 audit on record New Launch · 1d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The PreIPOToken contract implements a standard ERC-20 token with Pausable functionality, largely following OpenZeppelin patterns. The contract is well-structured and utilizes recent Solidity features like custom errors and `unchecked` blocks for gas optimization where safe. Key functionalities like minting, burning, and pausing are implemented as internal functions, implying a fixed supply and non-pausable token unless a derived contract exposes these with appropriate access control. The overall risk is assessed as Low due to the contract's simplicity and adherence to established patterns, with minor informational findings.

1 Low2 Informational
! Early-stage analysis. This token has limited on-chain history (1d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$5.14M
Liquidity
$1.08M
Price
$18.9300
Token Age
1d
Top 10 Holders
52.6%

Security Findings

1 Low2 Info
Low

Missing External Access Control for Core Functions

L-01The `_mint`, `_burn`, `_pause`, and `_unpause` functions are implemented as `internal virtual`. This means that the `PreIPOToken` contract itself does not expose these functionalities externally. If the intention is for the token supply to be mutable or for the token to be pausable, a derived contract must implement external functions with appropriate access control (e.g., `onlyOwner` or a multi-sig mechanism) to call these internal functions. Without such external wrappers, the token's supply is fixed after initial deployment (if `_mint` is called in constructor) and the pausing mechanism is unusable.
IssueThe `_mint`, `_burn`, `_pause`, and `_unpause` functions are implemented as `internal virtual`. This means that the `PreIPOToken` contract itself does not expose these functionalities externally. If the intention is for the token supply to be mutable or for the token to be pausable, a derived contract must implement external functions with appropriate access control (e.g., `onlyOwner` or a multi-sig mechanism) to call these internal functions. Without such external wrappers, the token's supply is fixed after initial deployment (if `_mint` is called in constructor) and the pausing mechanism is unusable.
FixIf minting, burning, or pausing capabilities are desired, implement a derived contract that exposes these functionalities via external functions, protected by robust access control mechanisms (e.g., OpenZeppelin's `Ownable` or a Gnosis Safe). If the intention is for a fixed-supply, non-pausable token, ensure this design choice is clearly documented.
StatusUnresolved
Info

Standard ERC-20 `approve` Race Condition

I-01The `approve` function in the ERC-20 standard is susceptible to a known front-running vulnerability. If a user increases an existing allowance for a spender, a malicious actor could front-run this transaction, spend the original allowance, and then the user's new allowance would also be spent, leading to a double-spend of the intended allowance amount. This is a limitation of the ERC-20 standard itself, not a flaw in this specific implementation.
IssueThe `approve` function in the ERC-20 standard is susceptible to a known front-running vulnerability. If a user increases an existing allowance for a spender, a malicious actor could front-run this transaction, spend the original allowance, and then the user's new allowance would also be spent, leading to a double-spend of the intended allowance amount. This is a limitation of the ERC-20 standard itself, not a flaw in this specific implementation.
FixUsers should be advised to first set their allowance to zero before increasing it to a new value. Alternatively, consider using `increaseAllowance` and `decreaseAllowance` functions (if implemented) which mitigate this specific race condition, though they are not part of the core ERC-20 standard.
StatusUnresolved
Info

Unused `SafeIntrospection` Library

I-02The `SafeIntrospection` library is included in the provided source code, but its functions are not called or utilized by the `PreIPOToken` contract. Including unused libraries can increase contract bytecode size and potentially introduce unnecessary complexity, even if the library itself is secure.
IssueThe `SafeIntrospection` library is included in the provided source code, but its functions are not called or utilized by the `PreIPOToken` contract. Including unused libraries can increase contract bytecode size and potentially introduce unnecessary complexity, even if the library itself is secure.
FixRemove the `SafeIntrospection` library if it is not intended to be used by `PreIPOToken` or any directly derived contracts. If it is part of a larger codebase and intended for future use by other components, ensure its inclusion is justified.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates good technical architecture (7.1) by inheriting from well-audited OpenZeppelin-like ERC20 and Pausable base contracts. Code security (7.2) is strong, utilizing Solidity 0.8.35 with default overflow/underflow checks and safe `unchecked` blocks for optimization. Custom error handling is implemented, enhancing clarity and gas efficiency. However, core functionalities like minting, burning, and pausing are only exposed internally, which might be a design choice but limits external control (7.3).

GovernanceHigh2/10

The economic model (7.4) for PreIPOToken appears to be a fixed-supply token, as `_mint` and `_burn` functions are internal and not exposed externally. This design choice simplifies the economic dynamics and reduces certain risks associated with inflationary/deflationary mechanisms. There are no explicit governance mechanisms (7.5) implemented within this contract, which is typical for a simple token. The lack of external minting/burning capabilities contributes to a predictable supply, minimizing economic manipulation risks.

UpgradesHigh3/10

The PreIPOToken contract is not designed as an upgradeable proxy (7.7). It is an immutable contract, meaning its logic cannot be changed after deployment. This design choice eliminates upgrade-related risks such as proxy storage collisions or faulty upgrade implementations. Any changes to the token's functionality would require deploying a new contract and migrating users, which is a standard approach for non-upgradeable tokens.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

52.6% in top 10
11.4% in wallets41.2% in contracts
Effective Concentration27.9%

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

$2.31M across 16 pairs
UniswapUSDTanalysed$1.08M46.9%Pancakeswap v3USDT$931.5K40.3%UniswapUSDT$221.5K9.6%Pancakeswap v3USDT$33.8K1.5%Pancakeswap v3USDT$24.9K1.1%Pancakeswap v3U$7.4K0.3%
Show 4 more pairsShow less
Pancakeswap v3WBNB$4.3K0.2%Pancakeswap v3U$3.8K0.2%Pancakeswap v3Cake$1.2K0.1%UniswapUSDC$990.0%

The 6 remaining pairs hold $1 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 Holder94.9%
Top-3 Unlocked97.9%

Key Addresses

11 addresses
Deployer
0x0b12…ca27
Unlocked LP Held By
0xf3af…28050xaac6…3e340x3dd9…8c820xca68…a8880xc224…243a0x4d82…e4360x9365…44190xf81b…043b0xcd6e…7a700x4308…157b

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

What Raised This Score

8 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 20% (52.6% total → 27.9% effective; 11.4% in EOAs, 41.2% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 94.9% (independent LP — depth risk, pool = 47% of DEX liquidity)
  • LP top3 unlocked holders = 97.9% (independent LP — depth risk, pool = 47% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 1 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

Related Audits

6 more on the record
UnifAI (UAI)Medium RiskAIW3Medium Risk吉祥马Medium RiskARAI Token (AA)Medium RiskCZBURN (CBURN)Medium RiskCSI888 (CSI)High Risk

Would You Like a More Detailed Audit of Paimon Polymarket SPV Token?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit