Quantum Audit Logo

Is Power Safe?

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

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

Power POWER
0x9dc4…1223
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
Executive SummaryAI Copilot

The Power Wrapped Token contract is an ERC-677 compliant token with burn and mint capabilities, built upon well-audited Chainlink and OpenZeppelin libraries. It features a two-step ownership transfer and a maximum supply cap. The primary risk identified is the centralized control over token supply through the owner's ability to manage minter and burner roles, despite the owner being a multisig. Minor issues include the use of deprecated function names and the absence of an emergency pause mechanism.

1 High1 Low2 Informational
Volume 24h
$14.7K
Liquidity
$19.9K
Price
$0.08706
Token Age
9mo
Top 10 Holders
81.6%

Security Findings

High

Centralized Control over Token Supply

H-01The contract owner has the exclusive ability to grant and revoke minter and burner roles. This means a single entity (the multisig owner) ultimately controls the token's supply dynamics. While a multisig enhances security over a single EOA, the concentrated power remains a significant centralization risk. A compromise of the multisig or malicious intent could lead to arbitrary minting or burning, impacting token value and integrity. (7.3 Access Control, 7.4 Economic)
IssueThe contract owner has the exclusive ability to grant and revoke minter and burner roles. This means a single entity (the multisig owner) ultimately controls the token's supply dynamics. While a multisig enhances security over a single EOA, the concentrated power remains a significant centralization risk. A compromise of the multisig or malicious intent could lead to arbitrary minting or burning, impacting token value and integrity. (7.3 Access Control, 7.4 Economic)
FixImplement a more decentralized approach for critical functions like minting and burning, such as a time-locked governance mechanism or a multi-signature scheme with a higher threshold for these specific actions. Clearly communicate this centralization risk to users.
StatusUnresolved
Low

Deprecated `increaseApproval` and `decreaseApproval` Functions

L-01The `BurnMintERC677` contract exposes `increaseApproval` and `decreaseApproval` functions. While these functions internally call the safer `increaseAllowance` and `decreaseAllowance` from OpenZeppelin's `ERC20`, the `*Approval` naming convention is deprecated due to known front-running vulnerabilities associated with the pattern of modifying allowances directly. (7.2 Code Security)
IssueThe `BurnMintERC677` contract exposes `increaseApproval` and `decreaseApproval` functions. While these functions internally call the safer `increaseAllowance` and `decreaseAllowance` from OpenZeppelin's `ERC20`, the `*Approval` naming convention is deprecated due to known front-running vulnerabilities associated with the pattern of modifying allowances directly. (7.2 Code Security)
FixConsider renaming these functions to `increaseAllowance` and `decreaseAllowance` to align with current best practices and avoid confusion, or remove them if their functionality is redundant with the inherited `increaseAllowance`/`decreaseAllowance`.
StatusUnresolved
Info

Lack of Emergency Pause Mechanism

I-01The `PowerWrappedToken` contract does not include a mechanism to pause token transfers or minting/burning operations in an emergency. In the event of a critical vulnerability, a market exploit, or other unforeseen circumstances, the inability to halt operations could lead to significant loss of funds or system instability. (7.8 Operations)
IssueThe `PowerWrappedToken` contract does not include a mechanism to pause token transfers or minting/burning operations in an emergency. In the event of a critical vulnerability, a market exploit, or other unforeseen circumstances, the inability to halt operations could lead to significant loss of funds or system instability. (7.8 Operations)
FixEvaluate the need for an emergency pause mechanism. If deemed necessary, integrate a `Pausable` contract (e.g., from OpenZeppelin) to allow the owner or a designated role to temporarily halt critical functions.
StatusUnresolved
Info

High `MAX_SUPPLY` Value

I-02The `MAX_SUPPLY` for the token is set to `10^27` (1 billion tokens with 18 decimals). While this is a hard cap, it represents a very large potential supply. This is not a vulnerability in itself, but it implies that the token's value proposition might rely on controlled minting rather than scarcity, and any compromise of the minter role could lead to a massive inflation event. (7.4 Economic)
IssueThe `MAX_SUPPLY` for the token is set to `10^27` (1 billion tokens with 18 decimals). While this is a hard cap, it represents a very large potential supply. This is not a vulnerability in itself, but it implies that the token's value proposition might rely on controlled minting rather than scarcity, and any compromise of the minter role could lead to a massive inflation event. (7.4 Economic)
FixEnsure that the implications of such a high maximum supply are well-understood and communicated to token holders. Reinforce the security measures around the minter role.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract is built upon well-audited OpenZeppelin and Chainlink libraries, providing a robust foundation for ERC-20 and ERC-677 functionalities. It includes a `validAddress` modifier to prevent accidental token locking and implements a maximum supply cap (7.1 Architecture, 7.2 Code Security). A minor issue is the exposure of deprecated `increaseApproval` and `decreaseApproval` functions, although they correctly delegate to safer allowance methods (7.2 Code Security). The lack of an emergency pause mechanism could be a concern for operational resilience (7.8 Operations).

GovernanceHigh2/10

The contract utilizes a two-step ownership transfer mechanism, enhancing security for owner changes. The owner is a multisig, mitigating single points of failure for administrative control. However, the owner retains significant centralized control over the token's supply through the ability to grant and revoke minter and burner roles (7.3 Access Control, 7.4 Economic). This concentration of power means a compromise of the multisig could lead to arbitrary supply manipulation, posing a substantial economic risk.

UpgradesMedium4/10

The contract is not designed as an upgradeable proxy, meaning its logic cannot be changed post-deployment. This eliminates risks associated with upgrade mechanisms, such as proxy implementation mismatches or insecure upgrade paths (7.7 Upgrades). Any changes would require a new deployment and migration.

Security Checklist

Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

7.5% in wallets74.1% in contracts
Effective Concentration37.1%

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

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

Deployer
0xf017…b336
Unlocked LP Held By
0xb1bd…ed9b0x6458…2df50xfacd…2a14

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

What Raised This Score

  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Mintable supply, nominal cap 2121%/year — effectively unbounded
  • Top-10 concentration > 30% (81.6% total → 37.1% effective; 7.5% in EOAs, 74.1% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($20,751 across 3 pairs — thin market)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 96% of DEX liquidity)
  • 1 High 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

Quack AI Token (Q)High RiskHoloworld AI (HOLO)High RiskXPULSHigh RiskHana Token (HANA)High RiskUpstarty (UPY)High RiskBillions Network Token (BILL)High Risk

Would You Like a More Detailed Audit of Power?

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

Get Detailed Audit