Quantum Audit Logo

Is Wrapped Pulse from PulseChain Safe?

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

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

Wrapped Pulse from PulseChain WPLS
0xa882…d68a
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

2 High1 Medium2 Low1 Informational
Volume 24h
$27.3K
Liquidity
$106.2K
Price
$0.00001104
Token Age
3y
Top 10 Holders
35.9%

Security Findings

2 High1 Med2 Low1 Info
High

Outdated Solidity Compiler Version

H-01The 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.
IssueThe 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.
FixUpgrade 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.
StatusUnresolved
High

Potential Access Control Flaw in `Claimable` Pattern

H-02The `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.
IssueThe `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.
FixEnsure 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.
StatusUnresolved
Medium

ERC20 `approve` Race Condition

M-01The `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.
IssueThe `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.
FixWhile `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.
StatusUnresolved
Low

`SafeMath.div` Lacks Division by Zero Check

L-01The `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.
IssueThe `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.
FixAdd 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.
StatusUnresolved
Low

Unusual `selfdestruct` for Ether Transfer Fallback

L-02The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved
Info

Missing `transferAndCall` Implementation

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

Category Ratings

TechnicalMedium6/10

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.

GovernanceMedium4/10

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.

UpgradesMedium4/10

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.

Security Checklist

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

Holder Composition

35.9% in top 10
19.7% in wallets16.2% in contracts
Effective Concentration26.2%

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

$128.6K across 7 pairs
Uniswap v3WETHanalysed$106.2K82.6%Uniswap v4USDC$19.0K14.8%Uniswap v4ETH$1.6K1.3%Uniswap v3WETH$8340.6%9inchWETH$4290.3%9mm V3WETH$2980.2%
Show 1 more pairShow less
Uniswap v3PYUSD$2080.2%

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 Holder30.6%
Top-3 Unlocked81.0%

Key Addresses

11 addresses
Deployer
0x30e2…2539
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.

What Raised This Score

8 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

Related Audits

6 more on the record
FLOKIHigh RiskStargate Finance (STG)High RiskEspresso (ESP)High RiskPRDCTR (PRD)High RiskAXGTHigh RiskSPACE ID (ID)High Risk

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