Quantum Audit Logo

Is Prometheus a Scam?

Early-stage security check — honeypot & rug-pull analysis

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

Prometheus PROMETHEUS
0x3cdb…04f1
Ethereum Not verifiedLast checked 3d ago 1 audit on record New Launch · 2d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The Prometheus token contract implements custom tax mechanisms, anti-bot/anti-whale features, and automated liquidity management. While it uses SafeMath for arithmetic safety, the audit reveals critical economic risks, primarily due to an unlocked liquidity pool and highly centralized control. The contract's high and dynamic tax rates also pose significant concerns for users.

1 Critical2 High2 Medium1 Informational
! Early-stage analysis. This token has limited on-chain history (2d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$10.5K
Liquidity
$20.6K
Price
$0.0007916
Token Age
2d
Top 10 Holders
32.5%

Security Findings

1 Crit2 High2 Med1 Info
Critical

Unlocked Liquidity Pool (Rug Pull Risk)

C-01The provided information indicates that the liquidity pool for the Prometheus token is 'unlocked'. This means the deployer or owner of the liquidity pool tokens can remove the entire liquidity at any time, effectively draining the trading pair and rendering the token worthless. This is a classic 'rug pull' vector, posing an immediate and severe threat to investor funds (7.4 Economic).
IssueThe provided information indicates that the liquidity pool for the Prometheus token is 'unlocked'. This means the deployer or owner of the liquidity pool tokens can remove the entire liquidity at any time, effectively draining the trading pair and rendering the token worthless. This is a classic 'rug pull' vector, posing an immediate and severe threat to investor funds (7.4 Economic).
FixImmediately lock the liquidity pool tokens using a reputable locker service or by transferring them to a burn address. Provide verifiable proof of liquidity locking to the community to build trust and mitigate this critical risk.
StatusUnresolved
High

Excessive Owner Privileges and Centralization

H-01The contract grants extensive control to the `owner()`, allowing manipulation of critical parameters. The owner can set various tax rates, transaction limits (`_maxTxAmount`, `_maxWalletSize`), swap parameters, and manage a `bots` mapping to exclude addresses from fees and limits. This high degree of centralization (7.3 Access Control) enables the owner to significantly impact the token's economy, potentially leading to unfair advantages, market manipulation, or malicious actions (7.4 Economic).
IssueThe contract grants extensive control to the `owner()`, allowing manipulation of critical parameters. The owner can set various tax rates, transaction limits (`_maxTxAmount`, `_maxWalletSize`), swap parameters, and manage a `bots` mapping to exclude addresses from fees and limits. This high degree of centralization (7.3 Access Control) enables the owner to significantly impact the token's economy, potentially leading to unfair advantages, market manipulation, or malicious actions (7.4 Economic).
FixConsider implementing a multi-signature wallet or a time-locked governance mechanism for sensitive functions. For parameters that must remain adjustable, implement reasonable bounds and transparent update procedures. Clearly communicate the extent of owner control to the community.
StatusUnresolved
High

Extremely High and Punitive Transaction Taxes

H-02The contract implements initial buy/sell taxes of 25% and a transfer tax of 70% for regular transfers between non-owner addresses after the first buy. These excessively high tax rates (7.4 Economic) are highly punitive, making the token unattractive for holding or transferring and strongly indicating a 'honeypot' characteristic. The owner's ability to dynamically modify these taxes at will further exacerbates the risk of exploitation.
IssueThe contract implements initial buy/sell taxes of 25% and a transfer tax of 70% for regular transfers between non-owner addresses after the first buy. These excessively high tax rates (7.4 Economic) are highly punitive, making the token unattractive for holding or transferring and strongly indicating a 'honeypot' characteristic. The owner's ability to dynamically modify these taxes at will further exacerbates the risk of exploitation.
FixSignificantly reduce all transaction taxes to foster a healthy and sustainable token economy. Consider implementing a fixed, transparent, and immutable tax structure to build trust and prevent potential abuse by the owner. Clearly document the tax mechanics and their purpose.
StatusUnresolved
Medium

Potential DoS for Sellers via `_taxWallet` Revert

M-01The `_transfer` function, specifically during sell operations to `uniswapV2Pair`, calls `sendETHToFee` to forward collected ETH to `_taxWallet`. If `_taxWallet` is a contract that is unable to receive ETH (e.g., due to a missing `receive()`/`fallback()` function or intentional revert logic), the `sendETHToFee` call will revert. This would cause the entire `_transfer` transaction to fail, effectively denying service for all sell transactions (7.2 Code Security, 7.8 Operations).
IssueThe `_transfer` function, specifically during sell operations to `uniswapV2Pair`, calls `sendETHToFee` to forward collected ETH to `_taxWallet`. If `_taxWallet` is a contract that is unable to receive ETH (e.g., due to a missing `receive()`/`fallback()` function or intentional revert logic), the `sendETHToFee` call will revert. This would cause the entire `_transfer` transaction to fail, effectively denying service for all sell transactions (7.2 Code Security, 7.8 Operations).
FixEnsure the `_taxWallet` is either an Externally Owned Account (EOA) or a robust contract designed to safely receive ETH. Implement a `try/catch` block around the `sendETHToFee` call to handle potential reverts gracefully, preventing the entire transaction from failing. Consider adding a mechanism to change the `_taxWallet` in case of issues.
StatusUnresolved
Medium

Anti-Bot/Anti-Whale Mechanisms Can Be Abused

M-02The contract includes `_maxTxAmount`, `_maxWalletSize`, and a `bots` mapping to prevent manipulation. However, these mechanisms are controlled by the owner, who can add or remove addresses from the `bots` list, effectively exempting them from taxes and limits (7.3 Access Control). This could be used to grant preferential treatment or manipulate the market. Additionally, the `sellCount` limit of 3 sells per block, while intended to prevent rapid dumping, can lead to legitimate users being unable to sell, causing frustration and potential DoS for sellers (7.4 Economic).
IssueThe contract includes `_maxTxAmount`, `_maxWalletSize`, and a `bots` mapping to prevent manipulation. However, these mechanisms are controlled by the owner, who can add or remove addresses from the `bots` list, effectively exempting them from taxes and limits (7.3 Access Control). This could be used to grant preferential treatment or manipulate the market. Additionally, the `sellCount` limit of 3 sells per block, while intended to prevent rapid dumping, can lead to legitimate users being unable to sell, causing frustration and potential DoS for sellers (7.4 Economic).
FixImplement transparent criteria and a decentralized process for managing bot lists or consider removing the ability to exempt specific addresses. Re-evaluate the sell limit per block to ensure it does not unduly restrict legitimate trading activity. Clearly document the purpose and impact of these mechanisms.
StatusUnresolved
Info

Incomplete Code Snippet / Missing `sendETHToFee` Implementation

I-01The provided contract snippet is incomplete, specifically lacking the implementation of the `sendETHToFee` function and the contract's `receive()` or `fallback()` payable function. While the contract's balance suggests a `receive()`/`fallback()` exists, the absence of these critical components in the audit scope prevents a full security assessment of their logic and potential vulnerabilities (7.1 Architecture, 7.2 Code Security).
IssueThe provided contract snippet is incomplete, specifically lacking the implementation of the `sendETHToFee` function and the contract's `receive()` or `fallback()` payable function. While the contract's balance suggests a `receive()`/`fallback()` exists, the absence of these critical components in the audit scope prevents a full security assessment of their logic and potential vulnerabilities (7.1 Architecture, 7.2 Code Security).
FixProvide the complete and final source code for all relevant functions and contracts to enable a comprehensive security audit. Ensure all external calls and ETH handling logic are explicitly defined and reviewed.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract utilizes `SafeMath` for arithmetic operations, mitigating common integer overflow/underflow vulnerabilities. Standard ERC-20 functionality is implemented correctly. However, the `_transfer` function's reliance on external calls to `sendETHToFee` (7.2 Code Security) introduces a potential Denial of Service if the `_taxWallet` reverts on receiving ETH. The `lockTheSwap` modifier helps prevent reentrancy during token swaps.

GovernanceMedium5/10

The economic model presents significant risks, primarily due to an **unlocked liquidity pool** (7.4 Economic), which enables a rug pull by the deployer. The contract exhibits **high centralization** (7.3 Access Control) with the owner possessing extensive control over critical parameters, including the ability to set extremely high initial buy/sell taxes (25%) and a punitive 70% transfer tax (7.4 Economic). These high taxes, coupled with the owner's ability to modify them, create a 'honeypot' characteristic, deterring legitimate participation.

UpgradesLow9/10

The contract is not designed with upgradeability mechanisms (7.7 Upgrades), meaning its logic cannot be modified post-deployment. This eliminates risks associated with proxy patterns or upgrade safety but also means any discovered vulnerabilities or desired feature changes would require a new deployment.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

32.5% in top 10
5.2% in wallets27.3% in contracts
Effective Concentration16.2%

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

$20.6K

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

LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

2 addresses
Deployer
0x2997…ac31
Unlocked LP Held By
0x2997…ac31

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

What Raised This Score

5 factors
  • Liquidity < $50k ($20,592 across 1 pairs — thin market)
  • Token age < 7 days (early, volatile)
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 Medium 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

Related Audits

6 more on the record
VERA (VRA)Medium RiskStarmanMedium RiskI love puppies (PUPPIES)Medium RiskAliensMedium RiskwojakMedium RiskBalancer (BAL)Medium Risk

Would You Like a More Detailed Audit of Prometheus?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit