Quantum Audit Logo
Launch App

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

Is Wrapped Pulse from PulseChain Safe?

WPLSEthereum
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
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance4/10Upgrades4/10Checks passed2 of 5Findings2 High · 1 Medium · 2 Low · 1 Info6
SummaryAI Copilot

This report details the security audit of an ERC20 token contract and associated libraries.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top3 unlocked holders = 81.0%
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 2 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 20% (35.9% total → 26.2% effective; 19.7% in EOAs, 16.2% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top3 unlocked holders = 81.0% (independent LP — depth risk, pool = 83% of DEX liquidity)
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 2 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
16.2%Contracts19.7%Wallets64.1%Everyone else
16.2%Contracts19.7%Wallets64.1%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
35.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking16.2%
  • Walletsanonymous holders, free to sell19.7%
  • Everyone elsethe rest of the supply64.1%
Effective concentrationwhat the score reads26.2%
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$128.6K across 7 pairs
Show 1 more pair

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$106.2KShare of depth82.6%
Top-1 Unlocked Holder30.6%
Top-3 Unlocked81.0%
Unlocked LP held by
0x5bcf…73820x4ff3…b9880x373d…44620xb52f…0af10xbb17…9b930x207b…e2970x7de2…eeef0x894a…4e780xc7cc…83330x1494…0639

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

Security Findings

2 High1 Medium2 Low1 Info
High

Outdated Solidity Compiler Version

The contract uses pragma solidity ^0.4.24;. This Solidity version is significantly outdated and is known to have compiler bugs and lacks many security features and optimizations present in newer versions (e.g., 0.8.x). Using an old compiler version increases the risk of undiscovered vulnerabilities or known exploits that have been patched in later versions.H-01

Issue

The contract uses pragma solidity ^0.4.24;. This Solidity version is significantly outdated and is known to have compiler bugs and lacks many security features and optimizations present in newer versions (e.g., 0.8.x). Using an old compiler version increases the risk of undiscovered vulnerabilities or known exploits that have been patched in later versions.

Fix

Upgrade the Solidity compiler version to a recent, stable release (e.g., ^0.8.0). This will require a thorough review and adaptation of the code to comply with new syntax and semantics, including changes to SafeMath usage (which is often no longer needed in 0.8.x due to default overflow/underflow checks) and require statements.

Status

Unresolved

High

Potential Access Control Flaw in Claimable Pattern

The IBurnableMintableERC677Token interface defines an external function claimTokens(address _token, address _to). The Claimable contract provides internal functions (claimValues, claimNativeCoins, claimErc20Tokens) to facilitate claiming assets. If the main token contract (e.g., ERC677BridgeToken) implements claimTokens without an onlyOwner or similar access control modifier, any user could call this function to drain arbitrary ERC20 tokens or native ETH from the contract's balance to any address.H-02

Issue

The IBurnableMintableERC677Token interface defines an external function claimTokens(address _token, address _to). The Claimable contract provides internal functions (claimValues, claimNativeCoins, claimErc20Tokens) to facilitate claiming assets. If the main token contract (e.g., ERC677BridgeToken) implements claimTokens without an onlyOwner or similar access control modifier, any user could call this function to drain arbitrary ERC20 tokens or native ETH from the contract's balance to any address.

Fix

Ensure that any public or external function that calls claimValues (or its internal derivatives) is protected by a robust access control mechanism, such as the onlyOwner modifier. This prevents unauthorized users from claiming funds held by the contract.

Status

Unresolved

Medium

ERC20 approve Race Condition

The approve function is susceptible to a known ERC20 race condition. If a user calls approve(spender, newAmount) while a spender is concurrently trying to spend the oldAmount, the spender might be able to spend both the oldAmount and the newAmount, or neither, depending on transaction ordering. While increaseApproval and decreaseApproval mitigate this, the approve function itself remains vulnerable.M-01

Issue

The approve function is susceptible to a known ERC20 race condition. If a user calls approve(spender, newAmount) while a spender is concurrently trying to spend the oldAmount, the spender might be able to spend both the oldAmount and the newAmount, or neither, depending on transaction ordering. While increaseApproval and decreaseApproval mitigate this, the approve function itself remains vulnerable.

Fix

While increaseApproval and decreaseApproval are provided, users should be strongly advised to use these functions instead of approve when modifying an existing allowance. For new allowances, a zero-value approve followed by the desired approve value can also mitigate the risk, but this is not enforced by the contract.

Status

Unresolved

Low

SafeMath.div Lacks Division by Zero Check

The div function in the SafeMath library does not explicitly check for division by zero. While Solidity's EVM will revert on division by zero, an explicit require(_b != 0) check would provide a clearer error message and prevent unnecessary gas consumption from the implicit revert.L-01

Issue

The div function in the SafeMath library does not explicitly check for division by zero. While Solidity's EVM will revert on division by zero, an explicit require(_b != 0) check would provide a clearer error message and prevent unnecessary gas consumption from the implicit revert.

Fix

Add an explicit require(_b != 0, "SafeMath: division by zero") check at the beginning of the div function in the SafeMath library for improved clarity and user experience.

Status

Unresolved

Low

Unusual selfdestruct for Ether Transfer Fallback

The Address.safeSendValue library function uses selfdestruct(_receiver) as a fallback if _receiver.send(_value) fails. While selfdestruct can force Ether to a contract, it is an unconventional and potentially gas-inefficient method. It might also lead to unexpected behavior if the recipient contract is not designed to handle Ether received via selfdestruct, potentially locking funds if the contract has no receive or fallback function, or if it has specific logic for selfdestruct calls.L-02

Issue

The Address.safeSendValue library function uses selfdestruct(_receiver) as a fallback if _receiver.send(_value) fails. While selfdestruct can force Ether to a contract, it is an unconventional and potentially gas-inefficient method. It might also lead to unexpected behavior if the recipient contract is not designed to handle Ether received via selfdestruct, potentially locking funds if the contract has no receive or fallback function, or if it has specific logic for selfdestruct calls.

Fix

Consider using a direct call with a gas limit as a fallback for send if a more robust Ether transfer is required, rather than selfdestruct. This provides more control and is generally a more standard approach for handling failed send calls.

Status

Unresolved

Info

Missing transferAndCall Implementation

The ERC677 interface is imported, which includes the transferAndCall(address, uint256, bytes) external returns (bool) function. However, the provided code snippets do not include an implementation for this function. If the main token contract intends to be ERC677 compliant, this function would need to be implemented.I-01

Issue

The ERC677 interface is imported, which includes the transferAndCall(address, uint256, bytes) external returns (bool) function. However, the provided code snippets do not include an implementation for this function. If the main token contract intends to be ERC677 compliant, this function would need to be implemented.

Fix

If ERC677 compliance is desired, implement the transferAndCall function. Ensure that its implementation is secure, particularly regarding reentrancy risks if it interacts with the recipient contract's tokenFallback function.

Status

Unresolved

Analysis

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

This report details the security audit of an ERC20 token contract and associated libraries. The provided source code appears to be a collection of standard OpenZeppelin 0.4.x contracts (BasicToken, StandardToken, MintableToken, BurnableToken, Ownable, SafeMath) along with some custom utilities (AddressUtils, SafeERC20, Claimable, Sacrifice). The main token contract, identified as 'PermittableToken' in prefill data, is not fully provided in the source, with 'ERC677BridgeToken' being truncated. The audit focuses on the provided code snippets. Key findings include the use of an outdated Solidity compiler, a potential access control vulnerability in the Claimable pattern if not properly protected, and the known ERC20 approve race condition.

Technical6/10Medium risk

The technical architecture leverages well-established ERC20 patterns and includes SafeMath for arithmetic safety (7.1 Architecture, 7.2 Code Security). However, the use of Solidity ^0.4.24 is a significant concern, as this version is outdated and lacks modern security features and compiler bug fixes (7.2 Code Security). The Claimable contract introduces a mechanism for claiming tokens/ETH, which, if implemented without proper access control in the inheriting contract, could lead to unauthorized fund drainage (7.3 Access Control). The approve function is also susceptible to the known ERC20 race condition.

Governance4/10Medium risk

The token implements standard Ownable access control, ensuring that critical functions like mint and finishMinting are restricted to the contract owner (7.5 Governance). The economic model appears straightforward, with minting and burning capabilities controlled by the owner, allowing for supply management (7.4 Economic). There are no complex DeFi primitives or oracle dependencies identified in the provided code, limiting economic attack vectors like flash loan manipulation.

Upgrades4/10Medium risk

The provided contracts do not implement an explicit upgrade mechanism (7.7 Upgrades). The prefill data indicates the contract is not a proxy. Therefore, upgrade safety issues are not directly applicable to this codebase. Any future upgradeability would require a separate proxy implementation.

Final RecommendationWhat to do about this score

It is strongly recommended to upgrade the Solidity compiler version to a modern, supported release (e.g., 0.8.x) to benefit from recent security patches and language improvements.

This would involve a comprehensive review and update of the codebase to align with newer Solidity syntax and best practices. Additionally, ensure that any external functions inheriting the Claimable pattern, such as claimTokens, are rigorously protected with appropriate access control mechanisms, typically onlyOwner, to prevent unauthorized asset withdrawals. Consider implementing a more robust and gas-efficient method for Ether transfers than selfdestruct in utility functions.

Contract & Record

1 audit on record
TypePermittableToken
NetworkEthereum
Token age3y
Contract0xa882…d68a
Deployer0x30e2…2539
Badge for your website
Wrapped Pulse from PulseChain 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, 202665High
  2. Aug 11, 202661Medium

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

Related Audits

6 more on the recordAll audits
FLOKIEthereum65HighAmpEthereum65HighWrapped FraxWFRAX · Ethereum65HighStargate FinanceSTG · Ethereum66HighEspressoESP · Ethereum64MediumPRDCTRPRD · Ethereum64Medium

Would You Like a More Detailed Audit of Wrapped Pulse from PulseChain?

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