Quantum Audit Logo
Launch App

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

Is 00 Token Safe?

00Ethereum
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/10Governance3/10Upgrades2/10Checks passed2 of 5Findings1 High · 1 Low · 2 Info4
SummaryAI Copilot

The P00lsTokenCreator contract serves as an ERC-20 token with Merkle drop functionality, deployed as an upgradeable implementation behind a BeaconProxy.

Read the full analysis
What raised the score
  • Ownership not renounced — Multisig
  • Proxy contract
  • Non-standard proxy storage
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — Multisig (2-of-4)
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Top-10 concentration > 30% (89.5% total → 47.0% effective; 18.6% in EOAs, 70.9% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 High finding(s) from audit
  • 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
70.9%Contracts18.6%Wallets10.5%Everyone else
70.9%Contracts18.6%Wallets10.5%
ContractsWalletsEveryone elseBubble area = share of supply
89.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking70.9%
  • Walletsanonymous holders, free to sell18.6%
  • Everyone elsethe rest of the supply10.5%
Effective concentrationwhat the score reads47.0%
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$464.7K

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$464.7KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xb554…1b0f

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

Security Findings

1 High1 Low2 Info
High

Unlimited Allowance Granted to xCreatorToken

The allowance function in P00lsTokenCreator is overridden to return type(uint256).max for the xCreatorToken address. This design choice grants the xCreatorToken contract unlimited spending approval over all token holders' balances within this contract. This represents a significant trust assumption and a potential single point of failure. If xCreatorToken is compromised, exploited, or behaves maliciously, it could lead to the draining of all P00lsTokenCreator tokens from users who have approved this contract.H-01

Issue

The allowance function in P00lsTokenCreator is overridden to return type(uint256).max for the xCreatorToken address. This design choice grants the xCreatorToken contract unlimited spending approval over all token holders' balances within this contract. This represents a significant trust assumption and a potential single point of failure. If xCreatorToken is compromised, exploited, or behaves maliciously, it could lead to the draining of all P00lsTokenCreator tokens from users who have approved this contract.

Fix

Re-evaluate the necessity of granting unlimited allowance to xCreatorToken. If possible, implement a more granular allowance mechanism (e.g., specific amounts, time-bound approvals, or a pull-based system). If unlimited allowance is critical for functionality, ensure xCreatorToken undergoes rigorous security audits, has robust access control, and is managed by a highly secure entity (e.g., a multi-sig or DAO). Consider implementing circuit breakers or emergency pause mechanisms in `xCreator…

Status

Unresolved

Low

Broad Solidity Pragma Version

The contract uses pragma solidity ^0.8.0;. This allows compilation with any 0.8.x version. While minor version updates are generally backward-compatible, it is a best practice to pin the pragma to a specific compiler version (e.g., pragma solidity 0.8.13;) to ensure consistent bytecode generation and avoid potential issues with future compiler updates that might introduce subtle changes or new warnings.L-01

Issue

The contract uses pragma solidity ^0.8.0;. This allows compilation with any 0.8.x version. While minor version updates are generally backward-compatible, it is a best practice to pin the pragma to a specific compiler version (e.g., pragma solidity 0.8.13;) to ensure consistent bytecode generation and avoid potential issues with future compiler updates that might introduce subtle changes or new warnings.

Fix

Pin the Solidity pragma to a specific compiler version used for deployment, for example, pragma solidity 0.8.13; to ensure consistent compilation results.

Status

Unresolved

Info

Constructor initializer() Call in Upgradeable Implementation

The P00lsTokenCreator constructor calls initializer(). In a BeaconProxy setup, the constructor of the implementation contract is called only once upon its deployment, not when the proxy is initialized. The initialize function, which also uses initializer(), is the one called via the proxy to set up the contract's state. While this constructor call is harmless as it only sets an internal flag that initialize also sets, it is redundant and can be confusing. The primary protection against re-initialization for proxy contracts comes from the initializer modifier on the initialize function itself.I-01

Issue

The P00lsTokenCreator constructor calls initializer(). In a BeaconProxy setup, the constructor of the implementation contract is called only once upon its deployment, not when the proxy is initialized. The initialize function, which also uses initializer(), is the one called via the proxy to set up the contract's state. While this constructor call is harmless as it only sets an internal flag that initialize also sets, it is redundant and can be confusing. The primary protection against re-initialization for proxy contracts comes from the initializer modifier on the initialize function itself.

Fix

Consider removing the initializer() call from the constructor of the implementation contract, as it is not strictly necessary for the proxy's upgradeability logic and can be misleading. The initialize function's initializer() modifier is sufficient.

Status

Unresolved

Info

Inter-Contract Dependency on xCreatorToken Security

The P00lsTokenCreator contract has a strong dependency on the xCreatorToken contract. Specifically, the _delegate function mirrors delegation calls to xCreatorToken.__delegate, and xCreatorToken is granted unlimited allowance (as noted in H-01). This tight coupling means that the overall security and integrity of P00lsTokenCreator are directly tied to the security and trustworthiness of xCreatorToken. Any vulnerability, exploit, or malicious behavior within xCreatorToken could directly impact P00lsTokenCreator and its users.I-02

Issue

The P00lsTokenCreator contract has a strong dependency on the xCreatorToken contract. Specifically, the _delegate function mirrors delegation calls to xCreatorToken.__delegate, and xCreatorToken is granted unlimited allowance (as noted in H-01). This tight coupling means that the overall security and integrity of P00lsTokenCreator are directly tied to the security and trustworthiness of xCreatorToken. Any vulnerability, exploit, or malicious behavior within xCreatorToken could directly impact P00lsTokenCreator and its users.

Fix

Ensure that the xCreatorToken contract undergoes equally rigorous security audits and adheres to the highest security standards. Implement robust monitoring for xCreatorToken's behavior and consider mechanisms to decouple or mitigate risks associated with this dependency if possible.

Status

Unresolved

Analysis

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

The P00lsTokenCreator contract serves as an ERC-20 token with Merkle drop functionality, deployed as an upgradeable implementation behind a BeaconProxy. It leverages OpenZeppelin's upgradeable contracts and a RegistryOwnable pattern for access control. While the core ERC-20 and Merkle drop logic appears sound, a significant design decision grants unlimited allowance to an external xCreatorToken contract, posing a high economic risk if that dependency is compromised. Minor informational findings relate to upgradeability nuances and external dependencies.

Technical8/10Low risk

The contract demonstrates good technical architecture, inheriting from well-audited OpenZeppelin upgradeable contracts for ERC-20, ERC-20Votes, Multicall, and ERC-1363 functionalities (7.1 Architecture). The Merkle drop mechanism for token claims is correctly implemented using MerkleProof.verify and BitMaps to prevent double claims (7.2 Code Security). The ERC1363Upgradeable functions include try/catch blocks for external calls, mitigating some reentrancy risks. A minor issue is the broad Solidity pragma ^0.8.0, which could lead to inconsistent compilation across different minor versions.

Governance3/10High risk

Access control is managed through a RegistryOwnable pattern, allowing for flexible and potentially multi-sig ownership, which is a robust approach (7.3 Access Control, 7.5 Governance). However, a significant economic risk exists due to the allowance function being overridden to grant type(uint256).max approval to the xCreatorToken contract (7.4 Economic). This means xCreatorToken has unlimited spending power over all token holders' balances, creating a single point of failure if xCreatorToken is compromised. Additionally, the _delegate function mirrors delegation calls to xCreatorToken, tightly coupling the governance of the two tokens (7.5 Governance).

Upgrades2/10High risk

The contract is designed as an upgradeable implementation for a BeaconProxy, correctly utilizing OpenZeppelin's initializer() modifier to prevent re-initialization on upgrades (7.7 Upgrades). All state variables are added at the end of the contract, maintaining storage layout compatibility with inherited upgradeable contracts. A minor observation is the redundant initializer() call in the constructor of the implementation, which is harmless but not strictly necessary for proxy functionality (7.1 Architecture).

Final RecommendationWhat to do about this score

Prioritize addressing the high-severity finding regarding the unlimited allowance granted to xCreatorToken.

Evaluate if this level of trust is absolutely necessary and explore alternative, more granular approval mechanisms or robust security measures for xCreatorToken. Pin the Solidity pragma to a specific version to ensure consistent compilation. Review the necessity of the initializer() call in the constructor of the implementation contract for clarity, although it poses no direct security risk.

Contract & Record

1 audit on record
TypeBeaconProxy
NetworkEthereum
Token age1y
Contract0x881b…250d
Deployer0x4f05…2d94
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
00 Token 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. Aug 13, 202654Medium

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

Related Audits

6 more on the recordAll audits
MorphoEthereum54MediumBeamEthereum54MediumSuperVerseSUPER · Ethereum54MediumIxs TokenIXS · Ethereum54MediumAlberich TokenALBRH · Ethereum54MediumSpiceSFI · Ethereum54Medium

Would You Like a More Detailed Audit of 00 Token?

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