Quantum Audit Logo
Launch App

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

Is Nillion Safe?

NILEthereum
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
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades1/10Checks passed1 of 5Findings3 High · 1 Medium · 2 Info6
SummaryAI Copilot

The audit covers an ERC-20 token contract, Nillion, implemented as an upgradeable UUPS proxy.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • LP lock status UNKNOWN — the pool's LP could not be read
  • 3 High finding(s) from audit
  • 1 Medium finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • LP lock status UNKNOWN — the pool's LP could not be read
  • 3 High finding(s) from audit
  • 1 Medium 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 41 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockUnknown
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026

How the supply is spread across holders could not be read — the indexer's holder list does not add up to the supply. Check the largest holders on a block explorer, which reads current balances.

Liquidity

as of audit · Sep 4$515.6K across 2 pairs

The risk score reads depth across every pair.

LP tokensUnknown

Whether the LP tokens are locked could not be determined.

Analysed pool$314.7KShare of depth61.0%

Security Findings

3 High1 Medium2 Info
High

Centralized Control of Critical Roles (Minter, Burner, Upgrader, Admin)

The DEFAULT_ADMIN_ROLE, MINTER_ROLE, BURNER_ROLE, and UPGRADER_ROLE are all initially granted to the msg.sender (initializer). The DEFAULT_ADMIN_ROLE has the power to grant and revoke all other roles, including itself. This high degree of centralization means that a compromise of this single address would grant an attacker full control over token minting, burning (from any address), and contract upgradeability, posing a critical risk to the protocol's integrity and user funds (7.3 Access Control, 7.5 Governance, 7.8 Operations).H-01

Issue

The DEFAULT_ADMIN_ROLE, MINTER_ROLE, BURNER_ROLE, and UPGRADER_ROLE are all initially granted to the msg.sender (initializer). The DEFAULT_ADMIN_ROLE has the power to grant and revoke all other roles, including itself. This high degree of centralization means that a compromise of this single address would grant an attacker full control over token minting, burning (from any address), and contract upgradeability, posing a critical risk to the protocol's integrity and user funds (7.3 Access Control, 7.5 Governance, 7.8 Operations).

Fix

Implement a robust multi-signature wallet (e.g., Gnosis Safe) for the DEFAULT_ADMIN_ROLE to distribute control and require multiple approvals for critical operations. Consider delegating specific roles (e.g., MINTER_ROLE, BURNER_ROLE) to separate, potentially more restricted, entities or smart contracts if their functionality is required long-term.

Status

Unresolved

High

Unlimited Minting Capability

The MINTER_ROLE allows an authorized address to mint an arbitrary amount of new tokens at any time. This capability can lead to uncontrolled supply inflation, significantly devaluing existing tokens and impacting the project's economy (7.4 Economic, 7.3 Access Control).H-02

Issue

The MINTER_ROLE allows an authorized address to mint an arbitrary amount of new tokens at any time. This capability can lead to uncontrolled supply inflation, significantly devaluing existing tokens and impacting the project's economy (7.4 Economic, 7.3 Access Control).

Fix

Evaluate if continuous minting is truly necessary. If not, consider revoking the MINTER_ROLE after the initial token distribution. If minting is required, implement a controlled minting mechanism (e.g., capped minting, time-locked minting, or a governance-controlled minting process) to prevent arbitrary supply increases.

Status

Unresolved

High

Arbitrary Token Burning Capability

The BURNER_ROLE allows an authorized address to burn tokens from *any* specified address (from). This means a malicious or compromised BURNER_ROLE holder could drain tokens from user accounts, leading to direct loss of user funds (7.4 Economic, 7.3 Access Control).H-03

Issue

The BURNER_ROLE allows an authorized address to burn tokens from *any* specified address (from). This means a malicious or compromised BURNER_ROLE holder could drain tokens from user accounts, leading to direct loss of user funds (7.4 Economic, 7.3 Access Control).

Fix

Re-evaluate the necessity of the BURNER_ROLE having the ability to burn from arbitrary addresses. If burning is only intended for specific scenarios (e.g., protocol-owned tokens, specific user opt-in), restrict the burn function to only allow burning from msg.sender or implement a more granular access control mechanism. If the functionality is critical, ensure the BURNER_ROLE is controlled by a highly secure, multi-signature wallet.

Status

Unresolved

Medium

Upgradeability Risk with Centralized Control

The contract uses the UUPS upgradeability pattern, allowing the contract logic to be changed. The UPGRADER_ROLE is initially granted to the msg.sender (initializer). While UUPS is a standard pattern, a compromised UPGRADER_ROLE holder could upgrade the contract to malicious code, potentially leading to loss of funds, freezing of assets, or other severe consequences (7.7 Upgrades, 7.3 Access Control).M-01

Issue

The contract uses the UUPS upgradeability pattern, allowing the contract logic to be changed. The UPGRADER_ROLE is initially granted to the msg.sender (initializer). While UUPS is a standard pattern, a compromised UPGRADER_ROLE holder could upgrade the contract to malicious code, potentially leading to loss of funds, freezing of assets, or other severe consequences (7.7 Upgrades, 7.3 Access Control).

Fix

Ensure the UPGRADER_ROLE is controlled by a robust multi-signature wallet with a high threshold. Consider implementing a timelock for upgrades to provide users with a window to react to proposed changes. Thoroughly audit all proposed upgrade implementations before deployment.

Status

Unresolved

Info

Constructor _disableInitializers() in Implementation

The Nillion contract's constructor calls _disableInitializers(). This is a good security practice for upgradeable contracts, preventing the implementation contract from being initialized directly, which could lead to state corruption if it were accidentally called (7.2 Code Security).I-01

Issue

The Nillion contract's constructor calls _disableInitializers(). This is a good security practice for upgradeable contracts, preventing the implementation contract from being initialized directly, which could lead to state corruption if it were accidentally called (7.2 Code Security).

Fix

No action required; this is a positive security measure.

Status

Resolved

Info

Decimals Override

The decimals() function is explicitly overridden to return 6 instead of the default 18 for ERC-20 tokens. This is a design choice that impacts how the token amount is displayed and handled by interfaces and integrations (7.1 Architecture).I-02

Issue

The decimals() function is explicitly overridden to return 6 instead of the default 18 for ERC-20 tokens. This is a design choice that impacts how the token amount is displayed and handled by interfaces and integrations (7.1 Architecture).

Fix

Ensure all front-ends, exchanges, and integrations are aware of and correctly handle the 6-decimal precision to prevent display errors or miscalculations.

Status

Resolved

Analysis

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

The audit covers an ERC-20 token contract, Nillion, implemented as an upgradeable UUPS proxy. The contract utilizes OpenZeppelin's battle-tested libraries for ERC-20, burnable functionality, access control, and upgradeability. Key roles such as DEFAULT_ADMIN_ROLE, MINTER_ROLE, BURNER_ROLE, and UPGRADER_ROLE are initially assigned to the deployer address, creating a highly centralized control structure. While the code itself is well-structured, this centralization introduces significant economic and operational risks, particularly concerning unlimited minting, arbitrary burning, and unchecked upgrade capabilities.

Technical4/10Medium risk

The technical architecture is sound, leveraging OpenZeppelin's upgradeable contracts for ERC-20, burnable tokens, and UUPS proxy patterns (7.1 Architecture). The custom logic for burn and decimals is minimal and correctly implemented, and _disableInitializers() is appropriately used in the implementation contract's constructor (7.2 Code Security). However, the UPGRADER_ROLE holds significant power, allowing for arbitrary contract logic changes, which, if compromised, could lead to severe technical vulnerabilities (7.7 Upgrades).

Governance1/10High risk

The contract's economic model features an initial supply of 1 billion tokens with 6 decimals. A primary concern is the highly centralized control over critical economic functions (7.4 Economic). The MINTER_ROLE allows for unlimited token inflation, and the BURNER_ROLE permits burning tokens from any address, posing a direct threat to user funds if misused. All these powerful roles, including the DEFAULT_ADMIN_ROLE, are initially assigned to a single address (7.5 Governance), creating a single point of failure and significant governance risk.

Upgrades1/10High risk

The contract employs the UUPS upgradeability pattern, a standard and robust mechanism for contract evolution (7.7 Upgrades). The _authorizeUpgrade function is correctly restricted by the UPGRADER_ROLE. A positive security measure is the use of _disableInitializers() in the implementation contract's constructor to prevent direct initialization. However, the UPGRADER_ROLE is initially held by a single address, which introduces a high risk: a compromise of this address could lead to unauthorized and potentially malicious upgrades, impacting the entire protocol.

Final RecommendationWhat to do about this score

Prioritize decentralizing control over critical administrative and operational roles.

Implement a robust multi-signature wallet for the DEFAULT_ADMIN_ROLE, MINTER_ROLE, BURNER_ROLE, and UPGRADER_ROLE to mitigate single points of failure and enhance security. Carefully evaluate the necessity of continuous unlimited minting and arbitrary burning capabilities; if not essential, consider revoking or restricting these roles. For upgrades, consider adding a timelock mechanism to provide a delay for community review before changes are enacted.

Contract & Record

1 audit on record
TypeERC1967Proxy
NetworkEthereum
Token age8mo
Contract0x7cf9…2d47
Deployer0x7b95…fa78
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Nillion 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, 202675High
  2. Jul 28, 202679High

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

Frequently Asked Questions

What is the NIL contract address?

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

Is Nillion a scam?

Quantum Audit's risk score for Nillion is 75/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Related Audits

6 more on the recordAll audits
trUSDEthereum75HighAIOZ NetworkAIOZ · Ethereum75HighAethir TokenATH · Ethereum75HighSendoverEthereum75HighMain Street USDMSUSD · Ethereum74HighSynapseSYN · Ethereum76High

Would You Like a More Detailed Audit of Nillion?

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