Is Nola Safe? Smart Contract Security Analysis

Security Findings

1 High2 Med2 Low2 Info

High

Integer Overflow in `maxWallet` and `maxTx` Calculations

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

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

FixImplement 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');`.

StatusUnresolved

Medium

Centralized Control by `factory` Address

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

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

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

StatusUnresolved

Medium

Immutability of Key Parameters Limits Flexibility

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

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

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

StatusUnresolved

Low

Missing `metaURI` Setter or Immutability Declaration

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

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

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

StatusUnresolved

Low

No Mechanism for Recovering Accidentally Sent Tokens

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

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

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

StatusUnresolved

Info

`unchecked` Block for `balanceOf[to] += value`

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

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

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

StatusUnresolved

Info

Lack of Emergency Pause Functionality

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

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

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceHigh1/10

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.

UpgradesMedium6/10

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.

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

37.6% in top 10

16.6% in wallets21.0% in contracts

Effective Concentration25.0%

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

$44.6K

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 Holder93.7%

Top-3 Unlocked100.0%

Key Addresses

6 addresses

Deployer

0x439a…48bc

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.

What Raised This Score

10 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

Is Nola Safe?

Security Findings

Integer Overflow in `maxWallet` and `maxTx` Calculations

Centralized Control by `factory` Address

Immutability of Key Parameters Limits Flexibility

Missing `metaURI` Setter or Immutability Declaration

No Mechanism for Recovering Accidentally Sent Tokens

`unchecked` Block for `balanceOf[to] += value`

Lack of Emergency Pause Functionality

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Nola?