Quantum Audit Logo

Is Pieverse Token Safe?

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

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

Pieverse Token PIEVERSE
0x0e63…25a9
BNB Chain Not verifiedLast checked 3d ago 2 audits on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The PieverseOFT contract implements a LayerZero-compatible Omnichain Fungible Token with features such as a global supply cap, time-locked transfers, and a whitelist system. The audit identified a Critical vulnerability related to the owner's ability to bypass the global supply cap, and High-severity issues concerning restricted cross-chain transfers for all users and the multisig's ability to indefinitely extend transfer locks. Several Medium and Low-severity findings highlight centralization risks and operational considerations. The contract generally follows good coding practices and utilizes standard libraries, but critical access control and economic logic flaws require immediate attention.

1 Critical2 High1 Medium1 Low1 Informational
Volume 24h
$17.1K
Liquidity
$22.4K
Price
$1.0950
Token Age
8mo
Top 10 Holders
90.0%

Security Findings

1 Crit2 High1 Med1 Low1 Info
Critical

Owner can bypass global supply cap via `syncSupplyAllChains`

C-01The `syncSupplyAllChains` function, callable by the contract owner, allows setting the `supplyAllChains` variable to any value up to `MAX_SUPPLY`. A malicious or compromised owner could repeatedly set `supplyAllChains` to a low value, then mint additional tokens up to `MAX_SUPPLY - supplyAllChains`, effectively bypassing the intended global supply cap and minting an arbitrary amount of tokens beyond `MAX_SUPPLY`.
IssueThe `syncSupplyAllChains` function, callable by the contract owner, allows setting the `supplyAllChains` variable to any value up to `MAX_SUPPLY`. A malicious or compromised owner could repeatedly set `supplyAllChains` to a low value, then mint additional tokens up to `MAX_SUPPLY - supplyAllChains`, effectively bypassing the intended global supply cap and minting an arbitrary amount of tokens beyond `MAX_SUPPLY`.
FixRemove the `syncSupplyAllChains` function or restrict its functionality. If synchronization is necessary, consider allowing only increases to `supplyAllChains` (e.g., for recovery from undercounting) or implement a multi-signature approval and a time-lock for any changes, especially decreases, to this critical variable.
StatusUnresolved
High

Cross-chain transfers (burning) are blocked for ALL users during restricted period

H-01The `_update` function, which is called for all token transfers, unconditionally reverts if `to == address(0)` (burning) during the `transferAllowedTime` restricted period. This means that even whitelisted users cannot perform cross-chain transfers, as LayerZero's `_send` operation typically involves burning tokens on the source chain. This contradicts the presumed intent of the whitelist, which should allow whitelisted users to transfer tokens, including cross-chain, during the restricted period.
IssueThe `_update` function, which is called for all token transfers, unconditionally reverts if `to == address(0)` (burning) during the `transferAllowedTime` restricted period. This means that even whitelisted users cannot perform cross-chain transfers, as LayerZero's `_send` operation typically involves burning tokens on the source chain. This contradicts the presumed intent of the whitelist, which should allow whitelisted users to transfer tokens, including cross-chain, during the restricted period.
FixModify the `_update` function to allow burning for whitelisted users during the restricted period. The logic should be similar to how regular transfers are handled: `else if (to == address(0)) { require(isWhitelisted[from], "Not whitelisted for burning during restricted period"); }`.
StatusUnresolved
High

Multisig can indefinitely extend transfer lock without grace period

H-02The `setTransferAllowedTime` function allows the `multisig` to set `transferAllowedTime` to *any* future timestamp if `transferAllowedTime > block.timestamp` and `ETA == 0`. This means that if the initial transfer lock is still active and no grace period has been set, the multisig can indefinitely extend the lock period without any time-based constraints, potentially leading to a permanent denial of service for non-whitelisted transfers.
IssueThe `setTransferAllowedTime` function allows the `multisig` to set `transferAllowedTime` to *any* future timestamp if `transferAllowedTime > block.timestamp` and `ETA == 0`. This means that if the initial transfer lock is still active and no grace period has been set, the multisig can indefinitely extend the lock period without any time-based constraints, potentially leading to a permanent denial of service for non-whitelisted transfers.
FixImplement a consistent grace period mechanism for all updates to `transferAllowedTime`. Ensure that any extension of the lock period is subject to a time-lock or a maximum extension duration. Consider requiring a separate governance vote or a time-lock for significant extensions to this critical parameter.
StatusUnresolved
Medium

Centralization risk with `owner` and `multisig` roles

M-01The contract relies heavily on two privileged roles: the `owner` (managing minters and `syncSupplyAllChains`) and the `multisig` (managing the whitelist and `transferAllowedTime`). While using a multisig for the `multisig` role mitigates some risk, a compromise of either the `owner`'s private key or the `multisig`'s quorum could lead to significant control over token supply, transferability, and distribution, posing a single point of failure.
IssueThe contract relies heavily on two privileged roles: the `owner` (managing minters and `syncSupplyAllChains`) and the `multisig` (managing the whitelist and `transferAllowedTime`). While using a multisig for the `multisig` role mitigates some risk, a compromise of either the `owner`'s private key or the `multisig`'s quorum could lead to significant control over token supply, transferability, and distribution, posing a single point of failure.
FixEnsure both the `owner` and `multisig` addresses are robustly secured (e.g., hardware wallets, strong operational security for multisig signers). Consider further decentralizing control over critical functions or implementing time-locks for highly sensitive operations to reduce the impact of a single point of compromise.
StatusUnresolved
Low

Initial minting chain dependency

L-01The constructor's initial minting logic is dependent on specific `chainId` values (Ethereum/Sepolia or BNB/Testnet). If the contract is deployed on a chain not explicitly listed in the `if/else if` statements (e.g., Arbitrum, Optimism, Base), no initial tokens will be minted. This might lead to unexpected operational behavior or require manual `mint` calls post-deployment, potentially causing delays or requiring additional administrative overhead.
IssueThe constructor's initial minting logic is dependent on specific `chainId` values (Ethereum/Sepolia or BNB/Testnet). If the contract is deployed on a chain not explicitly listed in the `if/else if` statements (e.g., Arbitrum, Optimism, Base), no initial tokens will be minted. This might lead to unexpected operational behavior or require manual `mint` calls post-deployment, potentially causing delays or requiring additional administrative overhead.
FixClearly document the intended deployment chains and initial distribution strategy. If deployment on other chains is anticipated, ensure a clear plan for initial token distribution, either by extending the `chainId` checks or by providing a post-deployment minting mechanism.
StatusUnresolved
Info

`ETA` variable not reset after grace period

I-01The `ETA` variable, once set (e.g., `transferAllowedTime + 1 days`), is never explicitly reset to 0. This means that subsequent calls to `setTransferAllowedTime` will always be subject to the `ETA` constraint, even if `transferAllowedTime` has long passed. While not a direct vulnerability, this behavior might lead to less intuitive grace period logic or unexpected constraints on future `transferAllowedTime` updates.
IssueThe `ETA` variable, once set (e.g., `transferAllowedTime + 1 days`), is never explicitly reset to 0. This means that subsequent calls to `setTransferAllowedTime` will always be subject to the `ETA` constraint, even if `transferAllowedTime` has long passed. While not a direct vulnerability, this behavior might lead to less intuitive grace period logic or unexpected constraints on future `transferAllowedTime` updates.
FixClarify the intended lifecycle of the `ETA` variable. If `ETA` is meant to be a temporary grace period, consider resetting it to 0 once `transferAllowedTime` has passed or after a certain condition is met to ensure the logic remains clear and predictable.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract is built upon LayerZero's OFT standard, leveraging battle-tested components (7.1 Architecture). Code quality is generally good, utilizing Solidity 0.8+ for safety. However, a critical flaw (C-01) allows the owner to manipulate the cross-chain supply, bypassing the `MAX_SUPPLY` limit (7.2 Code Security, 7.3 Access Control). Additionally, the `_update` override incorrectly blocks all cross-chain transfers (burning) during the restricted period, even for whitelisted users (H-01, 7.2 Code Security).

GovernanceHigh1/10

The economic model relies on a `MAX_SUPPLY` and `supplyAllChains` tracking, but the owner's `syncSupplyAllChains` function can subvert this cap (C-01, 7.4 Economic). Access control is split between an `owner` and a `multisig` (7.3 Access Control, 7.5 Governance). However, the `multisig` can indefinitely extend the transfer lock without a grace period (H-02, 7.5 Governance), posing a significant centralization risk. The initial token distribution logic is chain-dependent (L-01, 7.8 Operations).

UpgradesHigh3/10

The PieverseOFT contract is not designed as an upgradeable proxy. Therefore, direct upgradeability risks are not applicable to this specific contract. Any future changes would require a new deployment and migration.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

90.0% in top 10
83.9% in wallets6.1% in contracts
Effective Concentration86.4%

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

$23.3K across 4 pairs
UniswapUSDTanalysed$22.4K96.0%UniswapUSDT$9103.9%UniswapLUCKY$290.1%Pancakeswap v2WBNB$30.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

7 addresses
Deployer
0x7a37…4590
Unlocked LP Held By
0x3829…c82c0x6458…2df50x98c5…6e290x8c3b…eaeb0xde51…a29f0xfacd…2a14

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

What Raised This Score

11 factors
  • Ownership NOT renounced — Multisig (2-of-3)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 70% (90.0% total → 86.4% effective; 83.9% in EOAs, 6.1% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($23,324 across 4 pairs — thin market)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 2 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

Frequently Asked Questions

Is Pieverse Token a scam?

Based on automated analysis, Pieverse Token scores 67/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is Pieverse Token safe to buy?

Our scanner flagged a risk score of 67/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has Pieverse Token been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the record
WebKey DAO 2.0 (WKEYDAO2)Critical RiskSnapCoinCritical RiskSK Hynix (SKHYB)Critical RiskGameStop (GMEB)Critical RiskApple (AAPLB)Critical RiskSandisk Corporation (SNDKB)Critical Risk

Would You Like a More Detailed Audit of Pieverse Token?

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

Get Detailed Audit