Quantum Audit Logo
Launch App

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

Is Starpower Network Safe?

STARBNB Chain
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 · 2 audits on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance2/10Upgrades3/10Checks passed2 of 5Findings1 Medium · 1 Low · 2 Info4
SummaryAI Copilot

This audit report is based on a partial source code submission, specifically OpenZeppelin library dependencies (Context.sol, ECDSA.sol).

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (44.7% total → 31.1% effective; 22.0% in EOAs, 22.7% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • 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

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
22.7%Contracts22.0%Wallets55.3%Everyone else
22.7%Contracts22.0%Wallets55.3%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
44.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking22.7%
  • Walletsanonymous holders, free to sell22.0%
  • Everyone elsethe rest of the supply55.3%
Effective concentrationwhat the score reads31.1%
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$1.60M across 5 pairs

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$1.59MShare of depth99.5%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x3d0a…e9cf

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

Security Findings

1 Medium1 Low2 Info
Medium

Centralized Control by EOA Owner

The PeerToken contract is controlled by an Externally Owned Account (EOA) at 0xb816…ca7a. This centralizes significant power, such as potential minting, burning, pausing, or parameter modification, depending on the token's implementation. An EOA is a single point of failure; if its private key is compromised, the entire contract's integrity could be at risk (7.3 Access Control, 7.5 Governance).M-01

Issue

The PeerToken contract is controlled by an Externally Owned Account (EOA) at . This centralizes significant power, such as potential minting, burning, pausing, or parameter modification, depending on the token's implementation. An EOA is a single point of failure; if its private key is compromised, the entire contract's integrity could be at risk (7.3 Access Control, 7.5 Governance).

Fix

Consider implementing a multi-signature wallet (e.g., Gnosis Safe) for critical administrative functions. This distributes control among multiple trusted parties, significantly reducing the risk associated with a single compromised key. Alternatively, explore transitioning to a decentralized governance model.

Status

Unresolved

Low

Lack of Upgradeability

The contract is not deployed as an upgradeable proxy. This means that once deployed, its logic cannot be modified. While this eliminates upgrade-related risks (7.7 Upgrades), it also prevents bug fixes, feature enhancements, or parameter adjustments without a full redeployment and migration of user funds/states (7.8 Operations).L-01

Issue

The contract is not deployed as an upgradeable proxy. This means that once deployed, its logic cannot be modified. While this eliminates upgrade-related risks (7.7 Upgrades), it also prevents bug fixes, feature enhancements, or parameter adjustments without a full redeployment and migration of user funds/states (7.8 Operations).

Fix

For future deployments, evaluate the trade-offs between non-upgradeable and upgradeable contracts. If flexibility for bug fixes or feature additions is desired, consider using a well-audited proxy pattern (e.g., UUPS). If immutability is a core design principle, ensure the initial deployment is thoroughly tested and audited.

Status

Unresolved

Info

Incomplete Source Code Provided for Core Contract

The source code for the main contract, PeerToken, was not provided for review. Only OpenZeppelin library dependencies (Context.sol, ECDSA.sol) were available. This prevents a comprehensive security assessment of the contract's specific business logic, state variables, and potential vulnerabilities (7.1 Architecture, 7.2 Code Security).I-01

Issue

The source code for the main contract, PeerToken, was not provided for review. Only OpenZeppelin library dependencies (Context.sol, ECDSA.sol) were available. This prevents a comprehensive security assessment of the contract's specific business logic, state variables, and potential vulnerabilities (7.1 Architecture, 7.2 Code Security).

Fix

Provide the complete and verified source code for the PeerToken contract to enable a thorough and accurate security audit. Without the full source, the overall risk assessment remains significantly limited.

Status

Unresolved

Info

Reliance on Well-Audited OpenZeppelin Libraries

The provided code snippet exclusively consists of standard, battle-tested OpenZeppelin contracts (Context, ECDSA). These libraries are widely used and have undergone extensive audits and community review, significantly reducing the risk of vulnerabilities within these specific components (7.2 Code Security).I-02

Issue

The provided code snippet exclusively consists of standard, battle-tested OpenZeppelin contracts (Context, ECDSA). These libraries are widely used and have undergone extensive audits and community review, significantly reducing the risk of vulnerabilities within these specific components (7.2 Code Security).

Fix

Continue to leverage well-vetted and actively maintained libraries. Ensure that the versions used are up-to-date and compatible with the project's Solidity compiler version to benefit from the latest security patches and improvements.

Status

Resolved

Analysis

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

This audit report is based on a partial source code submission, specifically OpenZeppelin library dependencies (Context.sol, ECDSA.sol). The core contract, PeerToken, was not provided for review. Consequently, a comprehensive security assessment of the PeerToken contract's specific logic, functionality, and potential vulnerabilities could not be performed. The findings primarily address general architectural considerations and the implications of the missing source code, alongside observations about the provided libraries and the contract's operational setup.

Technical8/10Low risk

The provided code consists of well-audited OpenZeppelin libraries (Context, ECDSA), which are robust and widely used, indicating a strong foundation for these components (7.2 Code Security). However, the absence of the core PeerToken contract's source code prevents a thorough technical analysis of its specific logic, potential vulnerabilities like reentrancy or integer overflows, and overall code quality (7.1 Architecture). This significantly limits the scope of the technical assessment, introducing an unknown risk factor.

Governance2/10High risk

The contract is controlled by an Externally Owned Account (EOA) owner, , which centralizes significant administrative power (7.5 Governance). This single point of control could pose a risk if the EOA's private key is compromised, potentially leading to unauthorized actions like token minting, burning, or pausing, depending on the token's implementation (7.4 Economic). While this offers direct control, it lacks the security and decentralization benefits of multi-signature wallets or decentralized autonomous organizations.

Upgrades3/10High risk

The contract is not deployed as an upgradeable proxy, meaning its logic is immutable once deployed (7.7 Upgrades). This eliminates risks associated with proxy implementation bugs or upgrade path vulnerabilities. However, it also means that any discovered bugs or desired feature enhancements would necessitate a complete redeployment and migration of user assets, which can be a complex and risky process (7.8 Operations).

Final RecommendationWhat to do about this score

To enhance the security posture, it is crucial to provide the complete source code for the PeerToken contract for a comprehensive audit.

For critical administrative functions, consider transitioning from an EOA owner to a multi-signature wallet to mitigate single points of failure. Evaluate the trade-offs of immutability versus upgradeability for future deployments, ensuring thorough testing if a non-upgradeable design is chosen.

Contract & Record

2 audits on record
TypePeerToken
NetworkBNB Chain
Token age10mo
Contract0x8fce…787c
Deployer0xb816…ca7a
Badge for your website
Starpower Network 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, 202662Medium
  2. Jul 27, 202649Medium
  3. Jul 27, 202663Medium

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

Frequently Asked Questions

Is Starpower Network a scam?

Based on automated analysis, Starpower Network scores 63/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is Starpower Network safe to buy?

Our scanner flagged a risk score of 63/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has Starpower Network been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the recordAll audits
XRP TokenXRP · BNB Chain62MediumBTR tokenBTR · BNB Chain62MediumIrysBNB Chain62MediumBNB AttestationBAS · BNB Chain61MediumCalderaERA · BNB Chain63Medium0GBNB Chain63Medium

Would You Like a More Detailed Audit of Starpower Network?

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