Quantum Audit Logo
Launch App

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

Is Nola Safe?

NOLAArbitrum
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 High · 2 Medium · 2 Low · 2 Info7
SummaryAI Copilot

The OdysToken contract implements a standard ERC-20-like token with custom transfer restrictions based on wallet and transaction limits.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Top-10 concentration > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k
  • LP top1 unlocked holder = 93.7%
  • LP top3 unlocked holders = 100.0%
  • Token age < 30 days
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 20% (37.6% total → 25.0% effective; 16.6% in EOAs, 21.0% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($44,597 across 1 pairs — thin market)
  • LP top1 unlocked holder = 93.7% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • Token age < 30 days (still settling)
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 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
21.0%Contracts16.6%Wallets62.4%Everyone else
21.0%Contracts16.6%Wallets62.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
37.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking21.0%
  • Walletsanonymous holders, free to sell16.6%
  • Everyone elsethe rest of the supply62.4%
Effective concentrationwhat the score reads25.0%
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$44.6K

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$44.6KShare of depth100.0%
Top-1 Unlocked Holder93.7%
Top-3 Unlocked100.0%
Unlocked LP held by
0x4aca…9f1a0x1bac…d8070x6951…648d0xed21…f0330x3d38…0973

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

Security Findings

1 High2 Medium2 Low2 Info
High

Integer Overflow in maxWallet and maxTx Calculations

The calculations for maxWallet() and maxTx() involve multiplication operations: (totalSupply * maxWalletBps) and (w * 110). If totalSupply or w (the result of maxWallet()) are sufficiently large, these multiplications can exceed type(uint256).max, leading to an integer overflow. This would result in incorrect (smaller than intended) maxWallet or maxTx values, potentially allowing transfers that should be restricted or causing unexpected behavior in the token's economic model (7.2 Code Security).H-01

Issue

The calculations for maxWallet() and maxTx() involve multiplication operations: (totalSupply * maxWalletBps) and (w * 110). If totalSupply or w (the result of maxWallet()) are sufficiently large, these multiplications can exceed type(uint256).max, leading to an integer overflow. This would result in incorrect (smaller than intended) maxWallet or maxTx values, potentially allowing transfers that should be restricted or causing unexpected behavior in the token's economic model (7.2 Code Security).

Fix

Implement safe arithmetic for all multiplication operations, especially those involving large uint256 values. Consider using OpenZeppelin's SafeMath library or explicitly checking for overflow before multiplication, for example, `require(totalSupply <= type(uint256).max / maxWalletBps, 'Overflow');`.

Status

Unresolved

Medium

Centralized Control by factory Address

The factory address, set during contract deployment, holds exclusive control over critical functions such as setPool() and setInitialBuyRecipient() (7.3 Access Control). If the private key associated with this factory address is compromised, an attacker could maliciously set the liquidityPool or initialBuyRecipient to an arbitrary address, potentially disrupting liquidity or diverting funds. This represents a single point of failure for initial contract setup.M-01

Issue

The factory address, set during contract deployment, holds exclusive control over critical functions such as setPool() and setInitialBuyRecipient() (7.3 Access Control). If the private key associated with this factory address is compromised, an attacker could maliciously set the liquidityPool or initialBuyRecipient to an arbitrary address, potentially disrupting liquidity or diverting funds. This represents a single point of failure for initial contract setup.

Fix

To mitigate the risk of a single point of failure, consider using a multi-signature wallet (e.g., Gnosis Safe) for the factory address. For highly critical operations, implementing a time-lock mechanism could provide a window for intervention if a malicious transaction is initiated.

Status

Unresolved

Medium

Immutability of Key Parameters Limits Flexibility

The maxWalletBps and restrictionSeconds parameters are set as immutable in the constructor (7.4 Economic). While this provides predictability and reduces governance complexity, it also means these critical tokenomic parameters cannot be adjusted after deployment. This lack of flexibility could become a significant issue if unforeseen market conditions, community feedback, or protocol evolution necessitate changes to the token's transfer restrictions.M-02

Issue

The maxWalletBps and restrictionSeconds parameters are set as immutable in the constructor (7.4 Economic). While this provides predictability and reduces governance complexity, it also means these critical tokenomic parameters cannot be adjusted after deployment. This lack of flexibility could become a significant issue if unforeseen market conditions, community feedback, or protocol evolution necessitate changes to the token's transfer restrictions.

Fix

Evaluate whether future flexibility for these parameters is desirable. If so, consider making them configurable by a trusted entity (e.g., the factory address or a governance mechanism) with appropriate safeguards like time-locks or multi-signature approvals. If immutability is the intended design, ensure this decision is well-documented and understood by stakeholders.

Status

Unresolved

Low

Missing metaURI Setter or Immutability Declaration

The metaURI state variable is declared as string public and initialized in the constructor. However, there is no setter function provided to update its value after deployment. If the intention was for metaURI to be mutable, this is an oversight. If it was intended to be immutable, it should be declared as immutable to clearly communicate its fixed nature and potentially save gas (7.1 Architecture).L-01

Issue

The metaURI state variable is declared as string public and initialized in the constructor. However, there is no setter function provided to update its value after deployment. If the intention was for metaURI to be mutable, this is an oversight. If it was intended to be immutable, it should be declared as immutable to clearly communicate its fixed nature and potentially save gas (7.1 Architecture).

Fix

Clarify the intended mutability of metaURI. If it should be immutable, declare it as string public immutable metaURI;. If it should be mutable, add a restricted setter function (e.g., callable only by the factory address) to allow updates.

Status

Unresolved

Low

No Mechanism for Recovering Accidentally Sent Tokens

The contract lacks a function to recover accidentally sent ERC-20 tokens (other than its own OdysToken) or native currency (ETH/MATIC/BNB) that might be mistakenly sent to the contract address (7.8 Operations). Any such assets would become permanently locked within the contract, leading to irrecoverable loss.L-02

Issue

The contract lacks a function to recover accidentally sent ERC-20 tokens (other than its own OdysToken) or native currency (ETH/MATIC/BNB) that might be mistakenly sent to the contract address (7.8 Operations). Any such assets would become permanently locked within the contract, leading to irrecoverable loss.

Fix

Implement a restricted recoverERC20(address tokenAddress, uint256 amount) function and a withdrawEther(uint256 amount) function, callable only by the factory address. This would allow the recovery of assets sent to the contract by mistake.

Status

Unresolved

Info

unchecked Block for balanceOf[to] += value

The operation balanceOf[to] += value; is placed within an unchecked block. While balanceOf[from] -= value; is outside, ensuring value does not exceed balanceOf[from], and totalSupply is fixed, it's important to confirm that balanceOf[to] can never exceed type(uint256).max under any valid scenario. Given the current design, where value is bounded by balanceOf[from] and totalSupply is fixed, an overflow of balanceOf[to] is highly unlikely, but explicit documentation of this invariant would be beneficial (7.2 Code Security).I-01

Issue

The operation balanceOf[to] += value; is placed within an unchecked block. While balanceOf[from] -= value; is outside, ensuring value does not exceed balanceOf[from], and totalSupply is fixed, it's important to confirm that balanceOf[to] can never exceed type(uint256).max under any valid scenario. Given the current design, where value is bounded by balanceOf[from] and totalSupply is fixed, an overflow of balanceOf[to] is highly unlikely, but explicit documentation of this invariant would be beneficial (7.2 Code Security).

Fix

Document the reasoning behind using unchecked for this specific operation, explicitly stating the invariants that prevent an overflow (e.g., balanceOf[to] cannot exceed totalSupply, and totalSupply is less than type(uint256).max).

Status

Unresolved

Info

Lack of Emergency Pause Functionality

The contract does not include a mechanism to pause transfers or other critical operations in case of an emergency, such as a discovered vulnerability, a major exploit in an integrated protocol, or severe market manipulation (7.8 Operations). Without a pause function, the protocol would be unable to react quickly to mitigate ongoing damage.I-02

Issue

The contract does not include a mechanism to pause transfers or other critical operations in case of an emergency, such as a discovered vulnerability, a major exploit in an integrated protocol, or severe market manipulation (7.8 Operations). Without a pause function, the protocol would be unable to react quickly to mitigate ongoing damage.

Fix

Consider adding a pause mechanism, controlled by the factory address (preferably a multi-signature wallet), that can temporarily halt transfers. This would provide a crucial safety switch during unforeseen events.

Status

Unresolved

Analysis

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

The OdysToken contract implements a standard ERC-20-like token with custom transfer restrictions based on wallet and transaction limits. The contract exhibits good adherence to ERC-20 standards and includes immutable parameters for core tokenomics, enhancing predictability. However, a high-severity integer overflow vulnerability exists in the calculation of transfer limits under extreme totalSupply values. Centralized control by the factory address for critical setup functions and the lack of upgradeability or emergency pause mechanisms are also noted.

Technical8/10Low risk

The OdysToken contract provides a basic ERC-20 implementation with additional transfer restrictions for wallet and transaction sizes (7.1 Architecture). It correctly implements standard ERC-20 functions and events. A significant technical risk (7.2 Code Security) is the potential for integer overflow in the maxWallet and maxTx calculations if the totalSupply is set to an extremely large value, which could lead to incorrect enforcement of transfer limits. The use of unchecked for balanceOf[to] is noted but deemed safe under current design constraints.

Governance1/10High risk

The factory address holds centralized control for setting the liquidityPool and initialBuyRecipient addresses (7.3 Access Control), posing a single point of failure if compromised. Key tokenomic parameters such as maxWalletBps and restrictionSeconds are immutable (7.4 Economic), which provides predictability but limits the protocol's adaptability to unforeseen market conditions or community feedback. There is no on-chain governance mechanism (7.5 Governance) for parameter adjustments or protocol upgrades.

Upgrades6/10Medium risk

The OdysToken contract is not designed to be upgradeable (7.7 Upgrades), meaning its logic cannot be modified after deployment. This eliminates risks associated with proxy patterns, upgradeability bugs, or malicious upgrades. However, it also means that any discovered bugs cannot be patched, and new features cannot be added without a full redeployment and migration.

Final RecommendationWhat to do about this score

It is strongly recommended to address the high-severity integer overflow vulnerability in the maxWallet and maxTx calculations to ensure the integrity of transfer restrictions.

For enhanced security and operational robustness, consider implementing a multi-signature wallet for the factory address and adding functions for emergency pausing and recovery of accidentally sent tokens. Review the immutability of key tokenomic parameters to confirm alignment with long-term project goals regarding flexibility versus predictability.

Contract & Record

1 audit on record
TypeOdysToken
NetworkArbitrum
Token age20d
Contract0x768d…0c4e
Deployer0x439a…48bc
Badge for your website
Nola 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, 202660Medium
  2. Sep 1, 202646Medium

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

Frequently Asked Questions

What is the NOLA contract address?

The Nola contract on Arbitrum is 0x768d4b20869771a93946b5101a6a2e886f020c4e. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Nola a scam?

Quantum Audit's risk score for Nola is 60/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 NOLA liquidity locked?

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

Who holds NOLA?

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

Related Audits

6 more on the recordAll audits
Gains NetworkGNS · Arbitrum60MediumWINRArbitrum60MediumNOXCATNOX · Arbitrum58MediumMAGICArbitrum58Mediumether.fi governance tokenETHFI · Arbitrum58MediumUniswapUNI · Arbitrum62Medium

Would You Like a More Detailed Audit of Nola?

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