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.

On-chain security analysis — is it a scam or legit?
Is Power Safe?
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 →The Power Wrapped Token contract is an ERC-677 compliant token with burn and mint capabilities, built upon well-audited Chainlink and OpenZeppelin libraries.
Read the full analysis- Ownership not renounced — strong Multisig
- Mintable supply, nominal cap 2121%/year — effectively unbounded
- Top-10 concentration > 30%
- Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
- Liquidity < $50k
- LP top1 unlocked holder = 100.0%
- LP top3 unlocked holders = 100.0%
- 1 High finding(s) from audit
- 1 Low finding(s) from audit
Exact factors
- 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
Security Checklist
as of audit · Sep 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking74.1%
- Walletsanonymous holders, free to sell7.5%
- Everyone elsethe rest of the supply18.4%
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 4The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xb1bd…ed9b0x6458…2df50xfacd…2a14No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
HighCentralized Control over Token Supply
The 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)H-01
Issue
The 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)
Fix
Implement 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.
Status
Unresolved
LowDeprecated increaseApproval and decreaseApproval Functions
The 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)L-01
increaseApproval and decreaseApproval FunctionsIssue
The 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)
Fix
Consider 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.
Status
Unresolved
InfoLack of Emergency Pause Mechanism
The 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)I-01
Issue
The 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)
Fix
Evaluate 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.
Status
Unresolved
InfoHigh MAX_SUPPLY Value
The 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)I-02
MAX_SUPPLY ValueIssue
The 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)
Fix
Ensure 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.
Status
Unresolved
Analysis
AI Copilotas of audit · Sep 4The 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).
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.
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.
To enhance the security and decentralization of the Power Wrapped Token, consider implementing a more robust governance mechanism for critical functions like minting and burning.
This could involve a time-locked multisig or a community-driven governance system to reduce the reliance on a single administrative entity. Additionally, evaluate the necessity of an emergency pause feature to provide a safety net against unforeseen circumstances.
Contract & Record
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 3, 202667High
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Frequently Asked Questions
What is the POWER contract address?
The Power contract on BNB Chain is 0x9dc44ae5be187eca9e2a67e33f27a4c91cea1223. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Is Power a scam?
Quantum Audit's risk score for Power is 67/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Is POWER liquidity locked?
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $20.8K.
Who holds POWER?
As of Sep 4, 2026, the 10 largest holders own 81.6% of the supply. The Holders section on this page shows who they are by holder type.
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 Is this your token? Publish your own audit on this page