Is Aethir Token (ATH) Safe? Smart Contract Security Analysis

Security Findings

2 High1 Low2 Info

High

Centralized Control via Minter Role

H-01The `mint` and `burn` functions are protected by the `onlyRole(uint8(Roles.MINTER))` modifier. The `init` function adds `interchainTokenService_` and a user-provided `minter` address to the `MINTER` role. This grants significant power to these addresses, allowing them to arbitrarily mint and burn tokens, directly impacting the token's supply and value. If the `minter` address is an EOA or a single-sig contract, it represents a single point of failure and a high centralization risk (7.3 Access Control, 7.4 Economic).

IssueThe `mint` and `burn` functions are protected by the `onlyRole(uint8(Roles.MINTER))` modifier. The `init` function adds `interchainTokenService_` and a user-provided `minter` address to the `MINTER` role. This grants significant power to these addresses, allowing them to arbitrarily mint and burn tokens, directly impacting the token's supply and value. If the `minter` address is an EOA or a single-sig contract, it represents a single point of failure and a high centralization risk (7.3 Access Control, 7.4 Economic).

FixImplement robust governance or multi-signature control over the `MINTER` role. Consider time-locks or multi-stage processes for critical actions like adding/removing minters or large mint operations to distribute control and reduce single points of failure.

StatusUnresolved

High

Incomplete `RolesBase` Contract

H-02The provided `RolesBase` contract, which is fundamental to the access control system, is truncated. Specifically, the `_addAccountRoles` function is incomplete: `function _addAccountRoles(address account, uint256 accountRoles) i... (truncated)`. Without the full implementation of this core access control logic, a complete security assessment of the role management system (including how roles are added, removed, and proposed) is impossible. This leaves a significant blind spot in the audit (7.2 Code Security).

IssueThe provided `RolesBase` contract, which is fundamental to the access control system, is truncated. Specifically, the `_addAccountRoles` function is incomplete: `function _addAccountRoles(address account, uint256 accountRoles) i... (truncated)`. Without the full implementation of this core access control logic, a complete security assessment of the role management system (including how roles are added, removed, and proposed) is impossible. This leaves a significant blind spot in the audit (7.2 Code Security).

FixProvide the complete source code for all inherited and used contracts, especially critical security components like `RolesBase`, to enable a comprehensive security review and ensure the integrity of the access control mechanisms.

StatusUnresolved

Low

Redundant `_initialize()` Call in Constructor

L-01The `InterchainToken` contract, intended as a proxy implementation, calls `_initialize()` in its constructor. In a proxy pattern (like UUPS or Transparent), the constructor of the implementation contract is executed only once when the implementation itself is deployed, not when the proxy is initialized. The actual initialization for the proxy's storage occurs via an `init` function called on the proxy. While not a direct vulnerability (as `init` correctly uses `_isInitialized()` to prevent re-initialization on the proxy's storage), this constructor call is redundant and can be misleading (7.7 Upgrades).

IssueThe `InterchainToken` contract, intended as a proxy implementation, calls `_initialize()` in its constructor. In a proxy pattern (like UUPS or Transparent), the constructor of the implementation contract is executed only once when the implementation itself is deployed, not when the proxy is initialized. The actual initialization for the proxy's storage occurs via an `init` function called on the proxy. While not a direct vulnerability (as `init` correctly uses `_isInitialized()` to prevent re-initialization on the proxy's storage), this constructor call is redundant and can be misleading (7.7 Upgrades).

FixRemove the `_initialize()` call from the constructor of proxy implementation contracts. Ensure all proxy-related initialization logic resides solely within the designated initializer function (e.g., `init`) to maintain clarity and best practices for upgradeable contracts.

StatusUnresolved

Info

Custom `_spendAllowance` Override

I-01The contract overrides the `_spendAllowance` function with a custom implementation. It uses `_approve(sender, spender, _allowance - amount)` directly. In Solidity 0.8.0+, arithmetic operations automatically check for underflows and overflows, meaning `_allowance - amount` will revert if `amount` is greater than `_allowance`. The `UINT256_MAX` check correctly handles infinite approvals. This custom logic appears safe due to Solidity's built-in checks, but any deviation from standard library implementations warrants careful review (7.2 Code Security).

IssueThe contract overrides the `_spendAllowance` function with a custom implementation. It uses `_approve(sender, spender, _allowance - amount)` directly. In Solidity 0.8.0+, arithmetic operations automatically check for underflows and overflows, meaning `_allowance - amount` will revert if `amount` is greater than `_allowance`. The `UINT256_MAX` check correctly handles infinite approvals. This custom logic appears safe due to Solidity's built-in checks, but any deviation from standard library implementations warrants careful review (7.2 Code Security).

FixDocument the rationale for custom overrides, especially for core ERC20 functionalities. Ensure thorough unit and integration testing covers all edge cases for allowance spending to confirm its robustness.

StatusUnresolved

Info

Inline Assembly Usage

I-02The contract and its inherited `RolesBase` utilize inline assembly for direct storage manipulation (e.g., `sload`, `sstore`) for initialization flags and role management. This approach is used for gas optimization and specific storage patterns (like `keccak256` based mapping keys). While assembly can introduce subtle bugs if not handled correctly, the patterns observed (e.g., using a large constant for `INITIALIZED_SLOT`, `keccak256` for mapping keys) are standard and generally considered safe for preventing storage collisions (7.2 Code Security).

IssueThe contract and its inherited `RolesBase` utilize inline assembly for direct storage manipulation (e.g., `sload`, `sstore`) for initialization flags and role management. This approach is used for gas optimization and specific storage patterns (like `keccak256` based mapping keys). While assembly can introduce subtle bugs if not handled correctly, the patterns observed (e.g., using a large constant for `INITIALIZED_SLOT`, `keccak256` for mapping keys) are standard and generally considered safe for preventing storage collisions (7.2 Code Security).

FixEnsure comprehensive unit and integration tests cover all code paths involving inline assembly. Maintain clear and up-to-date documentation for the storage layout and assembly logic to facilitate future audits and maintenance.

StatusUnresolved

Category Ratings

TechnicalMedium5/10

The contract demonstrates good adherence to ERC20 standards and utilizes modern Solidity features. Custom `_spendAllowance` logic, while deviating from standard libraries, appears safe due to Solidity 0.8+ checks. However, the provided `RolesBase` contract is truncated, preventing a full security assessment of the core access control mechanisms (7.2 Code Security). Additionally, the use of inline assembly for storage management requires careful review, though the patterns used are generally robust (7.2 Code Security).

GovernanceHigh2/10

The economic model relies heavily on the `MINTER` role, which has the power to arbitrarily mint and burn tokens (7.4 Economic). The `init` function assigns this role to the `interchainTokenService_` and a user-defined `minter` address. This introduces a high degree of centralization, as the security and stability of the token supply depend entirely on the integrity and security of these privileged addresses (7.3 Access Control).

UpgradesHigh1/10

The contract is designed as an upgradeable implementation, correctly using an `_isInitialized()` check within its `init` function to prevent re-initialization of the proxy's storage (7.7 Upgrades). However, a redundant `_initialize()` call exists in the constructor of the implementation contract, which is not effective for proxy initialization and can be misleading (7.7 Upgrades). The use of `immutable` variables is correctly handled in the proxy context.

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyFail

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

Upgrades (30d)0 · stable

Holder Composition

74.9% in top 10

3.6% in wallets71.2% in contracts

Effective Concentration32.1%

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

$51.6K across 3 pairs

UniswapWETHanalysed$49.6K UniswapWETH$2.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

Top-1 Unlocked Holder32.9%

Top-3 Unlocked78.7%

Key Addresses

11 addresses

Deployer

0xc778…f4ae

Unlocked LP Held By

0x479a…d4970x75d1…107e0x72d6…58130x162d…b9e90x2322…a3e80xa54c…dd780xd1d3…85320x87c0…66400x785d…98b70x34a9…1fc2

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

What Raised This Score

8 factors

Ownership status UNKNOWN (owner could not be resolved)
Mintable supply — no cap found, dilution unbounded
Proxy contract (upgradeable — admin can replace logic)
Non-standard proxy storage (Etherscan-confirmed)
Top-10 concentration > 30% (74.9% total → 32.1% effective; 3.6% in EOAs, 71.2% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
2 High 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 Aethir Token Safe?

Security Findings

Centralized Control via Minter Role

Incomplete `RolesBase` Contract

Redundant `_initialize()` Call in Constructor

Custom `_spendAllowance` Override

Inline Assembly Usage

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Aethir Token?