Is Orochi Network Token (ON) Safe? Smart Contract Security Analysis

Security Findings

1 Med1 Low1 Info

Medium

Single-Shot Minting Design Limitation

M-01The `mint()` function includes a check `if (totalSupply() > 0) { revert AlreadyMinted(totalSupply()); }`, which prevents subsequent minting calls if any tokens have already been minted (i.e., `totalSupply` is non-zero). If the owner initially mints 0 tokens, they can still mint a non-zero amount later. However, if they mint any non-zero amount, they cannot mint additional tokens in the future. This design choice creates an immutable total supply after the first non-zero mint, which might be a desired feature but limits flexibility for future token supply management.

IssueThe `mint()` function includes a check `if (totalSupply() > 0) { revert AlreadyMinted(totalSupply()); }`, which prevents subsequent minting calls if any tokens have already been minted (i.e., `totalSupply` is non-zero). If the owner initially mints 0 tokens, they can still mint a non-zero amount later. However, if they mint any non-zero amount, they cannot mint additional tokens in the future. This design choice creates an immutable total supply after the first non-zero mint, which might be a desired feature but limits flexibility for future token supply management.

FixConfirm that a fixed, non-expandable token supply after the initial mint is the intended tokenomic model. If future flexibility for supply adjustments (e.g., for ecosystem growth, liquidity incentives) is ever desired, this design would require a new contract deployment. Ensure the initial mint quantity is carefully planned to meet all long-term requirements.

StatusUnresolved

Low

Centralized Ownership Risk

L-01The contract utilizes the `Ownable` pattern, granting a single external address (the `owner`) exclusive control over critical administrative functions, specifically the `mint()` function and the ability to `transferOwnership()`. This introduces a single point of failure (7.3 Access Control). If the owner's private key is compromised, a malicious actor could potentially perform an unauthorized initial mint or transfer ownership to themselves, leading to a loss of control or unexpected token distribution.

IssueThe contract utilizes the `Ownable` pattern, granting a single external address (the `owner`) exclusive control over critical administrative functions, specifically the `mint()` function and the ability to `transferOwnership()`. This introduces a single point of failure (7.3 Access Control). If the owner's private key is compromised, a malicious actor could potentially perform an unauthorized initial mint or transfer ownership to themselves, leading to a loss of control or unexpected token distribution.

FixTo mitigate the risk associated with a single point of failure, consider transferring ownership to a multi-signature wallet (e.g., Gnosis Safe) after deployment. This distributes control among multiple trusted parties, requiring multiple approvals for critical operations. Alternatively, if the token supply is fixed and no further administrative actions are anticipated, the owner could renounce ownership to fully decentralize control.

StatusUnresolved

Info

Immutability of Token Decimals

I-01The `decimals()` function is hardcoded to return `18`. While 18 is the most common and widely accepted standard for ERC-20 token decimals, this value is immutable once the contract is deployed. Any future requirement to change the token's decimal precision would necessitate deploying an entirely new token contract.

IssueThe `decimals()` function is hardcoded to return `18`. While 18 is the most common and widely accepted standard for ERC-20 token decimals, this value is immutable once the contract is deployed. Any future requirement to change the token's decimal precision would necessitate deploying an entirely new token contract.

FixConfirm that 18 decimals is the permanent and desired configuration for the token. This is generally a safe and standard practice, but it's important to acknowledge its immutability in the context of long-term project planning.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract leverages battle-tested OpenZeppelin ERC20 and Ownable implementations, ensuring robust core token functionalities and secure access control (7.2 Code Security). Standard ERC20 operations like `transfer` and `approve` are correctly implemented with appropriate checks and custom error handling. No reentrancy or integer overflow vulnerabilities were identified due to the careful use of `unchecked` blocks after validation checks. The architecture (7.1 Architecture) is straightforward and adheres to common ERC-20 standards.

GovernanceMedium6/10

The token's economic model features a single-shot minting mechanism controlled by the owner (7.4 Economic). Once a non-zero supply is minted, no further tokens can be created, which defines a fixed supply. However, this introduces a dependency on a single owner for the initial mint (7.5 Governance), posing a centralization risk if the owner's key is compromised. Transferring ownership to a multi-sig or renouncing it post-deployment can mitigate this. External dependencies (7.6 External) are limited to standard ERC interfaces.

UpgradesMedium6/10

The contract is not designed to be upgradeable (7.7 Upgrades), meaning its logic is immutable once deployed. This eliminates risks associated with proxy patterns, such as storage collisions or incorrect upgrade paths. Any future changes to the token's functionality would require a new contract deployment and migration, which is a common approach for simple token contracts.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Holder Composition

55.6% in top 10

36.6% in wallets19.1% in contracts

Effective Concentration44.2%

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

$1.17M across 3 pairs

Pancakeswap v3USDTanalysed$1.17M UniswapUSDT$2.4K Pancakeswap v3USDT$21

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 Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

4 addresses

Deployer

0xfac0…0d5d

Unlocked LP Held By

0x166a…0b050xf663…a2b00x9faa…6cd4

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

What Raised This Score

7 factors

Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 30% (55.6% total → 44.2% effective; 36.6% in EOAs, 19.1% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
1 Medium finding(s) from audit
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

Is Orochi Network Token Safe?

Security Findings

Single-Shot Minting Design Limitation

Centralized Ownership Risk

Immutability of Token Decimals

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 Orochi Network Token?