Is Token Prometeus Network (PROM) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low

High

Outdated Solidity Compiler Version

H-01The 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.

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

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

StatusUnresolved

Medium

ERC-20 `approve` Race Condition

M-01The `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.

IssueThe `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.

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

StatusUnresolved

Low

Inefficient Error Handling in SafeMath

L-01The `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.

IssueThe `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.

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceHigh1/10

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.

UpgradesMedium6/10

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.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

73.0% in top 10

44.4% in wallets28.6% in contracts

Effective Concentration55.8%

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

$1.5K across 3 pairs

Uniswap v4USDTanalysed$719 Uniswap v4USDT$664 Uniswap v2WETH$96

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

2 addresses

Deployer

0xda2a…db74

Unlocked LP Held By

0x8e87…2f9e

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

What Raised This Score

9 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

Final Recommendation

AI Copilot

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

Read the verdictHide

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

TypePROMToken

Audit History

2 audits on record

Jul 2669Jul 2753Sep 459

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

Is Token Prometeus Network Safe?

Security Findings

Outdated Solidity Compiler Version

ERC-20 `approve` Race Condition

Inefficient Error Handling in SafeMath

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Frequently Asked Questions

Related Audits

Would You Like a More Detailed Audit of Token Prometeus Network?