Quantum Audit Logo

Is Starpower Network Safe?

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

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

Starpower Network STAR
0x8fce…787c
BNB Chain Not verifiedLast checked 3d ago 2 audits on record
Executive SummaryAI Copilot

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.

1 Medium1 Low2 Informational
Volume 24h
$2.00M
Liquidity
$1.59M
Price
$0.1156
Token Age
10mo
Top 10 Holders
44.7%

Security Findings

Medium

Centralized Control by EOA Owner

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

Lack of Upgradeability

L-01The 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).
IssueThe 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).
FixFor 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.
StatusUnresolved
Info

Incomplete Source Code Provided for Core Contract

I-01The 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).
IssueThe 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).
FixProvide 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.
StatusUnresolved
Info

Reliance on Well-Audited OpenZeppelin Libraries

I-02The 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).
IssueThe 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).
FixContinue 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.
StatusResolved

Category Ratings

TechnicalLow8/10

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.

GovernanceHigh2/10

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.

UpgradesHigh3/10

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).

Security Checklist

Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

22.0% in wallets22.7% in contracts
Effective Concentration31.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
0xb816…ca7a
Unlocked LP Held By
0x3d0a…e9cf

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 — 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

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

XRP Token (XRP)High RiskBTR token (BTR)High RiskBNB Attestation (BAS)High RiskCaldera (ERA)High Risk0GHigh RiskFilecoin (FIL)High Risk

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