Is Aliens Safe? Smart Contract Security Analysis

Security Findings

1 Crit2 High2 Med1 Low1 Info

Critical

Centralized Control and Potential for Rug Pull

C-01The 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…

IssueThe 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…

FixImplement 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.

StatusUnresolved

High

Reentrancy Vulnerability in `sendETHToFee`

H-01The `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)

IssueThe `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)

FixApply 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.

StatusUnresolved

High

`tx.origin` Usage for Transfer Delay

H-02The `_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)

IssueThe `_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)

FixReplace `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`.

StatusUnresolved

Medium

High Initial Taxes and Dynamic Tax Changes

M-01The 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)

IssueThe 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)

FixConsider 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.

StatusUnresolved

Medium

Anti-Bot/Anti-Whale Mechanisms Can Be Abused

M-02The 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)

IssueThe 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)

FixEnsure 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.

StatusUnresolved

Low

Redundant `min` Function Definition

L-01The 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)

IssueThe 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)

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

StatusUnresolved

Info

Lack of Event Emission for Critical State Changes

I-01Several 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)

IssueSeveral 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)

FixEmit 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.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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).

GovernanceMedium6/10

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.

UpgradesLow9/10

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.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

41.6% in top 10

14.4% in wallets27.2% in contracts

Effective Concentration25.3%

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

$43.1K

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

1 addresses

Deployer

0xc607…9066

What Raised This Score

6 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

Is Aliens Safe?

Security Findings

Centralized Control and Potential for Rug Pull

Reentrancy Vulnerability in `sendETHToFee`

`tx.origin` Usage for Transfer Delay

High Initial Taxes and Dynamic Tax Changes

Anti-Bot/Anti-Whale Mechanisms Can Be Abused

Redundant `min` Function Definition

Lack of Event Emission for Critical State Changes

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Aliens?