Quantum Audit Logo
Launch App

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

Is Ixs Token Safe?

IXSEthereum
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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance3/10Upgrades4/10Checks passed5 of 7Findings1 High · 1 Medium · 2 Low · 2 Info6
SummaryAI Copilot

The IxsToken contract implements a standard ERC20 token with minting and burning capabilities, utilizing OpenZeppelin's SafeMath and role-based access control for Minter and Pauser functionalities.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • LP top1 unlocked holder = 89.9%
  • LP top3 unlocked holders = 100.0%
  • 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
Exact 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

Security Checklist

as of audit · Sep 45 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
17.3%Contracts8.0%Wallets74.7%Everyone else
17.3%Contracts8.0%74.7%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
25.3%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking17.3%
  • Walletsanonymous holders, free to sell8.0%
  • Everyone elsethe rest of the supply74.7%
Effective concentrationwhat the score reads14.9%
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$757.3K across 3 pairs

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$516.2KShare of depth68.2%
Top-1 Unlocked Holder89.9%
Top-3 Unlocked100.0%
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.

Security Findings

1 High1 Medium2 Low2 Info
High

Centralization of Minter and Pauser Roles

The 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.H-01

Issue

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

Fix

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

Status

Unresolved

Medium

Lack of Multi-Signature for Critical Operations

While 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.M-01

Issue

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

Fix

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

Status

Unresolved

Low

Outdated Solidity Compiler Version

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

Issue

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

Fix

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

Status

Unresolved

Low

Missing Emergency Token Recovery Mechanism

The 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.L-02

Issue

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

Fix

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

Status

Unresolved

Info

ERC20 approve Function Race Condition

The 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.I-01

Issue

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

Fix

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

Status

Unresolved

Info

Unused _msgData() in Context

The _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.I-02

Issue

The _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.

Fix

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

Status

Unresolved

Analysis

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

The IxsToken contract implements a standard ERC20 token with minting and burning capabilities, utilizing OpenZeppelin's SafeMath and role-based access control for Minter and Pauser functionalities. The code is generally well-structured and follows common patterns. However, significant centralization risks exist due to critical roles being controlled by a single address, and the use of an older Solidity compiler version introduces potential for missing modern security features.

Technical7/10Low risk

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.

Governance3/10High risk

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

Upgrades4/10Medium risk

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.

Final RecommendationWhat to do about this score

It is strongly recommended to implement a multi-signature wallet for managing the MinterRole and PauserRole to mitigate the risks associated with centralized control.

Consider upgrading the Solidity compiler version to a more recent release (e.g., 0.8.x) to benefit from improved security features and gas optimizations. Implement a recovery mechanism for accidentally sent tokens to prevent permanent loss of funds.

Contract & Record

1 audit on record
TypeIxsToken
NetworkEthereum
Token age8mo
Contract0x73d7…d1b4
Deployer0xdcb9…668f
Badge for your website
Ixs Token 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 2, 202654Medium

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

Related Audits

6 more on the recordAll audits
MorphoEthereum54MediumBeamEthereum54MediumSuperVerseSUPER · Ethereum54Medium00 Token00 · Ethereum54MediumAlberich TokenALBRH · Ethereum54MediumSpiceSFI · Ethereum54Medium

Would You Like a More Detailed Audit of Ixs Token?

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