Quantum Audit Logo

Is SPECTRE AI Safe?

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

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

SPECTRE AI SPECTRE
0x9cf0…dad6
Ethereum
Not verifiedThis 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 7d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The SpectreAI token contract implements standard ERC-20 functionality with additional features like transaction taxes, anti-whale/anti-bot mechanisms, and an automatic liquidity provision system. The audit identified a critical reentrancy-related vulnerability in the swap mechanism that can halt fee collection, alongside high-severity centralization risks and reliance on `block.timestamp` for security. Several medium and low-severity issues were also found, primarily concerning transparency and potential for economic manipulation by the owner.

1 Critical2 High1 Medium1 Low1 Informational
Volume 24h
$79.1K
Liquidity
$511.2K
Price
$0.5735
Token Age
2y
Top 10 Holders
20.8%

Security Findings

1 Crit2 High1 Med1 Low1 Info
Critical

Reentrancy Vulnerability / Stuck Swap Mechanism

C-01The `_transfer` function's logic for swapping tokens to ETH (when `to == uniswapV2Pair`) uses an `inSwapAndLiquify` flag to prevent reentrancy during the external call to `uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens`. However, the provided code snippet shows that `inSwapAndLiquify` is set to `1` before the external call but is never reset to `0`. This means that once a swap is initiated, the `inSwapAndLiquify` flag will remain `1` indefinitely, preventing any subsequent fee collection or liquidity provision through this mechanism. This effectively halts a core economic function of the token.
IssueThe `_transfer` function's logic for swapping tokens to ETH (when `to == uniswapV2Pair`) uses an `inSwapAndLiquify` flag to prevent reentrancy during the external call to `uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens`. However, the provided code snippet shows that `inSwapAndLiquify` is set to `1` before the external call but is never reset to `0`. This means that once a swap is initiated, the `inSwapAndLiquify` flag will remain `1` indefinitely, preventing any subsequent fee collection or liquidity provision through this mechanism. This effectively halts a core economic function of the token.
FixEnsure the `inSwapAndLiquify` flag is reset to `0` immediately after the external call to `uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens` completes. A common pattern is to use a `try-catch` block or a `modifier` to ensure the flag is reset even if the external call reverts.
StatusUnresolved
High

Excessive Centralization of Control

H-01The `Ownable` contract grants the owner extensive control over critical contract parameters and functions. The owner can `addExcludedWallet`, `openTrading`, `setLimit`, `removeAllLimits`, and `changeTax` without any timelock or community governance. This high degree of centralization introduces significant trust assumptions, as a malicious or compromised owner could manipulate taxes, disable limits, or exclude specific wallets from fees, potentially leading to economic exploitation or unfair advantage.
IssueThe `Ownable` contract grants the owner extensive control over critical contract parameters and functions. The owner can `addExcludedWallet`, `openTrading`, `setLimit`, `removeAllLimits`, and `changeTax` without any timelock or community governance. This high degree of centralization introduces significant trust assumptions, as a malicious or compromised owner could manipulate taxes, disable limits, or exclude specific wallets from fees, potentially leading to economic exploitation or unfair advantage.
FixConsider implementing a multi-signature wallet for ownership or introducing a timelock mechanism for sensitive administrative functions. This would provide a delay before critical changes take effect, allowing the community to react and reducing the risk of immediate malicious actions. Explore options for decentralizing control over key parameters through a governance mechanism.
StatusUnresolved
High

Reliance on `block.timestamp` for Anti-Bot Measures

H-02The `_delayBetweenTx` mechanism, intended to prevent rapid transactions (e.g., by bots), relies on `block.timestamp`. Miners have a degree of control over `block.timestamp` (they can set it within a certain range, typically up to 900 seconds in the future on Ethereum). This manipulation could potentially allow sophisticated bots or miners to bypass or exploit the transaction delay protection, undermining the anti-bot measures.
IssueThe `_delayBetweenTx` mechanism, intended to prevent rapid transactions (e.g., by bots), relies on `block.timestamp`. Miners have a degree of control over `block.timestamp` (they can set it within a certain range, typically up to 900 seconds in the future on Ethereum). This manipulation could potentially allow sophisticated bots or miners to bypass or exploit the transaction delay protection, undermining the anti-bot measures.
FixWhile `block.timestamp` is commonly used, be aware of its limitations. For more robust time-based security, consider using `block.number` in conjunction with an estimated block time, or integrate with a decentralized oracle network that provides reliable timestamp data if precise, unmanipulable time is critical. For simple delays, `block.timestamp` is often acceptable, but the risk should be acknowledged.
StatusUnresolved
Medium

Potential Slippage or Sandwich Attack Vulnerability in Swap

M-01The code snippet for `uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens` is truncated. If the `amountOutMin` parameter is not properly calculated and set to a non-zero value, the swap operation could be vulnerable to sandwich attacks or significant slippage. An `amountOutMin` of zero or a very low value allows attackers to front-run the transaction, manipulate the price, and profit from the difference, resulting in fewer ETH received by the contract for the swapped tokens.
IssueThe code snippet for `uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens` is truncated. If the `amountOutMin` parameter is not properly calculated and set to a non-zero value, the swap operation could be vulnerable to sandwich attacks or significant slippage. An `amountOutMin` of zero or a very low value allows attackers to front-run the transaction, manipulate the price, and profit from the difference, resulting in fewer ETH received by the contract for the swapped tokens.
FixEnsure that `amountOutMin` is always calculated based on a reasonable slippage tolerance (e.g., 0.5% to 1%) and passed to the `swapExactTokensForETHSupportingFeeOnTransferTokens` function. This protects the contract from receiving significantly less ETH than expected due to price manipulation or high network congestion.
StatusUnresolved
Low

Lack of Event Emission for Critical State Changes

L-01Several critical administrative functions, such as `setLimit`, `removeAllLimits`, `changeTax`, and `addExcludedWallet`, do not emit corresponding events upon execution. While the state changes occur on-chain, the absence of events makes it difficult for off-chain applications, block explorers, and users to monitor these significant administrative actions. This reduces transparency and auditability of the contract's operational history.
IssueSeveral critical administrative functions, such as `setLimit`, `removeAllLimits`, `changeTax`, and `addExcludedWallet`, do not emit corresponding events upon execution. While the state changes occur on-chain, the absence of events makes it difficult for off-chain applications, block explorers, and users to monitor these significant administrative actions. This reduces transparency and auditability of the contract's operational history.
FixEmit specific events for all functions that modify critical contract state. For example, `event TaxChanged(uint256 newBuyTax, uint256 newSellTax)` or `event WalletExcluded(address indexed wallet, bool isExcluded)`. This enhances transparency and allows for easier monitoring and auditing of administrative actions.
StatusUnresolved
Info

Hardcoded Uniswap Router Address

I-01The Uniswap V2 Router address (0x7a25…488D) is hardcoded in the contract's constructor. While this is a common practice for well-established protocols, it means that if the Uniswap router address ever changes (e.g., due to an upgrade or migration) or if the project wishes to integrate with a different DEX, the contract would need to be redeployed. This lacks flexibility.
IssueThe Uniswap V2 Router address () is hardcoded in the contract's constructor. While this is a common practice for well-established protocols, it means that if the Uniswap router address ever changes (e.g., due to an upgrade or migration) or if the project wishes to integrate with a different DEX, the contract would need to be redeployed. This lacks flexibility.
FixConsider making critical external contract addresses configurable by the owner (with appropriate access control and timelocks) or through a governance mechanism. This would allow for greater flexibility in adapting to ecosystem changes without requiring a full contract redeployment.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract's technical architecture (7.1) is a standard ERC-20 with added tax and anti-bot logic. Code security (7.2) is compromised by a critical reentrancy vulnerability in the `_transfer` function's swap logic, where the `inSwapAndLiquify` flag is not reset, effectively blocking future swaps. Access control (7.3) is correctly implemented using `onlyOwner` for administrative functions, but the reliance on `block.timestamp` for transaction delays (7.2) introduces a potential for miner manipulation. External interactions (7.6) with Uniswap V2 are present, but the truncated code snippet prevents a full review of `amountOutMin` parameter usage, which could lead to slippage.

GovernanceLow7/10

The economic model (7.4) includes buy/sell taxes and anti-whale/anti-bot limits. However, the governance model (7.5) is highly centralized, with the owner having extensive control over these parameters, including the ability to change taxes, set transaction limits, and exclude wallets from fees. This introduces significant trust assumptions and potential for economic manipulation. For example, the owner can change `buyTax` and `sellTax` at any time, which could be abused. The `marketingWallet` is immutable, which is a good practice for fixed destinations.

UpgradesLow9/10

The SpectreAI contract is not designed as an upgradeable proxy contract (7.7). It is a standard, non-upgradeable implementation. Therefore, there are no upgrade-related risks or concerns.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.1%Sell Tax0.0%

Holder Composition

20.8% in top 10
12.5% in wallets8.3% in contracts
Effective Concentration15.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

$511.2K

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 Locked100.0% · Null Address, TeamFinance

Key Addresses

1 addresses
Deployer
0x0c23…e9f9

What Raised This Score

4 factors
  • 1 Critical finding(s) from audit
  • 2 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

Related Audits

6 more on the record
FuseMedium RiskClawdMedium RiskShiba Inu (SHIB)Medium RiskGrand Theft Auto VI (GTAVI)Medium RiskUnipeg (UPEG)Medium RiskKekius Maximus (KEKIUS)Medium Risk

Would You Like a More Detailed Audit of SPECTRE AI?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit