Quantum Audit Logo

Is Aethir Token Safe?

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

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

Aethir Token ATH
0xbe0e…226b
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 today 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The AethirToken contract, an ERC20Permit implementation, features a whitelisting mechanism for token distribution controlled by an owner multisig. Critical vulnerabilities were identified, including a fundamental flaw in the token transfer mechanism that prevents distribution of minted tokens, and a re-whitelisting vulnerability allowing users to bypass transfer limits. These issues severely impact the token's intended functionality and economic model. Additionally, the contract exhibits high centralization of power with the owner.

2 Critical1 High1 Medium
Volume 24h
$168.0K
Liquidity
$354.4K
Price
$0.005491
Token Age
2y
Top 10 Holders
78.8%

Security Findings

2 Crit1 High1 Med
Critical

Critical Logic Error in Token Distribution (`SafeERC20.safeTransfer(this, ...)` Misuse)

C-01The `transferToWhitelisted` function, intended to distribute tokens from the contract's balance, incorrectly uses `SafeERC20.safeTransfer(this, to, amount)`. `SafeERC20.safeTransfer` is designed for a contract to transfer *another* ERC20 token it holds. To transfer its *own* tokens (which were minted to `address(this)`), the contract must use the internal `_transfer(address(this), to, amount)` function. As implemented, `transferToWhitelisted` will fail to move tokens, effectively locking all minted tokens within the contract and making the token unusable for its intended purpose of distribution.
IssueThe `transferToWhitelisted` function, intended to distribute tokens from the contract's balance, incorrectly uses `SafeERC20.safeTransfer(this, to, amount)`. `SafeERC20.safeTransfer` is designed for a contract to transfer *another* ERC20 token it holds. To transfer its *own* tokens (which were minted to `address(this)`), the contract must use the internal `_transfer(address(this), to, amount)` function. As implemented, `transferToWhitelisted` will fail to move tokens, effectively locking all minted tokens within the contract and making the token unusable for its intended purpose of distribution.
FixReplace `SafeERC20.safeTransfer(this, to, amount);` with `_transfer(address(this), to, amount);` in the `transferToWhitelisted` function. Ensure that the contract's internal balance is correctly managed for transfers.
StatusUnresolved
Critical

Re-whitelisting/Re-transfer Vulnerability via `_afterTokenTransfer`

C-02The `_afterTokenTransfer` override contains logic that allows whitelisted users to bypass their `allowedAmount` limits. If a whitelisted user sends tokens back to the `AethirToken` contract address, the `_afterTokenTransfer` function reduces their `transferredAmount[from]` and `totalTransferred`. This means a user can receive tokens via `transferToWhitelisted`, send them back to the contract, and then receive more tokens, effectively resetting their `transferredAmount` and exceeding their `allowedAmount`. This breaks the core whitelisting mechanism and can lead to unauthorized token inflation or distribution beyond intended limits.
IssueThe `_afterTokenTransfer` override contains logic that allows whitelisted users to bypass their `allowedAmount` limits. If a whitelisted user sends tokens back to the `AethirToken` contract address, the `_afterTokenTransfer` function reduces their `transferredAmount[from]` and `totalTransferred`. This means a user can receive tokens via `transferToWhitelisted`, send them back to the contract, and then receive more tokens, effectively resetting their `transferredAmount` and exceeding their `allowedAmount`. This breaks the core whitelisting mechanism and can lead to unauthorized token inflation or distribution beyond intended limits.
FixRemove or completely redesign the `_afterTokenTransfer` logic. Transfers *to* the token contract address should generally not affect internal whitelisting state variables like `transferredAmount` or `totalTransferred`. If a burn mechanism is intended, it should be explicit and not tied to general transfers to the contract address.
StatusUnresolved
High

Centralized Control and Minting Power

H-01The `AethirToken` contract grants the `owner` (a multisig wallet) extensive and centralized control over critical functions. The owner can `mint` tokens up to the `MAX_SUPPLY`, `transferToWhitelisted` any amount to whitelisted addresses, and fully manage the whitelisting parameters (`addWhitelisted`, `removeWhitelisted`, `updateWhitelistedMaxAmount`, `updateWhitelistedAddress`). This high degree of centralization means that the integrity of the token supply and distribution relies entirely on the security and good faith of the multisig signers. A compromise of the multisig or malicious intent could lead to significant economic damage or misuse of funds.
IssueThe `AethirToken` contract grants the `owner` (a multisig wallet) extensive and centralized control over critical functions. The owner can `mint` tokens up to the `MAX_SUPPLY`, `transferToWhitelisted` any amount to whitelisted addresses, and fully manage the whitelisting parameters (`addWhitelisted`, `removeWhitelisted`, `updateWhitelistedMaxAmount`, `updateWhitelistedAddress`). This high degree of centralization means that the integrity of the token supply and distribution relies entirely on the security and good faith of the multisig signers. A compromise of the multisig or malicious intent could lead to significant economic damage or misuse of funds.
FixWhile a multisig improves security over a single EOA, consider further decentralization or implementing time-locks for critical actions like large mints or significant changes to whitelisting parameters. Explore integrating with a governance module for key decisions, or at minimum, ensure robust operational security procedures for the multisig.
StatusUnresolved
Medium

Unconventional Token Holding Pattern

M-01The `mint` function calls `_mint(address(this), amount)`, which means all newly minted tokens are held by the `AethirToken` contract itself. This is an unusual pattern for an ERC20 token. Typically, tokens are minted to a specific treasury, vesting contract, or the owner's address for subsequent distribution. Holding all tokens within the token contract makes it a single point of failure for distribution (assuming the `transferToWhitelisted` function worked correctly). This design choice increases the contract's complexity and reliance on the owner's actions for any token movement.
IssueThe `mint` function calls `_mint(address(this), amount)`, which means all newly minted tokens are held by the `AethirToken` contract itself. This is an unusual pattern for an ERC20 token. Typically, tokens are minted to a specific treasury, vesting contract, or the owner's address for subsequent distribution. Holding all tokens within the token contract makes it a single point of failure for distribution (assuming the `transferToWhitelisted` function worked correctly). This design choice increases the contract's complexity and reliance on the owner's actions for any token movement.
FixConsider revising the minting strategy. Mint tokens directly to a dedicated treasury contract or a controlled distribution contract. This separates the token logic from the token holding and distribution responsibilities, improving modularity and potentially security.
StatusUnresolved

Category Ratings

TechnicalHigh3/10

The contract utilizes OpenZeppelin's ERC20 and Ownable for foundational security. However, the custom `transferToWhitelisted` function contains a critical logic error by misusing `SafeERC20.safeTransfer(this, ...)`, rendering minted tokens undistributable (7.2 Code Security). Furthermore, the `_afterTokenTransfer` override introduces a severe re-whitelisting vulnerability, allowing whitelisted users to bypass their `allowedAmount` limits (7.2 Code Security). The architectural choice to mint tokens to the contract address itself is unconventional and contributes to the distribution issues (7.1 Architecture).

GovernanceHigh1/10

The token's economic model is highly centralized, with the owner (a multisig wallet) possessing extensive control over the token supply and distribution (7.4 Economic, 7.5 Governance). The owner can mint tokens up to the `MAX_SUPPLY` and manage all whitelisted transfers. While using a multisig enhances operational security, this level of centralized power introduces significant trust assumptions for token holders and could lead to economic manipulation if the multisig is compromised or acts maliciously (7.3 Access Control).

UpgradesHigh2/10

The AethirToken contract is not designed with upgradeability features, such as a proxy pattern. This means the contract's logic is immutable once deployed, eliminating upgrade-related risks but requiring any future changes to be deployed as a new contract (7.7 Upgrades).

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

78.8% in top 10
14.6% in wallets64.2% in contracts
Effective Concentration40.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

$419.9K across 8 pairs
Uniswap v3WETHanalysed$354.4K84.4%Uniswap v4USDC$20.0K4.8%Uniswap v4USDT$15.0K3.6%Uniswap v4USDC$10.0K2.4%Uniswap v4USDT$10.0K2.4%Uniswap v4USDC$5.0K1.2%
Show 2 more pairsShow less
Uniswap v4USDC$5.0K1.2%Uniswap v4USDT$4800.1%

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

Top-1 Unlocked Holder88.9%
Top-3 Unlocked98.9%

Key Addresses

6 addresses
Deployer
0x9b16…9180
Unlocked LP Held By
0x32e9…d2940x6c63…bb120xaab1…4cf10xfe34…6b450xf922…6794

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

9 factors
  • Ownership NOT renounced — Multisig (2-of-3)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (78.8% total → 40.3% effective; 14.6% in EOAs, 64.2% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 88.9% (independent LP — depth risk, pool = 84% of DEX liquidity)
  • LP top3 unlocked holders = 98.9% (independent LP — depth risk, pool = 84% of DEX liquidity)
  • 2 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 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
trUSDCritical RiskAIOZ Network (AIOZ)Critical RiskMain Street USD (MSUSD)Critical RiskSynapse (SYN)Critical RiskCovalent X Token (CXT)Critical RiskAutonolas (OLAS)Critical Risk

Would You Like a More Detailed Audit of Aethir Token?

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

Get Detailed Audit