Quantum Audit Logo
Launch App

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

Is Token Prometeus Network Safe?

PROMEthereum
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/10Governance1/10Upgrades6/10Checks passed3 of 5Findings1 High · 1 Medium · 1 Low3
SummaryAI Copilot

The PROMToken contract implements a standard ERC-20 token. It utilizes the SafeMath library to prevent integer overflow/underflow vulnerabilities.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Top-10 concentration > 50%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $10k
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 50% (73.0% total → 55.8% effective; 44.4% in EOAs, 28.6% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $10k ($1,480 across 3 pairs — easily drained)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 49% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 49% of DEX liquidity)
  • 1 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

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
28.6%Contracts44.4%Wallets27.0%Everyone else
28.6%Contracts44.4%Wallets27.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
73.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking28.6%
  • Walletsanonymous holders, free to sell44.4%
  • Everyone elsethe rest of the supply27.0%
Effective concentrationwhat the score reads55.8%
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.5K across 3 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$719Share of depth48.6%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x8e87…2f9e

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

Security Findings

1 High1 Medium1 Low
High

Outdated Solidity Compiler Version

The contract is compiled with Solidity version ^0.4.23. This version is significantly outdated and lacks numerous security enhancements, bug fixes, and gas optimizations introduced in later compiler versions (e.g., 0.5.x, 0.6.x, 0.8.x). Using an old compiler increases the risk of undiscovered compiler bugs and prevents the use of modern best practices like checked arithmetic by default in Solidity 0.8.x.H-01

Issue

The contract is compiled with Solidity version ^0.4.23. This version is significantly outdated and lacks numerous security enhancements, bug fixes, and gas optimizations introduced in later compiler versions (e.g., 0.5.x, 0.6.x, 0.8.x). Using an old compiler increases the risk of undiscovered compiler bugs and prevents the use of modern best practices like checked arithmetic by default in Solidity 0.8.x.

Fix

Upgrade the contract to a recent and actively maintained Solidity compiler version (e.g., 0.8.x). This would require careful refactoring and testing to adapt to breaking changes and new language features, such as explicit _ for unused return values, calldata for external function parameters, and default checked arithmetic.

Status

Unresolved

Medium

ERC-20 approve Race Condition

The approve function is susceptible to a known ERC-20 race condition. If a user calls approve to change an allowance from a non-zero value to another non-zero value, an attacker could front-run the transaction, spend the original allowance, and then allow the new allowance to be set, effectively allowing them to spend more than the intended new allowance. The contract's comments acknowledge this risk.M-01

Issue

The approve function is susceptible to a known ERC-20 race condition. If a user calls approve to change an allowance from a non-zero value to another non-zero value, an attacker could front-run the transaction, spend the original allowance, and then allow the new allowance to be set, effectively allowing them to spend more than the intended new allowance. The contract's comments acknowledge this risk.

Fix

While the contract provides increaseApproval and decreaseApproval to mitigate this, users should be strongly advised to use these helper functions instead of directly calling approve when modifying an existing non-zero allowance. If approve must be used, it is safer to first set the allowance to zero and then to the desired new value in separate transactions.

Status

Unresolved

Low

Inefficient Error Handling in SafeMath

The SafeMath library uses assert for error checking (e.g., assert(c / a == b) in mul, assert(b <= a) in sub, assert(c >= a) in add). In Solidity, assert consumes all remaining gas on failure, which is less gas-efficient than require or revert statements that refund unused gas. While assert is typically used for internal invariants, its use here for public-facing arithmetic operations could lead to higher transaction costs for users in case of an error.L-01

Issue

The SafeMath library uses assert for error checking (e.g., assert(c / a == b) in mul, assert(b <= a) in sub, assert(c >= a) in add). In Solidity, assert consumes all remaining gas on failure, which is less gas-efficient than require or revert statements that refund unused gas. While assert is typically used for internal invariants, its use here for public-facing arithmetic operations could lead to higher transaction costs for users in case of an error.

Fix

For contracts targeting modern Solidity versions, consider replacing assert with require or revert statements, especially for conditions that can be triggered by external input. This would improve gas efficiency for failed transactions. However, given the ^0.4.23 compiler, assert was a common pattern for internal checks.

Status

Unresolved

Analysis

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

The PROMToken contract implements a standard ERC-20 token. It utilizes the SafeMath library to prevent integer overflow/underflow vulnerabilities. The contract's architecture is straightforward, adhering to the ERC-20 standard. However, the use of an outdated Solidity compiler version and the inherent ERC-20 'approve' race condition introduce notable technical risks. The contract is not upgradeable and has a simple, fixed-supply economic model.

Technical8/10Low risk

The technical architecture (7.1 Architecture) of the PROMToken is a standard ERC-20 implementation, inheriting from OpenZeppelin's BasicToken and StandardToken patterns. The contract correctly uses SafeMath (7.2 Code Security) to prevent common integer overflow/underflow issues in arithmetic operations like add, sub, and mul. Access control (7.3 Access Control) is standard for an ERC-20 token, relying on msg.sender for transfers and allowed mappings for delegated transfers. A significant technical risk is the use of Solidity compiler version ^0.4.23, which is outdated and lacks modern security features and bug fixes. Additionally, the approve function is susceptible to the known ERC-20 race condition, although increaseApproval and decreaseApproval functions are provided as a mitigation.

Governance1/10High risk

The PROMToken contract represents a simple, fixed-supply ERC-20 token (7.4 Economic). The initial supply is minted and assigned entirely to the deployer in the constructor, which is a common and transparent distribution model. There are no complex economic mechanisms, staking, or lending functionalities. The contract does not include any governance features (7.5 Governance) or external dependencies (7.6 External) that could introduce economic or governance risks. The token's value is solely determined by market dynamics.

Upgrades6/10Medium risk

The PROMToken contract is implemented as a standard, non-upgradeable contract (7.7 Upgrades). This design choice eliminates all risks associated with upgrade mechanisms, such as proxy implementation bugs, storage collisions, or administrative key compromises during upgrades. The contract's immutability ensures its behavior remains consistent post-deployment. There are no operational (7.8 Operations) risks related to upgrades as the contract cannot be modified.

Final RecommendationWhat to do about this score

It is strongly recommended to migrate the contract to a modern Solidity compiler version (e.g., 0.8.x) to benefit from enhanced security features, gas optimizations, and clearer error handling.

While the contract provides increaseApproval and decreaseApproval as mitigations, users should be educated on the potential risks of directly using the approve function due to its inherent race condition. A thorough review of the SafeMath library's assert statements should be conducted, considering revert or require for more gas-efficient error handling in modern Solidity versions.

Contract & Record

2 audits on record
TypePROMToken
NetworkEthereum
Token age2y
Contract0xfc82…b27d
Deployer0xda2a…db74
Badge for your website
Token Prometeus 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, 202659Medium
  2. Jul 27, 202653Medium
  3. Jul 26, 202669High

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

Frequently Asked Questions

Is Token Prometeus Network a scam?

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

Is Token Prometeus Network safe to buy?

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

Has Token Prometeus 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
Fake World AssetsFWA · Ethereum59MediumPrismEthereum59MediumStaked USDeSUSDE · Ethereum59MediumGULDEthereum59MediumDeXeEthereum60MediumTether GoldXAUT · Ethereum58Medium

Would You Like a More Detailed Audit of Token Prometeus 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