Quantum Audit Logo
Launch App

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

Is Illuvium Safe?

ILVEthereum
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
Technical6/10Governance2/10Upgrades3/10Checks passed2 of 5Findings2 High · 1 Medium · 1 Low · 1 Info5
SummaryAI Copilot

This audit covers the IlluviumERC20 token contract. The contract implements a standard ERC-20 token with custom access control, feature flags, and voting power delegation.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (58.7% total → 39.1% effective; 26.0% in EOAs, 32.7% 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 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
32.7%Contracts26.0%Wallets41.3%Everyone else
32.7%Contracts26.0%Wallets41.3%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
58.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking32.7%
  • Walletsanonymous holders, free to sell26.0%
  • Everyone elsethe rest of the supply41.3%
Effective concentrationwhat the score reads39.1%
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$1.97M across 3 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$1.93MShare of depth98.1%
Top-1 Unlocked Holder39.5%
Top-3 Unlocked79.6%
Unlocked LP held by
0x8b4d…3f720xe984…1cc20xb9a3…19b70xa3b0…bf750x59b2…c3390x5f24…b3460x90f6…0bce0x8582…b7bb0x3e8c…250e0x460a…2919

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

Security Findings

2 High1 Medium1 Low1 Info
High

Incomplete Access Control Implementation Details

The IlluviumERC20 contract imports AccessControl.sol, but the source code for this critical base contract was not provided. This prevents a full audit of how roles (e.g., ROLE_TOKEN_CREATOR, ROLE_TOKEN_DESTROYER) are assigned, revoked, and how features (e.g., FEATURE_TRANSFERS) are enabled or disabled. The security of core functions like mint and burn heavily relies on the correct and secure implementation of this access control system.H-01

Issue

The IlluviumERC20 contract imports AccessControl.sol, but the source code for this critical base contract was not provided. This prevents a full audit of how roles (e.g., ROLE_TOKEN_CREATOR, ROLE_TOKEN_DESTROYER) are assigned, revoked, and how features (e.g., FEATURE_TRANSFERS) are enabled or disabled. The security of core functions like mint and burn heavily relies on the correct and secure implementation of this access control system.

Fix

Provide the complete source code for the AccessControl.sol contract to allow for a comprehensive security review of the access control mechanisms. Ensure that role management functions are adequately protected and follow best practices for privilege separation.

Status

Unresolved

High

Truncated Critical Logic for Voting Power

The functions __moveVotingPower (an internal function central to voting power updates) and getVotingPowerAt (a public view function) are truncated in the provided source code. This prevents a thorough security analysis of the voting power delegation mechanism, which is a significant feature of this token. Without the full implementation, potential vulnerabilities such as incorrect voting power calculations, manipulation, or denial-of-service attacks cannot be identified.H-02

Issue

The functions __moveVotingPower (an internal function central to voting power updates) and getVotingPowerAt (a public view function) are truncated in the provided source code. This prevents a thorough security analysis of the voting power delegation mechanism, which is a significant feature of this token. Without the full implementation, potential vulnerabilities such as incorrect voting power calculations, manipulation, or denial-of-service attacks cannot be identified.

Fix

Provide the complete source code for __moveVotingPower and getVotingPowerAt to enable a full audit of the voting power delegation logic. Ensure that all calculations are correct, history is properly maintained, and potential edge cases are handled securely.

Status

Unresolved

Medium

Inconsistent Total Supply Limit

The mint function includes a `require(totalSupply + _value <= type(uint192).max, "total supply overflow (uint192)"); check. While totalSupply is declared as uint256, its maximum value is explicitly limited to type(uint192).max. Individual tokenBalances are also uint256`. This inconsistency in type declaration versus actual limit could lead to confusion or unexpected behavior if not clearly documented, potentially causing mint operations to fail prematurely even if uint256 could accommodate larger values.M-01

Issue

The mint function includes a `require(totalSupply + _value <= type(uint192).max, "total supply overflow (uint192)"); check. While totalSupply is declared as uint256, its maximum value is explicitly limited to type(uint192).max. Individual tokenBalances are also uint256`. This inconsistency in type declaration versus actual limit could lead to confusion or unexpected behavior if not clearly documented, potentially causing mint operations to fail prematurely even if uint256 could accommodate larger values.

Fix

Clarify the design choice behind limiting totalSupply to uint192.max while using uint256 for the variable itself and for tokenBalances. Consider if totalSupply should be uint192 if this is the intended maximum, or if the limit should be removed if uint256 capacity is desired. Ensure this design decision is well-documented.

Status

Unresolved

Low

Standard ERC-20 approve Race Condition

The approve function is susceptible to a known front-running attack. If a user approves an allowance of X and then, before the first transaction is mined, sends another transaction to approve Y, a malicious actor could front-run the second transaction. This allows the attacker to spend X tokens, and then the second approve transaction for Y is mined, allowing the attacker to spend Y tokens, effectively spending X + Y instead of just Y.L-01

Issue

The approve function is susceptible to a known front-running attack. If a user approves an allowance of X and then, before the first transaction is mined, sends another transaction to approve Y, a malicious actor could front-run the second transaction. This allows the attacker to spend X tokens, and then the second approve transaction for Y is mined, allowing the attacker to spend Y tokens, effectively spending X + Y instead of just Y.

Fix

While increaseAllowance and decreaseAllowance functions are provided to mitigate this, users should be educated to use these functions instead of directly calling approve when modifying an existing allowance. If approve must be used, the best practice is to first set the allowance to zero and wait for that transaction to confirm before setting a new allowance.

Status

Unresolved

Info

Centralized Control over Token Supply and Features

The contract design grants significant centralized control to addresses holding specific roles, such as ROLE_TOKEN_CREATOR (for minting tokens) and ROLE_TOKEN_DESTROYER (for burning tokens). Additionally, administrators can enable or disable core token features (e.g., transfers, burns) via feature flags. This level of centralization, while offering flexibility in managing the token, introduces a single point of failure and relies heavily on the trustworthiness and security practices of the entities controlling these roles.I-01

Issue

The contract design grants significant centralized control to addresses holding specific roles, such as ROLE_TOKEN_CREATOR (for minting tokens) and ROLE_TOKEN_DESTROYER (for burning tokens). Additionally, administrators can enable or disable core token features (e.g., transfers, burns) via feature flags. This level of centralization, while offering flexibility in managing the token, introduces a single point of failure and relies heavily on the trustworthiness and security practices of the entities controlling these roles.

Fix

Clearly document the roles, their associated privileges, and the process for assigning/revoking these roles. Consider implementing a multi-signature wallet or a decentralized governance mechanism for critical roles and feature management to reduce centralization risks over time.

Status

Unresolved

Analysis

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

This audit covers the IlluviumERC20 token contract. The contract implements a standard ERC-20 token with custom access control, feature flags, and voting power delegation. Key functionalities include minting, burning, transfers, and allowance management. A significant limitation of this audit is the absence of the AccessControl.sol base contract and truncated critical functions (__moveVotingPower, getVotingPowerAt), which prevents a complete security assessment of the access control and voting delegation mechanisms.

Technical6/10Medium risk

The IlluviumERC20 contract demonstrates good adherence to the ERC-20 standard, including proper event emissions and robust checks for common arithmetic overflows/underflows in increaseAllowance and decreaseAllowance. The implementation of safeTransferFrom with an onERC20Received callback enhances compatibility with contract recipients (7.2 Code Security). However, the audit is significantly hampered by the absence of the AccessControl.sol base contract, making it impossible to fully evaluate the security of role management and feature toggles (7.3 Access Control). Additionally, critical functions related to voting power delegation, such as __moveVotingPower and getVotingPowerAt, are truncated, preventing a comprehensive review of this core functionality (7.1 Architecture, 7.2 Code Security).

Governance2/10High risk

The contract design incorporates a custom access control system with distinct roles such as ROLE_TOKEN_CREATOR and ROLE_TOKEN_DESTROYER, granting significant power over the token supply to specific addresses (7.5 Governance). Feature flags allow administrators to enable or disable core functionalities like transfers and burns, introducing a centralized point of control over the token's operational parameters (7.5 Governance). While this offers flexibility, it also concentrates power, which could pose a risk if these roles are compromised or misused (7.4 Economic). The voting power delegation mechanism, though partially obscured by truncated code, aims to decentralize governance influence (7.5 Governance).

Upgrades3/10High risk

The IlluviumERC20 contract is implemented as a standard, non-upgradeable token contract (7.7 Upgrades). It does not utilize any proxy patterns (e.g., UUPS, Transparent) or other upgrade mechanisms. Consequently, any future modifications or bug fixes would necessitate the deployment of an entirely new contract and a migration of token holders, which is a standard approach for non-upgradeable contracts and carries no inherent upgrade-specific risks.

Final RecommendationWhat to do about this score

To ensure the highest level of security and transparency, it is crucial to provide the complete source code for all imported and truncated contracts, especially AccessControl.sol and the full implementations of __moveVotingPower and getVotingPowerAt.

A thorough review of these components is essential to verify the integrity of access control and voting delegation. Additionally, consider documenting the rationale behind the uint192.max totalSupply limit and educate users about the safer increaseAllowance/decreaseAllowance functions to mitigate known ERC-20 approve race conditions.

Contract & Record

1 audit on record
TypeToken
NetworkEthereum
Token age5y
Contract0x767f…ca0e
Deployer0x0691…f38f
Badge for your website
Illuvium 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 4, 202657Medium
  2. Aug 17, 202662Medium

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

Frequently Asked Questions

What is the ILV contract address?

The Illuvium (ILV) contract on Ethereum is 0x767fe9edc9e0df98e07454847909b5e959d7ca0e. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Illuvium a scam?

Quantum Audit's risk score for Illuvium is 57/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is ILV liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $1.97M.

Who holds ILV?

As of Sep 4, 2026, the 10 largest holders own 58.7% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Paxos GoldPAXG · Ethereum57MediumRailEthereum57MediumFlying TulipFT · Ethereum57MediumTether GoldXAUT · Ethereum58MediumSustainable Aviation FuelSAF · Ethereum56MediumMatrixMTX · Ethereum58Medium

Would You Like a More Detailed Audit of Illuvium?

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