Is Prometeus (PROM) Safe? Smart Contract Security Analysis

Security Findings

1 Low1 Info

Low

Potential `approve` Race Condition (Mitigated)

L-01The standard ERC-20 `approve` function is susceptible to a front-running attack where a malicious actor can observe a transaction to decrease an allowance and front-run it, transferring the original approved amount before the allowance is reduced. This could lead to a user approving a larger amount than intended. While the contract provides `increaseAllowance` and `decreaseAllowance` functions to mitigate this by allowing atomic adjustments, the base `approve` function still exists and can be used directly.

IssueThe standard ERC-20 `approve` function is susceptible to a front-running attack where a malicious actor can observe a transaction to decrease an allowance and front-run it, transferring the original approved amount before the allowance is reduced. This could lead to a user approving a larger amount than intended. While the contract provides `increaseAllowance` and `decreaseAllowance` functions to mitigate this by allowing atomic adjustments, the base `approve` function still exists and can be used directly.

FixEducate users to primarily use `increaseAllowance` and `decreaseAllowance` instead of directly calling `approve` when modifying an existing allowance. For new approvals, `approve` is safe. Ensure any external integrations or dApps interacting with this token prioritize the use of the safer allowance adjustment functions.

StatusUnresolved

Info

Use of Older Solidity Compiler Version

I-01The contract is compiled with Solidity version `0.5.16`. While functional, this version is older. Newer Solidity versions (e.g., 0.8.x) offer significant improvements, including built-in overflow/underflow checks (making `SafeMath` redundant and potentially saving gas), better optimizer performance, and enhanced security features.

IssueThe contract is compiled with Solidity version `0.5.16`. While functional, this version is older. Newer Solidity versions (e.g., 0.8.x) offer significant improvements, including built-in overflow/underflow checks (making `SafeMath` redundant and potentially saving gas), better optimizer performance, and enhanced security features.

FixConsider upgrading the Solidity compiler version to a more recent stable release (e.g., 0.8.x) for future deployments or contract updates. This would allow for removal of the `SafeMath` library, reducing bytecode size and gas costs, and leveraging modern compiler optimizations.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture (7.1 Architecture) is a straightforward BEP20 token with `Ownable` pattern. Code security (7.2 Code Security) is strong, utilizing `SafeMath` to prevent integer overflows/underflows and including necessary zero-address checks in critical transfer and approval functions. Access control (7.3 Access Control) is standard for an `Ownable` token, restricting only ownership transfers and renunciations. A minor issue is the use of an older Solidity compiler (0.5.16), which could be updated for better optimizations and built-in safety features. The contract also includes `increaseAllowance` and `decreaseAllowance` functions, which help mitigate the classic ERC-20 `approve` race condition.

GovernanceHigh1/10

The economic model (7.4 Economic) is a fixed-supply token with all tokens minted to the deployer at creation, which is a standard distribution model. There are no complex economic mechanisms, staking, or lending pools within this contract. Governance (7.5 Governance) is limited to the `Ownable` pattern, allowing the owner to transfer or renounce ownership. There are no external dependencies (7.6 External) that could introduce economic or governance risks, as the contract only interacts with the `IBEP20` interface for standard token operations.

UpgradesMedium6/10

The contract is not designed to be upgradeable (7.7 Upgrades), meaning there are no proxy patterns (e.g., UUPS, Transparent, Beacon) implemented. This eliminates upgrade-related risks such as proxy misconfigurations or logic contract vulnerabilities introduced during upgrades. The contract is immutable once deployed, providing a stable and predictable operational environment (7.8 Operations).

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

98.1% in top 10

97.9% in wallets0.2% in contracts

Effective Concentration98.0%

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

$133.6K across 9 pairs

Pancakeswap v3USDTanalysed$132.9K 0x9Ad3…53B3WBNB$605 0x8a1E…1256WBNB$126 Pancakeswap v2BTCB$32 Uniswap v2WBNB$2 Pancakeswap v1WBNB$2

Show 2 more pairsShow less

Pancakeswap v2WBNB$1 0x8a1E…1256BURGER$1

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 Holder99.7%

Top-3 Unlocked100.0%

Key Addresses

8 addresses

Deployer

0xe082…18de

Unlocked LP Held By

0x2ba8…a01e0xa80e…61f00xf587…3d290x5e91…fac10x4125…df6c0xa873…45880xba64…7242

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

What Raised This Score

6 factors

Ownership NOT renounced — owner is an EOA (single private key)
Top-10 concentration > 70% (98.1% total → 98.0% effective; 97.9% in EOAs, 0.2% in contracts — extreme)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 99.7% (independent LP — depth risk, pool = 99% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
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

Is Prometeus Safe?