Quantum Audit Logo
Launch App

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

Is PeaqOFT Safe?

PEAQBNB 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 · 1 audit on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical10/10Governance4/10Upgrades7/10Checks passed5 of 7Findings1 Low · 3 Info4
SummaryAI Copilot

The audit focused on the provided Solidity source code, which consists of standard OpenZeppelin ERC20 and Ownable implementations.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Top-10 concentration > 30% (72.1% total → 45.3% effective; 27.4% in EOAs, 44.7% 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 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 45 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
44.7%Contracts27.4%Wallets27.9%Everyone else
44.7%Contracts27.4%Wallets27.9%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
72.1%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking44.7%
  • Walletsanonymous holders, free to sell27.4%
  • Everyone elsethe rest of the supply27.9%
Effective concentrationwhat the score reads45.3%
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$89.3K

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$89.3KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x4315…678b0x6458…2df5

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

Security Findings

1 Low3 Info
Low

Centralized Ownership

The contract utilizes the Ownable pattern, granting the owner address significant control over administrative functions such as transferOwnership and renounceOwnership. While the prefill indicates the owner is a multisig (0x3e3f…f08b with 3/5 threshold), which mitigates single-point-of-failure risk, this still represents a centralized control point for the contract's management.L-01

Issue

The contract utilizes the Ownable pattern, granting the owner address significant control over administrative functions such as transferOwnership and renounceOwnership. While the prefill indicates the owner is a multisig ( with 3/5 threshold), which mitigates single-point-of-failure risk, this still represents a centralized control point for the contract's management.

Fix

Ensure the multisig wallet managing ownership is highly secure, with robust key management practices and a sufficient threshold for transaction execution. Regularly review the multisig signers and their security practices. Consider implementing a time-lock for critical administrative actions to provide a window for community review or emergency intervention.

Status

Unresolved

Info

Missing Specific Contract Source for PeaqOFT

The provided source code only contains OpenZeppelin base contracts (Context, Ownable, ERC20, etc.) and interfaces (IERC1363). The actual implementation of the PeaqOFT token, which would inherit from ERC20 and potentially add custom logic or implement IERC1363, is not included. This limits the scope of the audit to the generic OpenZeppelin components only, and any specific vulnerabilities or features of the PeaqOFT contract itself could not be assessed.I-01

Issue

The provided source code only contains OpenZeppelin base contracts (Context, Ownable, ERC20, etc.) and interfaces (IERC1363). The actual implementation of the PeaqOFT token, which would inherit from ERC20 and potentially add custom logic or implement IERC1363, is not included. This limits the scope of the audit to the generic OpenZeppelin components only, and any specific vulnerabilities or features of the PeaqOFT contract itself could not be assessed.

Fix

Provide the complete source code for the PeaqOFT contract to enable a comprehensive security audit of its specific implementation and business logic.

Status

Unresolved

Info

ERC20 approve Race Condition

The standard ERC20 approve function is susceptible to a front-running attack. If a user attempts to change an existing allowance by calling approve with a new value, a malicious actor can observe this transaction, front-run it by spending the original allowance, and then allow the new approve transaction to proceed. This results in the spender having access to the original allowance plus the new allowance, effectively spending more than intended. This is an inherent design pattern of ERC20 and not a flaw in this specific implementation.I-02

Issue

The standard ERC20 approve function is susceptible to a front-running attack. If a user attempts to change an existing allowance by calling approve with a new value, a malicious actor can observe this transaction, front-run it by spending the original allowance, and then allow the new approve transaction to proceed. This results in the spender having access to the original allowance plus the new allowance, effectively spending more than intended. This is an inherent design pattern of ERC20 and not a flaw in this specific implementation.

Fix

Users should be advised to first set the allowance to zero (approve(spender, 0)) before setting a new non-zero allowance (approve(spender, newAmount)). Alternatively, consider using increaseAllowance and decreaseAllowance functions if available in a derived contract, or explore alternative approval mechanisms like ERC2612 (permit) for more secure allowance management.

Status

Unresolved

Info

IERC1363 Interface Present Without Implementation

The IERC1363 interface, which defines transferAndCall and approveAndCall functionalities, is included in the provided source code. However, the ERC20 abstract contract does not implement these functions. If the PeaqOFT contract (not provided) also does not implement them, users might expect these functionalities based on the interface's presence but find them unavailable, potentially leading to confusion or failed transactions.I-03

Issue

The IERC1363 interface, which defines transferAndCall and approveAndCall functionalities, is included in the provided source code. However, the ERC20 abstract contract does not implement these functions. If the PeaqOFT contract (not provided) also does not implement them, users might expect these functionalities based on the interface's presence but find them unavailable, potentially leading to confusion or failed transactions.

Fix

If PeaqOFT is intended to support IERC1363, ensure the contract explicitly implements all functions defined in the interface. If not, consider removing the IERC1363 interface import to avoid misleading users about supported functionalities.

Status

Unresolved

Analysis

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

The audit focused on the provided Solidity source code, which consists of standard OpenZeppelin ERC20 and Ownable implementations. The code demonstrates high quality and adherence to best practices for a basic token. However, the specific PeaqOFT contract implementation was not provided, limiting the scope to generic OpenZeppelin components. Key findings include informational notes on the missing specific contract source, the standard ERC20 approve race condition, and the presence of the IERC1363 interface without implementation in the provided code. Centralized ownership, while present, is mitigated by a multisig owner.

Technical10/10Low risk

The technical architecture (7.1) is based on well-vetted OpenZeppelin standards, ensuring a robust foundation. Code security (7.2) is strong, utilizing Solidity 0.8+ with safe math and comprehensive input validation, including address(0) checks. The _update function correctly uses unchecked blocks where safety is guaranteed, optimizing gas. No reentrancy vectors or direct integer overflows/underflows were identified. However, the audit was limited to generic OpenZeppelin components, as the specific PeaqOFT contract source was not provided (I-01).

Governance4/10Medium risk

Access control (7.3) is managed via the Ownable pattern, restricting administrative functions like transferOwnership to a single owner. While this introduces centralization (L-01), the prefill indicates the owner is a multisig, which significantly enhances security and decentralization for governance (7.5). The economic model (7.4) for a standard ERC20 token is straightforward, with no complex mechanisms that could lead to economic exploits or oracle manipulation. External interactions (7.6) are limited to standard ERC20 operations, reducing attack surface.

Upgrades7/10Low risk

The provided contract is not designed as an upgradeable proxy (7.7), meaning its logic is immutable once deployed. This eliminates upgrade-related risks such as proxy misconfigurations or logic bugs introduced during upgrades. Operations (7.8) are standard for an ERC20 token, with no complex operational procedures identified.

Final RecommendationWhat to do about this score

Ensure that the full source code for the PeaqOFT contract, including any custom logic or overrides, is thoroughly audited to confirm its security posture.

Implement a robust process for managing the multisig owner keys to prevent unauthorized access or loss of control. For any future token interactions, consider using the approve(0) then approve(newAmount) pattern to mitigate the ERC20 approve race condition, or utilize alternative approval mechanisms if available in the ecosystem.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age1y
Contract0x8b9e…18f6
Deployer0x0ad5…3915
Badge for your website
PeaqOFT 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. Aug 30, 202630Low

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

Frequently Asked Questions

What is the PEAQ contract address?

The PeaqOFT (PEAQ) contract on BNB Chain is 0x8b9ee39195ea99d6ddd68030f44131116bc218f6. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is PeaqOFT a scam?

Quantum Audit's risk score for PeaqOFT is 30/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is PEAQ liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $89.3K.

Who holds PEAQ?

As of Sep 4, 2026, the 10 largest holders own 72.1% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
AsterBNB Chain30LowMYXBNB Chain30LowBluwhale AIBLUAI · BNB Chain30LowTaleXX · BNB Chain30Low施工猫SUE · BNB Chain30LowVELLORAVELL · BNB Chain30Low

Would You Like a More Detailed Audit of PeaqOFT?

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