Quantum Audit Logo

Is PeaqOFT Safe?

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

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

PeaqOFT PEAQ
0x8b9e…18f6
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

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.

1 Low3 Informational
Volume 24h
$175.8K
Liquidity
$89.3K
Price
$0.02385
Token Age
1y
Top 10 Holders
72.1%

Security Findings

1 Low3 Info
Low

Centralized Ownership

L-01The 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.
IssueThe 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.
FixEnsure 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.
StatusUnresolved
Info

Missing Specific Contract Source for `PeaqOFT`

I-01The 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.
IssueThe 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.
FixProvide the complete source code for the `PeaqOFT` contract to enable a comprehensive security audit of its specific implementation and business logic.
StatusUnresolved
Info

ERC20 `approve` Race Condition

I-02The 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.
IssueThe 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.
FixUsers 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.
StatusUnresolved
Info

`IERC1363` Interface Present Without Implementation

I-03The `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.
IssueThe `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.
FixIf `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.
StatusUnresolved

Category Ratings

TechnicalLow10/10

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

GovernanceMedium4/10

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.

UpgradesLow7/10

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.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

72.1% in top 10
27.4% in wallets44.7% in contracts
Effective Concentration45.3%

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

$89.3K

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

3 addresses
Deployer
0x0ad5…3915
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.

What Raised This Score

6 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

Related Audits

6 more on the record
AsterMedium RiskMYXMedium RiskBluwhale AI (BLUAI)Medium RiskTaleX (X)Medium Risk施工猫 (SUE)Medium RiskmubarakMedium Risk

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