Quantum Audit Logo
Launch App

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

Is Aliens Safe?

ALIENSEthereum
Not verified This 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 Sep 4, 2026 · 1 audit on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance6/10Upgrades9/10Checks passed5 of 5Findings1 Critical · 2 High · 2 Medium · 1 Low · 1 Info7
SummaryAI Copilot

The ALIENS token contract implements standard ERC-20 functionality alongside complex anti-whale, anti-bot, and tax mechanisms.

Read the full analysis
What raised the score
  • Top-10 concentration > 20%
  • Liquidity < $50k
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 20% (41.6% total → 25.3% effective; 14.4% in EOAs, 27.2% in contracts — mild)
  • Liquidity < $50k ($43,081 across 1 pairs — thin market)
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 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

Security Checklist

as of audit · Sep 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
27.2%Contracts14.4%Wallets58.4%Everyone else
27.2%Contracts14.4%58.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
41.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking27.2%
  • Walletsanonymous holders, free to sell14.4%
  • Everyone elsethe rest of the supply58.4%
Effective concentrationwhat the score reads25.3%
How holder types affect the score

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

Liquidity

as of audit · Sep 4$43.1K

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$43.1KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Security Findings

1 Critical2 High2 Medium1 Low1 Info
Critical

Centralized Control and Potential for Rug Pull

The contract owner possesses extensive control over critical economic parameters and operational flags. This includes the ability to set initial/final buy/sell taxes, transaction limits (_maxTxAmount, _maxWalletSize), enable/disable trading (tradingOpen), enable/disable swaps (swapEnabled), and manage a bots list. The removeLimits function allows the owner to completely disable transaction and wallet size restrictions. This level of centralized control enables the owner to manipulate the token's economy, potentially leading to a rug pull by removing liquidity, disabling taxes for themselves, and dumping tokens without restrictions. (7.3 Access Control, 7.4 Economic, 7.5 Governan…C-01

Issue

The contract owner possesses extensive control over critical economic parameters and operational flags. This includes the ability to set initial/final buy/sell taxes, transaction limits (_maxTxAmount, _maxWalletSize), enable/disable trading (tradingOpen), enable/disable swaps (swapEnabled), and manage a bots list. The removeLimits function allows the owner to completely disable transaction and wallet size restrictions. This level of centralized control enables the owner to manipulate the token's economy, potentially leading to a rug pull by removing liquidity, disabling taxes for themselves, and dumping tokens without restrictions. (7.3 Access Control, 7.4 Economic, 7.5 Governan…

Fix

Implement a time-locked multi-signature wallet for critical administrative functions to introduce a delay and require consensus for changes. Consider decentralizing control over some parameters or hardcoding certain values to prevent arbitrary changes. If removeLimits is intended for a specific post-launch phase, ensure clear communication and consider a time-locked mechanism for its activation.

Status

Unresolved

High

Reentrancy Vulnerability in sendETHToFee

The sendETHToFee function performs a direct ETH transfer to _taxWallet using call after a token swap, but before the inSwap reentrancy lock is released. If _taxWallet is a malicious contract, it could reenter the _transfer function (or other functions that interact with the contract's ETH balance) while inSwap is still true, potentially draining the contract's ETH balance before it's fully distributed or accounted for. (7.2 Code Security)H-01

Issue

The sendETHToFee function performs a direct ETH transfer to _taxWallet using call after a token swap, but before the inSwap reentrancy lock is released. If _taxWallet is a malicious contract, it could reenter the _transfer function (or other functions that interact with the contract's ETH balance) while inSwap is still true, potentially draining the contract's ETH balance before it's fully distributed or accounted for. (7.2 Code Security)

Fix

Apply the Checks-Effects-Interactions pattern. Ensure that the inSwap flag is reset immediately after the external call to swapTokensForEth and before sendETHToFee is called, or implement a reentrancy guard specifically for sendETHToFee if it's called independently. Alternatively, ensure _taxWallet is an EOA or a trusted contract that does not reenter.

Status

Unresolved

High

tx.origin Usage for Transfer Delay

The _holderLastTransferTimestamp check within the _transfer function uses tx.origin to enforce a transfer delay (one purchase per block). While this might be intended to prevent contract-based bots, tx.origin is generally discouraged in security-sensitive contexts due to its susceptibility to phishing attacks. A malicious contract could trick a user into calling it, and then that contract could call _transfer on behalf of the user, potentially bypassing msg.sender-based checks if they were present elsewhere, or leading to unexpected behavior. (7.2 Code Security)H-02

Issue

The _holderLastTransferTimestamp check within the _transfer function uses tx.origin to enforce a transfer delay (one purchase per block). While this might be intended to prevent contract-based bots, tx.origin is generally discouraged in security-sensitive contexts due to its susceptibility to phishing attacks. A malicious contract could trick a user into calling it, and then that contract could call _transfer on behalf of the user, potentially bypassing msg.sender-based checks if they were present elsewhere, or leading to unexpected behavior. (7.2 Code Security)

Fix

Replace tx.origin with msg.sender for all access control and state-modifying checks. If the intent is specifically to prevent contract interactions, consider alternative mechanisms that do not rely on tx.origin.

Status

Unresolved

Medium

High Initial Taxes and Dynamic Tax Changes

The contract sets initial buy and sell taxes at 25%, which is exceptionally high and can significantly deter legitimate trading activity and liquidity provision. Furthermore, the owner has the ability to dynamically adjust these tax rates (_initialBuyTax, _finalBuyTax, _initialSellTax, _finalSellTax), tax reduction thresholds (_reduceBuyTaxAt, _reduceSellTaxAt), and swap parameters (_preventSwapBefore, _taxSwapThreshold, _maxTaxSwap). This high degree of flexibility introduces significant economic uncertainty and potential for abuse, as the owner could change taxes at any time to their advantage. (7.4 Economic)M-01

Issue

The contract sets initial buy and sell taxes at 25%, which is exceptionally high and can significantly deter legitimate trading activity and liquidity provision. Furthermore, the owner has the ability to dynamically adjust these tax rates (_initialBuyTax, _finalBuyTax, _initialSellTax, _finalSellTax), tax reduction thresholds (_reduceBuyTaxAt, _reduceSellTaxAt), and swap parameters (_preventSwapBefore, _taxSwapThreshold, _maxTaxSwap). This high degree of flexibility introduces significant economic uncertainty and potential for abuse, as the owner could change taxes at any time to their advantage. (7.4 Economic)

Fix

Consider reducing initial tax rates to a more sustainable level to encourage trading. If dynamic tax changes are necessary, implement a timelock or a community governance mechanism to provide transparency and prevent sudden, arbitrary changes. Clearly communicate the tax structure and any potential changes to the community.

Status

Unresolved

Medium

Anti-Bot/Anti-Whale Mechanisms Can Be Abused

The contract includes robust anti-bot and anti-whale features such as _maxTxAmount, _maxWalletSize, transferDelayEnabled, and a bots mapping. While these are intended to prevent manipulation, the owner's absolute control over these parameters allows for potential abuse. The owner can selectively exclude users, disable limits for specific addresses, or use these features to create a 'honeypot' scenario where limits are enforced during initial buys but removed later to facilitate a large dump. (7.3 Access Control, 7.4 Economic)M-02

Issue

The contract includes robust anti-bot and anti-whale features such as _maxTxAmount, _maxWalletSize, transferDelayEnabled, and a bots mapping. While these are intended to prevent manipulation, the owner's absolute control over these parameters allows for potential abuse. The owner can selectively exclude users, disable limits for specific addresses, or use these features to create a 'honeypot' scenario where limits are enforced during initial buys but removed later to facilitate a large dump. (7.3 Access Control, 7.4 Economic)

Fix

Ensure transparent communication regarding the use and purpose of these anti-manipulation features. Consider implementing a community-driven or time-locked mechanism for changes to these parameters to prevent arbitrary abuse. Clearly define the criteria for adding/removing addresses from the bots list.

Status

Unresolved

Low

Redundant min Function Definition

The contract defines the min function twice, once taking uint256 arguments and once taking uint arguments. Since uint is an alias for uint256 in Solidity, these definitions are functionally identical and redundant. (7.2 Code Security)L-01

Issue

The contract defines the min function twice, once taking uint256 arguments and once taking uint arguments. Since uint is an alias for uint256 in Solidity, these definitions are functionally identical and redundant. (7.2 Code Security)

Fix

Remove one of the min function definitions, as uint and uint256 are the same type. This will improve code clarity and reduce unnecessary duplication.

Status

Unresolved

Info

Lack of Event Emission for Critical State Changes

Several critical state changes, such as modifications to tax rates, transaction limits, tradingOpen, swapEnabled, transferDelayEnabled, _preventSwapBefore, _taxSwapThreshold, _maxTaxSwap, _taxWallet, and the bots mapping, do not emit corresponding events. This lack of event emission makes it difficult for off-chain monitoring tools, block explorers, and users to track important administrative actions and changes to the contract's operational parameters. (7.8 Operations)I-01

Issue

Several critical state changes, such as modifications to tax rates, transaction limits, tradingOpen, swapEnabled, transferDelayEnabled, _preventSwapBefore, _taxSwapThreshold, _maxTaxSwap, _taxWallet, and the bots mapping, do not emit corresponding events. This lack of event emission makes it difficult for off-chain monitoring tools, block explorers, and users to track important administrative actions and changes to the contract's operational parameters. (7.8 Operations)

Fix

Emit events for all critical state changes, especially those controlled by the owner. This enhances transparency, auditability, and allows for better monitoring of the contract's lifecycle and administrative actions.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The ALIENS token contract implements standard ERC-20 functionality alongside complex anti-whale, anti-bot, and tax mechanisms. While SafeMath is used to prevent integer overflows/underflows, the contract exhibits significant centralization risks due to extensive owner control over critical parameters, including taxes, transaction limits, and trading status. A reentrancy vulnerability in the ETH transfer mechanism and the use of tx.origin for transfer delays are also identified. These issues collectively pose a high risk of economic manipulation and potential for a rug pull.

Technical6/10Medium risk

The contract utilizes SafeMath for arithmetic operations, mitigating common integer overflow/underflow vulnerabilities (7.2 Code Security). A lockTheSwap modifier is used to prevent reentrancy during token swaps, which is a good practice. However, a reentrancy vulnerability exists in the sendETHToFee function, allowing a malicious _taxWallet to potentially drain ETH (7.2 Code Security). The use of tx.origin for transfer delay checks is an anti-pattern that can lead to unexpected behavior or be exploited in certain phishing scenarios (7.2 Code Security).

Governance6/10Medium risk

The contract grants the owner extensive control over all critical economic parameters, including initial and final buy/sell taxes, tax reduction thresholds, maximum transaction amounts, maximum wallet sizes, and the ability to enable/disable trading and swaps (7.3 Access Control, 7.4 Economic). The removeLimits function allows the owner to disable all transaction and wallet size restrictions, which is a common feature in 'honeypot' schemes. The owner can also add/remove addresses from a 'bots' list, effectively censoring participants (7.5 Governance). These centralized controls present a significant risk of economic manipulation and potential for a rug pull.

Upgrades9/10Low risk

The contract is not designed with upgradeability patterns (e.g., proxy contracts). Therefore, there are no upgrade-specific risks (7.7 Upgrades). Any changes to the contract's logic would require deploying a new contract and migrating assets, which is a standard practice for non-upgradeable contracts.

Final RecommendationWhat to do about this score

It is strongly recommended to decentralize control over critical contract parameters where possible, or to implement a multi-signature wallet for administrative functions to mitigate single points of failure and reduce rug pull potential.

The identified reentrancy vulnerability in sendETHToFee should be addressed by implementing a Checks-Effects-Interactions pattern or using a reentrancy guard. The use of tx.origin should be replaced with msg.sender for security best practices.

Contract & Record

1 audit on record
TypeRouter, Token
NetworkEthereum
Token age2y
Contract0xc778…0fdc
Deployer0xc607…9066
Badge for your website
Aliens security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202631Low
  2. Aug 12, 202625Low

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

Related Audits

6 more on the recordAll audits
I love puppiesPUPPIES · Ethereum31LowShiba Inu TreatTREAT · Ethereum31LowSolaxySOLX · Ethereum31LowTAU FATAUFA · Ethereum31LowwojakEthereum30LowBalancerBAL · Ethereum30Low

Would You Like a More Detailed Audit of Aliens?

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

Get Detailed Audit Is this your token? Publish your own audit on this page