Quantum Audit Logo
Launch App

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

Is Novalon Safe?

NVLNBase
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
Technical8/10Governance1/10Upgrades6/10Checks passed5 of 7Findings1 Low · 3 Info4
SummaryAI Copilot

The audit focused on the provided OpenZeppelin ERC20 and ERC20Permit contract implementations, which form the foundation for the Novalon token.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k
  • Volume/Liquidity > 10×
  • LP top1 unlocked holder = 81.7%
  • LP top3 unlocked holders = 95.4%
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 45 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
11.2%Contracts84.6%Wallets4.1%
11.2%84.6%Wallets
ContractsWalletsEveryone elseBubble area = share of supply
95.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking11.2%
  • Walletsanonymous holders, free to sell84.6%
  • Everyone elsethe rest of the supply4.1%
Effective concentrationwhat the score reads89.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$17.7K

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$17.7KShare of depth100.0%
Top-1 Unlocked Holder81.7%
Top-3 Unlocked95.4%
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.

Security Findings

1 Low3 Info
Low

Missing Access Control for Minting/Burning in Inheriting Contract

The _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.L-01

Issue

The _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.

Fix

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

Status

Unresolved

Info

Use of Unchecked Arithmetic Blocks

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

Issue

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

Fix

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

Status

Unresolved

Info

Abstract Contract Requires Further Implementation

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

Issue

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

Fix

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

Status

Unresolved

Info

Fixed Decimals Value

The 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.I-03

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical8/10Low risk

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.

Governance1/10High risk

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.

Upgrades6/10Medium risk

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.

Final RecommendationWhat to do about this score

It is recommended to ensure that any contract inheriting from ERC20Permit implements robust access control for sensitive functions like _mint and _burn, typically restricting them to a trusted owner or governance mechanism.

Thoroughly review the off-chain component responsible for generating permit signatures to prevent any potential misuse or compromise. Consider the implications of immutability for the token's long-term lifecycle and future feature requirements.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age1mo
Contract0xe43d…46ed
Deployer0x0c31…070f
Badge for your website
Novalon 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, 202661Medium
  2. Sep 3, 202657Medium

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

Frequently Asked Questions

What is the NVLN contract address?

The Novalon (NVLN) contract on Base is 0xe43df70a3a8067680aae799fa5171c3f473b46ed. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Novalon a scam?

Quantum Audit's risk score for Novalon is 61/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is NVLN liquidity locked?

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

Who holds NVLN?

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

Related Audits

6 more on the recordAll audits
LayerZeroZRO · Base61MediumAvail (Wormhole)AVAIL · Base61MediumJito Staked SOLJITOSOL · Base62MediumMorpho TokenMORPHO · Base60MediumTether USDUSDT · Base60MediumevoBase60Medium

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 Is this your token? Publish your own audit on this page