Is Ixs Token (IXS) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med2 Low2 Info

High

Centralization of Minter and Pauser Roles

H-01The `MinterRole` and `PauserRole` are critical roles that grant the ability to mint new tokens (potentially inflating supply) and pause all token transfers, respectively. Both roles are initially assigned to the contract deployer in their respective constructors (`MinterRole` and `PauserRole`). This creates a single point of failure, as a compromise of the deployer's private key would allow an attacker to mint arbitrary tokens or halt all token operations.

IssueThe `MinterRole` and `PauserRole` are critical roles that grant the ability to mint new tokens (potentially inflating supply) and pause all token transfers, respectively. Both roles are initially assigned to the contract deployer in their respective constructors (`MinterRole` and `PauserRole`). This creates a single point of failure, as a compromise of the deployer's private key would allow an attacker to mint arbitrary tokens or halt all token operations.

FixImplement a multi-signature wallet (e.g., Gnosis Safe) to control the `MinterRole` and `PauserRole`. This would require multiple independent approvals for any sensitive action, significantly reducing the risk of a single point of compromise.

StatusUnresolved

Medium

Lack of Multi-Signature for Critical Operations

M-01While the contract implements role-based access control for minting and pausing, the management of these roles (adding/removing minters/pausers) is also controlled by existing minters/pausers. Without a multi-signature wallet or a more robust governance mechanism, a single compromised Minter or Pauser could unilaterally add new malicious role holders or remove legitimate ones, leading to a loss of control.

IssueWhile the contract implements role-based access control for minting and pausing, the management of these roles (adding/removing minters/pausers) is also controlled by existing minters/pausers. Without a multi-signature wallet or a more robust governance mechanism, a single compromised Minter or Pauser could unilaterally add new malicious role holders or remove legitimate ones, leading to a loss of control.

FixFor critical administrative functions, especially those involving role management, consider integrating a multi-signature wallet or a time-locked governance mechanism. This adds an extra layer of security by requiring consensus for sensitive changes.

StatusUnresolved

Low

Outdated Solidity Compiler Version

L-01The contract uses Solidity compiler version `^0.5.0`. Newer Solidity versions (e.g., 0.8.x) include significant security enhancements, such as default integer overflow/underflow checks (removing the need for SafeMath in many cases), custom errors for more efficient error handling, and improved gas optimizations. Using an older version might miss out on these benefits and potentially expose the contract to known compiler-related issues that have since been patched.

IssueThe contract uses Solidity compiler version `^0.5.0`. Newer Solidity versions (e.g., 0.8.x) include significant security enhancements, such as default integer overflow/underflow checks (removing the need for SafeMath in many cases), custom errors for more efficient error handling, and improved gas optimizations. Using an older version might miss out on these benefits and potentially expose the contract to known compiler-related issues that have since been patched.

FixConsider upgrading the Solidity compiler version to a more recent and stable release (e.g., 0.8.x). Thoroughly test the contract after the upgrade to ensure compatibility and correct functionality.

StatusUnresolved

Low

Missing Emergency Token Recovery Mechanism

L-02The contract does not include a function to recover ERC20 tokens or native currency (ETH) that might be accidentally sent to the contract address. If any unsupported tokens or ETH are sent to the contract, they will become permanently locked and inaccessible, leading to a loss of funds.

IssueThe contract does not include a function to recover ERC20 tokens or native currency (ETH) that might be accidentally sent to the contract address. If any unsupported tokens or ETH are sent to the contract, they will become permanently locked and inaccessible, leading to a loss of funds.

FixImplement a function, callable only by an authorized address (e.g., a multi-sig wallet), to recover accidentally sent ERC20 tokens and native currency. This function should allow specifying the token address and recipient.

StatusUnresolved

Info

ERC20 `approve` Function Race Condition

I-01The standard ERC20 `approve` function is susceptible to a known race condition. If a user approves an amount, and then attempts to change that approval to a different amount before the first transaction is mined, an attacker could front-run the second `approve` transaction. This could result in the spender being able to spend both the original and the new approved amount, effectively doubling the allowance. While `increaseAllowance` and `decreaseAllowance` functions are provided to mitigate this, the base `approve` function still exists.

IssueThe standard ERC20 `approve` function is susceptible to a known race condition. If a user approves an amount, and then attempts to change that approval to a different amount before the first transaction is mined, an attacker could front-run the second `approve` transaction. This could result in the spender being able to spend both the original and the new approved amount, effectively doubling the allowance. While `increaseAllowance` and `decreaseAllowance` functions are provided to mitigate this, the base `approve` function still exists.

FixEducate users and integrators to primarily use `increaseAllowance` and `decreaseAllowance` instead of directly calling `approve` when modifying an existing allowance. If `approve` must be used, advise setting the allowance to zero first before setting a new non-zero value.

StatusUnresolved

Info

Unused `_msgData()` in `Context`

I-02The `_msgData()` function in the `Context` contract contains the statement `this;`. This statement is a no-op and does not affect the contract's logic or state. It can be removed without any functional impact.

IssueThe `_msgData()` function in the `Context` contract contains the statement `this;`. This statement is a no-op and does not affect the contract's logic or state. It can be removed without any functional impact.

FixRemove the `this;` statement from the `_msgData()` function in the `Context` contract for cleaner and more optimized code.

StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract implements a standard ERC20 token with minting and burning capabilities, leveraging OpenZeppelin's `SafeMath` for arithmetic safety (7.2 Code Security). The architecture is modular, inheriting from `Context`, `IERC20`, `ERC20Detailed`, `MinterRole`, and `PauserRole` (7.1 Architecture). However, the use of Solidity 0.5.0 is outdated, missing modern security features and optimizations (7.2 Code Security). Additionally, the `_msgData()` function in `Context` contains an unnecessary `this;` statement.

GovernanceHigh3/10

The token's economic model includes minting and burning, controlled by specific roles. The `MinterRole` and `PauserRole` are critical for token supply management and emergency control (7.4 Economic). However, these roles are initially assigned to the contract deployer, creating a single point of failure (7.3 Access Control). There is no multi-signature or decentralized governance mechanism to manage these powerful roles, posing a significant centralization risk (7.5 Governance).

UpgradesMedium4/10

The contract does not incorporate any upgradeability patterns (7.7 Upgrades). This means the contract's logic is immutable once deployed, preventing future bug fixes, feature enhancements, or adjustments to tokenomics without a complete redeployment and migration. While this eliminates upgrade-related risks, it sacrifices flexibility.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

25.3% in top 10

8.0% in wallets17.3% in contracts

Effective Concentration14.9%

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

$757.3K across 3 pairs

Uniswap v4ETHanalysed$516.2K Uniswap v2WETH$241.0K Uniswap v3WETH$155

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 Holder89.9%

Top-3 Unlocked100.0%

Key Addresses

8 addresses

Deployer

0xdcb9…668f

Unlocked LP Held By

0x9c09…bbd70xf062…edf20x035d…d1090x634f…b0ca0x4f27…f9da0x135d…04700x1f2f…f387

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
LP top1 unlocked holder = 89.9% (independent LP — depth risk, pool = 68% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 68% of DEX liquidity)
LP claimed locked but only 0.0% actually locked
1 High finding(s) from audit
1 Medium finding(s) from audit
2 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 Ixs Token Safe?

Security Findings

Centralization of Minter and Pauser Roles

Lack of Multi-Signature for Critical Operations

Outdated Solidity Compiler Version

Missing Emergency Token Recovery Mechanism

ERC20 `approve` Function Race Condition

Unused `_msgData()` in `Context`

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 Ixs Token?