Quantum Audit Logo

Is PRDCTR Safe?

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

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

PRDCTR PRD
0xc847…efe5
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The audit of the ConfigurableTokenUpgradeable contract, deployed via an ERC1967Proxy, reveals a well-structured and minimal ERC-20 token implementation. The contract leverages battle-tested OpenZeppelin upgradeable libraries for ERC-20, ERC-20 Permit, Ownable, and UUPS functionality. No critical or high-severity vulnerabilities were identified. Minor observations include the custom decimals implementation and the reinitializer for ERC20Permit. Centralized control by the owner (a multisig) for upgrades and initial configuration is noted, which is typical for such tokens.

1 Low2 Informational
Volume 24h
$83.6K
Liquidity
$6.32M
Price
$0.0008639
Token Age
1mo
Top 10 Holders
95.8%

Security Findings

1 Low2 Info
Low

Centralized Control by Owner

L-01The `ConfigurableTokenUpgradeable` contract grants significant control to the contract owner, including the ability to authorize contract upgrades (`_authorizeUpgrade`), transfer ownership, and renounce ownership. The initial token configuration (name, symbol, decimals, initial supply, initial holder) is also set by the owner during initialization. The prefill indicates the owner is a 2/4 multisig.
IssueThe `ConfigurableTokenUpgradeable` contract grants significant control to the contract owner, including the ability to authorize contract upgrades (`_authorizeUpgrade`), transfer ownership, and renounce ownership. The initial token configuration (name, symbol, decimals, initial supply, initial holder) is also set by the owner during initialization. The prefill indicates the owner is a 2/4 multisig.
FixWhile the use of a multisig wallet for ownership significantly mitigates the risk of a single point of failure, it is crucial that the multisig signers are trustworthy, follow robust operational security practices, and that the multisig threshold is appropriate for the protocol's risk profile. Consider implementing time-locks for critical operations like upgrades if further decentralization or safety is desired.
StatusUnresolved
Info

Custom Decimals Implementation

I-01The `ConfigurableTokenUpgradeable` contract overrides the `decimals()` function from `ERC20Upgradeable` to return a custom `_decimals` value set during initialization, rather than the default 18. While this provides flexibility, it deviates from the common ERC-20 standard of 18 decimals.
IssueThe `ConfigurableTokenUpgradeable` contract overrides the `decimals()` function from `ERC20Upgradeable` to return a custom `_decimals` value set during initialization, rather than the default 18. While this provides flexibility, it deviates from the common ERC-20 standard of 18 decimals.
FixEnsure all integrations and user interfaces are aware of and correctly handle the token's configurable decimal count to prevent display issues or misinterpretations. Clearly document this design choice in external documentation.
StatusUnresolved
Info

Reinitializer for ERC20Permit

I-02The `initializePermit()` function is marked as a `reinitializer(2)`, allowing it to be called multiple times if the reinitialization flag for slot 2 is reset. This function re-initializes the `ERC20Permit` component by calling `__ERC20Permit_init(name())`.
IssueThe `initializePermit()` function is marked as a `reinitializer(2)`, allowing it to be called multiple times if the reinitialization flag for slot 2 is reset. This function re-initializes the `ERC20Permit` component by calling `__ERC20Permit_init(name())`.
FixConfirm the specific use case and necessity for `ERC20Permit` re-initialization. While generally safe, ensure that repeated calls do not introduce unexpected state changes or gas inefficiencies if not genuinely required.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture (7.1) is robust, utilizing OpenZeppelin's upgradeable contracts for ERC-20, ERC-20 Permit, Ownable, and UUPS proxy patterns. Code security (7.2) is high, benefiting from OpenZeppelin's audited codebase and Solidity 0.8+ default overflow/underflow checks. The contract correctly implements unstructured storage for upgradeability, preventing storage collisions. A notable design choice is the custom `decimals()` override, allowing for flexible token configurations.

GovernanceHigh1/10

The economic model (7.4) is that of a standard ERC-20 token with an initial supply minted to a specified holder. Governance (7.5) is centralized, with the contract owner having control over initial token parameters and upgrades. The prefill indicates the owner is a 2/4 multisig, which enhances security by requiring multiple approvals for critical actions, mitigating single-point-of-failure risks. However, the owner retains significant power over the token's future.

UpgradesHigh1/10

The contract implements the UUPS upgrade pattern (7.7), with the `_authorizeUpgrade` function correctly restricted to the `onlyOwner` modifier. This ensures that only the designated owner can initiate contract upgrades. The use of OpenZeppelin's upgradeable contracts with explicit storage structs and gaps minimizes the risk of storage collisions during upgrades, contributing to a secure upgrade path. The primary risk remains the owner's ability to upgrade to potentially malicious code.

Security Checklist

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

Proxy Upgrade Controls

Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

95.8% in top 10
1.1% in wallets94.7% in contracts
Effective Concentration39.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

$6.32M across 2 pairs
Uniswap v3USDTanalysed$6.32M100.0%Uniswap v4USDC$460.0%

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
0x528e…a5c2
Unlocked LP Held By
0x528e…a5c20x9da9…b37b0x7e5c…6c50

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

7 factors
  • Ownership NOT renounced — Multisig (2-of-4)
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (95.8% total → 39.0% effective; 1.1% in EOAs, 94.7% in contracts — moderate)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • LP top1 unlocked holder = 100.0% (exit-liquidity risk)
  • LP top3 unlocked holders = 100.0% (exit-liquidity risk)
  • 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
Espresso (ESP)High RiskAXGTHigh RiskSPACE ID (ID)High RiskWrapped Pulse from PulseChain (WPLS)High RiskUSDS Stablecoin (USDS)High RiskMarlin POND (POND)High Risk

Would You Like a More Detailed Audit of PRDCTR?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit