Quantum Audit Logo

Is PowerLedger Safe?

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

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

PowerLedger POWR
0x5958…1269
Ethereum
Not verifiedThis 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 10d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The PowerLedger contract implements an ERC20-like token. The audit identified several high-severity issues related to the ERC20 `approve` race condition and centralized administrative control, alongside medium-severity concerns regarding the use of an outdated Solidity compiler. While basic token functionalities are present, the contract's age and specific design choices introduce notable security risks.

2 High1 Medium1 Low
Volume 24h
$44.2K
Liquidity
$535.9K
Price
$0.055
Token Age
4y
Top 10 Holders
80.7%

Security Findings

2 High1 Med1 Low
High

ERC20 `approve` Race Condition

H-01The `approve` function is vulnerable to a known ERC20 race condition. If a user approves an allowance and then attempts to change it, a malicious spender can front-run the second transaction to spend the original allowance, then the new allowance is set, allowing the spender to spend more than intended. While `compareAndApprove` attempts to mitigate this by checking `_currentValue`, it does not fully resolve the issue in all scenarios, especially when increasing allowances or if the spender is also front-running the `compareAndApprove` call itself. (7.2 Code Security)
IssueThe `approve` function is vulnerable to a known ERC20 race condition. If a user approves an allowance and then attempts to change it, a malicious spender can front-run the second transaction to spend the original allowance, then the new allowance is set, allowing the spender to spend more than intended. While `compareAndApprove` attempts to mitigate this by checking `_currentValue`, it does not fully resolve the issue in all scenarios, especially when increasing allowances or if the spender is also front-running the `compareAndApprove` call itself. (7.2 Code Security)
FixImplement the 'approve-and-call' pattern or require setting allowance to zero before increasing it. For `compareAndApprove`, ensure its logic is robust against all race conditions or deprecate it in favor of a safer pattern that explicitly sets allowance to zero before a new value is approved.
StatusUnresolved
High

Centralized Administrative Control

H-02The `migrationInfoSetter` role has the authority to change itself (`changeMigrationInfoSetter`) and set arbitrary `migrationInfo` (`setMigrationInfo`). This introduces a single point of failure. If the `migrationInfoSetter` address is compromised, an attacker could transfer the role to themselves and then set misleading `migrationInfo`, potentially for phishing or social engineering attacks. (7.3 Access Control, 7.4 Economic)
IssueThe `migrationInfoSetter` role has the authority to change itself (`changeMigrationInfoSetter`) and set arbitrary `migrationInfo` (`setMigrationInfo`). This introduces a single point of failure. If the `migrationInfoSetter` address is compromised, an attacker could transfer the role to themselves and then set misleading `migrationInfo`, potentially for phishing or social engineering attacks. (7.3 Access Control, 7.4 Economic)
FixConsider implementing a multi-signature wallet for the `migrationInfoSetter` role or a time-locked mechanism for critical administrative changes like `changeMigrationInfoSetter` to reduce the risk of a single point of compromise and provide a window for intervention.
StatusUnresolved
Medium

Outdated Solidity Compiler Version

M-01The contract is compiled with Solidity version `0.4.11`. This version is significantly outdated and lacks several security features, gas optimizations, and robust error handling mechanisms (e.g., `require`, `revert`, `assert`) introduced in later versions. While explicit checks mitigate direct integer underflows in `transfer` and `transferFrom`, the general use of an old compiler version increases the risk of undiscovered compiler bugs or less secure code patterns. (7.2 Code Security)
IssueThe contract is compiled with Solidity version `0.4.11`. This version is significantly outdated and lacks several security features, gas optimizations, and robust error handling mechanisms (e.g., `require`, `revert`, `assert`) introduced in later versions. While explicit checks mitigate direct integer underflows in `transfer` and `transferFrom`, the general use of an old compiler version increases the risk of undiscovered compiler bugs or less secure code patterns. (7.2 Code Security)
FixMigrate the contract to a more recent and supported Solidity compiler version (e.g., 0.8.x) to benefit from automatic overflow/underflow checks, improved error handling, and other security enhancements. Thoroughly re-audit the contract after migration to ensure no new vulnerabilities are introduced.
StatusUnresolved
Low

Missing Event for Critical State Change

L-01The `changeMigrationInfoSetter` function, which modifies a critical administrative role, does not emit an event. This makes it difficult to monitor and track changes to the `migrationInfoSetter` address on-chain, hindering transparency and off-chain auditing. (7.2 Code Security, 7.8 Operations)
IssueThe `changeMigrationInfoSetter` function, which modifies a critical administrative role, does not emit an event. This makes it difficult to monitor and track changes to the `migrationInfoSetter` address on-chain, hindering transparency and off-chain auditing. (7.2 Code Security, 7.8 Operations)
FixEmit an event (e.g., `event MigrationInfoSetterChanged(address indexed oldSetter, address indexed newSetter);`) whenever the `migrationInfoSetter` address is updated to improve transparency and traceability of administrative actions.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract implements a basic ERC20-like token with standard transfer functionalities. Strengths include explicit checks to prevent integer underflows in transfer operations (7.2 Code Security). However, the use of Solidity 0.4.11 is a significant technical debt, lacking modern safety features and potentially exposing the contract to compiler-related issues (7.2 Code Security). The `approve` function is also susceptible to the well-known ERC20 race condition, despite an attempt at mitigation with `compareAndApprove` (7.2 Code Security).

GovernanceHigh1/10

The contract features a `migrationInfoSetter` role, which can update an informational string and, critically, transfer its own administrative privileges (7.3 Access Control). This design introduces a single point of failure; a compromise of this address could lead to unauthorized changes to the setter and potentially misleading `migrationInfo` (7.4 Economic). The token supply is fixed and immutable, which is a clear design choice (7.4 Economic).

UpgradesMedium6/10

The contract is not designed with upgradeability patterns (e.g., proxy contracts) and is immutable once deployed (7.7 Upgrades). This eliminates upgrade-related risks such as proxy misconfigurations or logic contract vulnerabilities. However, it also means that any discovered vulnerabilities or desired feature enhancements would require a new deployment and migration of assets.

Security Checklist

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

Holder Composition

80.7% in top 10
77.7% in wallets2.9% in contracts
Effective Concentration78.9%

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

$537.0K across 2 pairs
Uniswap v3WETHanalysed$535.9K99.8%Uniswap v2WETH$1.1K0.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 Holder99.9%
Top-3 Unlocked100.0%

Key Addresses

5 addresses
Deployer
0x988b…0953
Unlocked LP Held By
0xc090…7bbf0xfb44…95c30x826f…1e650x33f4…c9a5

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 status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 70% (80.7% total → 78.9% effective; 77.7% in EOAs, 2.9% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.9% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • 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

Related Audits

6 more on the record
DIAToken (DIA)High RiskTERAFABHigh RiskTrace Token (TRAC)High RiskStargate Finance (STG)High RiskREHigh RiskZamaHigh Risk

Would You Like a More Detailed Audit of PowerLedger?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit