Quantum Audit Logo
Launch App

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

Is Pieverse Token Safe?

PIEVERSEBNB Chain
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 · 2 audits on record
Chart
Critical RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades3/10Checks passed2 of 5Findings1 Critical · 2 High · 1 Medium · 1 Low · 1 Info6
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.

Read the full analysis
What raised the score
  • Ownership not renounced — Multisig
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
6.1%83.9%Wallets10.0%Everyone else
6.1%83.9%Wallets10.0%
ContractsWalletsEveryone elseBubble area = share of supply
90.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking6.1%
  • Walletsanonymous holders, free to sell83.9%
  • Everyone elsethe rest of the supply10.0%
Effective concentrationwhat the score reads86.4%
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$23.3K across 4 pairs

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$22.4KShare of depth96.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
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.

Security Findings

1 Critical2 High1 Medium1 Low1 Info
Critical

Owner can bypass global supply cap via syncSupplyAllChains

The 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.C-01

Issue

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

Fix

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

Status

Unresolved

High

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

The _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.H-01

Issue

The _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.

Fix

Modify 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"); }`.

Status

Unresolved

High

Multisig can indefinitely extend transfer lock without grace period

The 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.H-02

Issue

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

Fix

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

Status

Unresolved

Medium

Centralization risk with owner and multisig roles

The 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.M-01

Issue

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

Fix

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

Status

Unresolved

Low

Initial minting chain dependency

The 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.L-01

Issue

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

Fix

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

Status

Unresolved

Info

ETA variable not reset after grace period

The 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.I-01

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical4/10Medium risk

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

Governance1/10High risk

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

Upgrades3/10High risk

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.

Final RecommendationWhat to do about this score

It is critical to address the identified vulnerabilities, especially the owner's ability to bypass the global supply cap and the unintended blocking of cross-chain transfers for all users during the restricted period.

The setTransferAllowedTime logic should be refined to ensure consistent grace period application and prevent indefinite lock extensions by the multisig. Review and strengthen the operational security for both the owner and multisig roles, considering additional decentralization or time-locks for highly sensitive functions.

Contract & Record

2 audits on record
TypeSolidity 0.8.25
NetworkBNB Chain
Token age8mo
Contract0x0e63…25a9
Deployer0x7a37…4590
Badge for your website
Pieverse 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. Sep 4, 2026100Critical
  2. Jul 27, 202699Critical
  3. Jul 26, 202667High

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

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 recordAll audits
WebKey DAO 2.0WKEYDAO2 · BNB Chain100CriticalSnapCoinBNB Chain100CriticalSK HynixSKHYB · BNB Chain100CriticalGameStopGMEB · BNB Chain100CriticalAppleAAPLB · BNB Chain100CriticalSandisk CorporationSNDKB · BNB Chain100Critical

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 Is this your token? Publish your own audit on this page