Quantum Audit Logo

Is Wrapped Pearl Safe?

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

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

Wrapped Pearl WPRL
0x0769…cb00
Ethereum
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 4d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The WPearl contract implements an upgradeable ERC-20 token with custom freezing capabilities and a fixed maximum supply. It leverages OpenZeppelin's upgradeable contracts and access control mechanisms. While the core logic is sound and standard patterns are used, significant power is concentrated in administrative roles, and a token rescue function is absent. The upgrade mechanism includes a timelock and upward-only delay, enhancing security.

1 High1 Medium1 Low1 Informational
Volume 24h
$335.1K
Liquidity
$236.1K
Price
$0.9209
Token Age
4mo
Top 10 Holders
49.2%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control of Critical Functions

H-01The `DEFAULT_ADMIN_ROLE` possesses extensive power, including the ability to grant/revoke all other roles (e.g., `bridgeController`, `FREEZER_ROLE`, `REVOKE_FREEZE_ROLE`), propose/cancel upgrades, and adjust the upgrade delay. The `bridgeController` role has sole authority to `mint` new tokens (up to `MAX_SUPPLY`) and `burnFrom` any account. The `FREEZER_ROLE` can freeze and unfreeze accounts, impacting token transferability. While `AccessControlDefaultAdminRulesUpgradeable` provides an initial delay for admin actions, the concentration of power in these roles represents a significant centralization risk. A compromise of the keys controlling these roles could lead to severe consequences suc…
IssueThe `DEFAULT_ADMIN_ROLE` possesses extensive power, including the ability to grant/revoke all other roles (e.g., `bridgeController`, `FREEZER_ROLE`, `REVOKE_FREEZE_ROLE`), propose/cancel upgrades, and adjust the upgrade delay. The `bridgeController` role has sole authority to `mint` new tokens (up to `MAX_SUPPLY`) and `burnFrom` any account. The `FREEZER_ROLE` can freeze and unfreeze accounts, impacting token transferability. While `AccessControlDefaultAdminRulesUpgradeable` provides an initial delay for admin actions, the concentration of power in these roles represents a significant centralization risk. A compromise of the keys controlling these roles could lead to severe consequences suc…
FixEnsure that the `DEFAULT_ADMIN_ROLE` and `bridgeController` are controlled by robust multi-signature wallets with high thresholds, or a well-governed DAO. Implement strict operational security procedures, including multi-party approval and time-locks for critical actions, to mitigate the risk of a single point of failure or key compromise.
StatusUnresolved
Medium

Missing Emergency Token Rescue Function

M-01The contract lacks a function to rescue accidentally sent ERC-20 tokens (other than WPRL itself) or native currency. If any other token or ETH is mistakenly transferred to the contract address, it will be permanently locked and inaccessible, leading to irretrievable loss of funds. (7.8 Operations)
IssueThe contract lacks a function to rescue accidentally sent ERC-20 tokens (other than WPRL itself) or native currency. If any other token or ETH is mistakenly transferred to the contract address, it will be permanently locked and inaccessible, leading to irretrievable loss of funds. (7.8 Operations)
FixImplement a `rescueTokens(address tokenAddress, address to, uint256 amount)` function, restricted to the `DEFAULT_ADMIN_ROLE`, to allow recovery of mistakenly sent tokens. This function should explicitly prevent the rescue of the contract's own token (`address(this)`) to avoid accidental draining of the token supply.
StatusUnresolved
Low

Permanent Revocation of Freeze Ability

L-01The `revokeFreezeAbility()` function, callable by `REVOKE_FREEZE_ROLE`, permanently sets `freezeAbilityRevoked = true` if `frozenCount == 0`. Once this flag is set, the `FREEZER_ROLE` can no longer be granted, and accounts cannot be frozen or unfrozen. This is an irreversible state change designed to permanently disable the freeze mechanism. While intentional, it represents a critical, one-time decision with lasting implications for the token's censorship resistance. (7.3 Access Control, 7.4 Economic)
IssueThe `revokeFreezeAbility()` function, callable by `REVOKE_FREEZE_ROLE`, permanently sets `freezeAbilityRevoked = true` if `frozenCount == 0`. Once this flag is set, the `FREEZER_ROLE` can no longer be granted, and accounts cannot be frozen or unfrozen. This is an irreversible state change designed to permanently disable the freeze mechanism. While intentional, it represents a critical, one-time decision with lasting implications for the token's censorship resistance. (7.3 Access Control, 7.4 Economic)
FixEnsure that the implications of `revokeFreezeAbility` are fully understood by the `REVOKE_FREEZE_ROLE` holders. If not already covered by the admin's multi-sig or DAO, consider adding a multi-step process or a governance vote for such a critical, irreversible action to ensure broad consensus.
StatusUnresolved
Info

`burn()` Function Reverts by Design

I-01The `burn()` function, which is part of the `ERC20BurnableUpgradeable` standard, is explicitly overridden to `revert("WPearl: use BridgeController.requestBurn()")`. This design choice centralizes all burning operations through the `bridgeController` via the `burnFrom` function. This deviates from the standard ERC-20 `burn` behavior where any token holder can burn their own tokens. (7.1 Architecture, 7.2 Code Security)
IssueThe `burn()` function, which is part of the `ERC20BurnableUpgradeable` standard, is explicitly overridden to `revert("WPearl: use BridgeController.requestBurn()")`. This design choice centralizes all burning operations through the `bridgeController` via the `burnFrom` function. This deviates from the standard ERC-20 `burn` behavior where any token holder can burn their own tokens. (7.1 Architecture, 7.2 Code Security)
FixDocument this design choice clearly for users and integrators, explaining that direct burning by token holders is not supported and all burn requests must be initiated or processed through the `bridgeController`.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract utilizes a robust architecture based on OpenZeppelin's upgradeable ERC-20, AccessControl, and UUPS proxy patterns, which are well-audited and widely adopted. Custom logic for freezing accounts and revoking freeze ability is implemented with appropriate checks, such as requiring `frozenCount == 0` before revocation. The use of `SafeERC20` and Solidity 0.8.27 mitigates common technical vulnerabilities. However, the custom freeze mechanism adds complexity and requires careful management of associated roles (7.2 Code Security).

GovernanceHigh3/10

The economic model includes a `MAX_SUPPLY` of 2.1 billion WPRL, preventing uncontrolled inflation. Minting and burning are centralized under a `bridgeController` role, which is a significant point of control (7.4 Economic). The `DEFAULT_ADMIN_ROLE` holds extensive power, including managing all other roles and controlling upgrades, which introduces centralization risk. While `AccessControlDefaultAdminRulesUpgradeable` provides an initial delay for admin actions, the concentration of power necessitates robust governance and operational security for these roles (7.5 Governance). The freeze mechanism allows for censorship of transfers, which can be permanently revoked under specific conditions.

UpgradesHigh1/10

The contract implements the UUPS upgradeability pattern, a standard and secure method for upgradeable contracts (7.7 Upgrades). Upgrades are controlled by the `DEFAULT_ADMIN_ROLE` and incorporate a `upgradeDelay` timelock, preventing immediate malicious upgrades. The `setUpgradeDelay` function only allows increasing the delay, further enhancing security by preventing administrators from shortening the timelock. However, the ultimate control over upgrades rests with the `DEFAULT_ADMIN_ROLE`, making its security paramount.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

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

Holder Composition

49.2% in top 10
28.7% in wallets20.5% in contracts
Effective Concentration36.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

$282.0K across 3 pairs
Uniswap v3USDTanalysed$236.1K83.7%Uniswap v4USDT$39.8K14.1%Uniswap v4USDC$6.1K2.2%

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
0x4c34…b239
Unlocked LP Held By
0xe08f…dbc8

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

What Raised This Score

10 factors
  • Ownership NOT renounced — Timelock 24h delay
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (49.2% total → 36.9% effective; 28.7% in EOAs, 20.5% 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, pool = 84% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 84% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium 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
NEXOCritical RiskCronos (CRO)Critical RiskEpic Chain (EPIC)Critical RiskAZTECCritical RiskCoW Protocol Token (COW)Critical RiskMetronome Synth ETH (MSETH)Critical Risk

Would You Like a More Detailed Audit of Wrapped Pearl?

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

Get Detailed Audit