Quantum Audit Logo

Is Illuvium Safe?

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

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

Illuvium ILV
0x767f…ca0e
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive 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. 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.

2 High1 Medium1 Low1 Informational
Volume 24h
$54.0K
Liquidity
$1.93M
Price
$3.1200
Token Age
5y
Top 10 Holders
58.7%

Security Findings

2 High1 Med1 Low1 Info
High

Incomplete Access Control Implementation Details

H-01The `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.
IssueThe `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.
FixProvide 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.
StatusUnresolved
High

Truncated Critical Logic for Voting Power

H-02The 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.
IssueThe 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.
FixProvide 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.
StatusUnresolved
Medium

Inconsistent Total Supply Limit

M-01The `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.
IssueThe `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.
FixClarify 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.
StatusUnresolved
Low

Standard ERC-20 `approve` Race Condition

L-01The `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`.
IssueThe `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`.
FixWhile `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.
StatusUnresolved
Info

Centralized Control over Token Supply and Features

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

Category Ratings

TechnicalMedium6/10

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

GovernanceHigh2/10

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

UpgradesHigh3/10

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.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

58.7% in top 10
26.0% in wallets32.7% in contracts
Effective Concentration39.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

$1.97M across 3 pairs
SushiswapWETHanalysed$1.93M98.1%Uniswap v3WETH$28.4K1.4%Sushiswap v3WETH$9.6K0.5%

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 Holder39.5%
Top-3 Unlocked79.6%

Key Addresses

11 addresses
Deployer
0x0691…f38f
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.

What Raised This Score

7 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

Related Audits

6 more on the record
Paxos Gold (PAXG)High RiskRailHigh RiskTether Gold (XAUT)High RiskSustainable Aviation Fuel (SAF)High RiskMatrix (MTX)High RiskAnimecoin (ANIME)High Risk

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