Is Nillion (NIL) Safe? Smart Contract Security Analysis

Security Findings

3 High1 Med2 Info

High

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

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

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

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

StatusUnresolved

High

Unlimited Minting Capability

H-02The `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).

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

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

StatusUnresolved

High

Arbitrary Token Burning Capability

H-03The `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).

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

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

StatusUnresolved

Medium

Upgradeability Risk with Centralized Control

M-01The 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).

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

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

StatusUnresolved

Info

Constructor `_disableInitializers()` in Implementation

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

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

FixNo action required; this is a positive security measure.

StatusResolved

Info

Decimals Override

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

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

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

StatusResolved

Category Ratings

TechnicalMedium4/10

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

GovernanceHigh1/10

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.

UpgradesHigh1/10

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.

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Uups

ImplementationVerified source

Upgrades (30d)0 · stable

Liquidity Depth

$515.6K across 2 pairs

Uniswap v4USDCanalysed$314.7K Uniswap v4ETH$200.8K

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.

Key Addresses

1 addresses

Deployer

0x7b95…fa78

What Raised This Score

6 factors

Ownership status UNKNOWN (owner could not be resolved)
Mintable supply — no cap found, dilution unbounded
Proxy contract (upgradeable — admin can replace logic)
Liquidity NOT locked (owner can withdraw — rug-pull risk)
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

Is Nillion Safe?

Security Findings

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

Unlimited Minting Capability

Arbitrary Token Burning Capability

Upgradeability Risk with Centralized Control

Constructor `_disableInitializers()` in Implementation

Decimals Override

Category Ratings

Security Checklist

Proxy Upgrade Controls

Liquidity Depth

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Nillion?