Quantum Audit Logo

Is Novalon Safe?

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

Novalon NVLN
0xe43d…46ed
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The audit focused on the provided OpenZeppelin ERC20 and ERC20Permit contract implementations, which form the foundation for the Novalon token. These contracts are well-established and widely used, exhibiting high code quality and adherence to best practices. No critical or high-severity vulnerabilities were identified within the scope of the provided code. The primary considerations are informational, related to the standard design patterns and the need for proper implementation of minting/burning mechanisms in the inheriting contract.

1 Low3 Informational
Volume 24h
$248.2K
Liquidity
$17.7K
Price
$0.001394
Token Age
1mo
Top 10 Holders
95.9%

Security Findings

1 Low3 Info
Low

Missing Access Control for Minting/Burning in Inheriting Contract

L-01The `_mint` and `_burn` functions are declared as `internal` in the `ERC20` contract. While this is appropriate for an abstract base contract, it means that any contract inheriting from `ERC20` (or `ERC20Permit`) must implement its own access control mechanisms for functions that call `_mint` or `_burn`. Without proper restrictions (e.g., `onlyOwner`), an inheriting contract could inadvertently allow unauthorized minting or burning, leading to uncontrolled supply changes.
IssueThe `_mint` and `_burn` functions are declared as `internal` in the `ERC20` contract. While this is appropriate for an abstract base contract, it means that any contract inheriting from `ERC20` (or `ERC20Permit`) must implement its own access control mechanisms for functions that call `_mint` or `_burn`. Without proper restrictions (e.g., `onlyOwner`), an inheriting contract could inadvertently allow unauthorized minting or burning, leading to uncontrolled supply changes.
FixEnsure that any public or external functions in the inheriting Novalon token contract that call `_mint` or `_burn` are protected by appropriate access control mechanisms, such as `onlyOwner`, `onlyMinter`, or a robust governance system, to prevent unauthorized supply manipulation.
StatusUnresolved
Info

Use of Unchecked Arithmetic Blocks

I-01The `_update` and `_spendAllowance` functions utilize `unchecked` blocks for arithmetic operations such as `_balances[from] = fromBalance - value;` and `_balances[to] += value;`. This is a standard optimization in modern Solidity to save gas by bypassing default overflow/underflow checks. In these specific cases, the `unchecked` blocks are preceded by explicit checks (e.g., `if (fromBalance < value)`) or operate on values that are guaranteed not to overflow/underflow based on the contract's logic (e.g., `_totalSupply` decrease during burn).
IssueThe `_update` and `_spendAllowance` functions utilize `unchecked` blocks for arithmetic operations such as `_balances[from] = fromBalance - value;` and `_balances[to] += value;`. This is a standard optimization in modern Solidity to save gas by bypassing default overflow/underflow checks. In these specific cases, the `unchecked` blocks are preceded by explicit checks (e.g., `if (fromBalance < value)`) or operate on values that are guaranteed not to overflow/underflow based on the contract's logic (e.g., `_totalSupply` decrease during burn).
FixNo direct action is required as this is a standard and safe practice in the context of OpenZeppelin contracts. However, it's important for developers to understand the implications of `unchecked` blocks and ensure that all necessary bounds checks are performed prior to entering such blocks in custom logic.
StatusUnresolved
Info

Abstract Contract Requires Further Implementation

I-02The provided `ERC20` and `ERC20Permit` contracts are abstract. They define the core logic and interfaces for an ERC20 token with permit functionality but do not include specific deployment-ready implementations for functions like initial supply minting or specific administrative roles. A concrete contract, such as 'Novalon', would need to inherit from `ERC20Permit` and implement these details.
IssueThe provided `ERC20` and `ERC20Permit` contracts are abstract. They define the core logic and interfaces for an ERC20 token with permit functionality but do not include specific deployment-ready implementations for functions like initial supply minting or specific administrative roles. A concrete contract, such as 'Novalon', would need to inherit from `ERC20Permit` and implement these details.
FixEnsure that the final concrete Novalon token contract correctly inherits from `ERC20Permit` and provides all necessary implementations, including a constructor that calls `super(name)` and any desired minting/burning functions with appropriate access control.
StatusUnresolved
Info

Fixed Decimals Value

I-03The `decimals()` function in the `ERC20` contract is hardcoded to return `18`. This is the standard number of decimal places for most ERC20 tokens on Ethereum-compatible networks. While common, it means the token's divisibility cannot be changed without deploying a new contract.
IssueThe `decimals()` function in the `ERC20` contract is hardcoded to return `18`. This is the standard number of decimal places for most ERC20 tokens on Ethereum-compatible networks. While common, it means the token's divisibility cannot be changed without deploying a new contract.
FixNo action is required if 18 decimals is the intended and desired divisibility for the Novalon token. If a different number of decimals is ever considered, this function would need to be overridden in the inheriting contract or the base contract modified (which is not recommended for OpenZeppelin libraries).
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture (7.1) is based on battle-tested OpenZeppelin ERC20 and ERC20Permit standards, ensuring a robust foundation. Code security (7.2) is high, utilizing modern Solidity features like custom errors and `unchecked` blocks appropriately for gas efficiency without compromising safety, as bounds checks are performed beforehand. Access control (7.3) for core token functions is standard, relying on `_msgSender()`. The `permit` function introduces off-chain signature verification, which is a standard and secure pattern when implemented correctly. No reentrancy or integer overflow/underflow issues were found due to careful implementation and OpenZeppelin's robust design.

GovernanceHigh1/10

The provided contracts are abstract base implementations for an ERC20 token and do not include specific governance (7.5) or complex economic (7.4) mechanisms. The `_mint` and `_burn` functions are internal, requiring an inheriting contract to define specific access control for these operations, which is a common design pattern. The token's economic model is a standard fixed-supply or inflationary model depending on how `_mint` is exposed. External dependencies (7.6) are limited to OpenZeppelin's well-audited cryptography utilities.

UpgradesMedium6/10

The provided contracts are not designed with upgradeability (7.7) in mind, as indicated by `is_proxy: false` and the absence of proxy-related patterns (e.g., UUPS, Transparent). This means the deployed token contract will be immutable. This reduces the risk of upgrade-related vulnerabilities but also removes the flexibility to fix issues or add features post-deployment. Operational risks (7.8) are minimal, as the token functions are standard and well-understood.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

95.9% in top 10
84.6% in wallets11.2% in contracts
Effective Concentration89.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

$17.7K

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 Holder81.7%
Top-3 Unlocked95.4%

Key Addresses

11 addresses
Deployer
0x0c31…070f
Unlocked LP Held By
0xdd85…7c9d0x575e…fe980x119a…d4fc0xb749…6b0a0xec5b…83560x8e4c…7bb20x8281…a4030xa5db…d6700x29de…730c0x6313…1a60

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

What Raised This Score

8 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 70% (95.9% total → 89.1% effective; 84.6% in EOAs, 11.2% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($17,706 across 1 pairs — thin market)
  • Volume/Liquidity > 10× (14.0× — possible wash trading)
  • LP top1 unlocked holder = 81.7% (independent LP — depth risk)
  • LP top3 unlocked holders = 95.4% (independent LP — depth risk)
  • 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
LayerZero (ZRO)High RiskAvail (Wormhole) (AVAIL)High RiskJito Staked SOL (JITOSOL)High RiskMorpho Token (MORPHO)High RiskTether USD (USDT)High RiskevoHigh Risk

Would You Like a More Detailed Audit of Novalon?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit