Quantum Audit Logo

Is 00 Token Safe?

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

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

00 Token 00
0x881b…250d
Ethereum Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 High1 Low2 Informational
Volume 24h
$94.8K
Liquidity
$464.7K
Price
$0.01929
Token Age
1y
Top 10 Holders
89.5%

Security Findings

1 High1 Low2 Info
High

Unlimited Allowance Granted to `xCreatorToken`

H-01The `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.
IssueThe `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.
FixRe-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…
StatusUnresolved
Low

Broad Solidity Pragma Version

L-01The 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.
IssueThe 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.
FixPin the Solidity pragma to a specific compiler version used for deployment, for example, `pragma solidity 0.8.13;` to ensure consistent compilation results.
StatusUnresolved
Info

Constructor `initializer()` Call in Upgradeable Implementation

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

Inter-Contract Dependency on `xCreatorToken` Security

I-02The `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.
IssueThe `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.
FixEnsure 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceHigh3/10

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

UpgradesHigh2/10

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

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

89.5% in top 10
18.6% in wallets70.9% in contracts
Effective Concentration47.0%

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

$464.7K

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

2 addresses
Deployer
0x4f05…2d94
Unlocked LP Held By
0xb554…1b0f

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

What Raised This Score

9 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

Related Audits

6 more on the record
MorphoHigh RiskBeamHigh RiskSuperVerse (SUPER)High RiskIxs Token (IXS)High RiskAlberich Token (ALBRH)High RiskSpice (SFI)High Risk

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