Early-stage security check — honeypot & rug-pull analysis
EthereumThe Prometheus token contract implements custom tax mechanisms, anti-bot/anti-whale features, and automated liquidity management.
Read the full analysisEach 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
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
The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0x2997…ac31A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.
The 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).
Immediately 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.
Unresolved
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).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).
Consider 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.
Unresolved
The 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.
Significantly 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.
Unresolved
_taxWallet Revert_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).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).
Ensure 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.
Unresolved
_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).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).
Implement 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.
Unresolved
sendETHToFee ImplementationsendETHToFee 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).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).
Provide 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.
Unresolved
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.
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.
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.
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.
It is strongly recommended that users exercise extreme caution when interacting with this contract due to the critical risk of a rug pull from the unlocked liquidity pool.
The project should immediately lock its liquidity to protect investor funds. Furthermore, the excessively high and dynamic tax rates, coupled with the extensive owner control, create an unfavorable and potentially exploitative economic environment. The project should consider significantly reducing tax rates, implementing a more transparent and immutable tax structure, and decentralizing control over critical parameters to build trust and foster a sustainable ecosystem.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.
Get Detailed Audit Is this your token? Publish your own audit on this page
