Quantum Audit Logo
Launch App

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

Is ODYS Safe?

Arbitrum
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
Technical7/10Governance1/10Upgrades5/10Checks passed5 of 7Findings1 Critical · 1 High · 1 Medium · 1 Low · 2 Info6
SummaryAI Copilot

The OdysToken contract implements a standard ERC-20-like token with additional transfer restrictions based on wallet and transaction size, active during an initial period.

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
  • LP top1 unlocked holder = 95.0%
  • LP top3 unlocked holders = 98.7%
  • Token age < 30 days
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 20% (24.5% total → 21.9% effective; 20.2% in EOAs, 4.4% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 95.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 98.7% (independent LP — depth risk)
  • Token age < 30 days (still settling)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 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

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
4.4%20.2%Wallets75.5%Everyone else
4.4%20.2%Wallets75.5%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
24.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking4.4%
  • Walletsanonymous holders, free to sell20.2%
  • Everyone elsethe rest of the supply75.5%
Effective concentrationwhat the score reads21.9%
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$198.1K

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$198.1KShare of depth100.0%
Top-1 Unlocked Holder95.0%
Top-3 Unlocked98.7%
Unlocked LP held by
0x4aca…9f1a0xf1db…b3e00x07af…8f0d0x1bac…d8070x80dd…1a4b0xcf26…ee1c0x6951…648d0x5b71…90ad0xb5cf…1e590x5dba…a82a

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

Security Findings

1 Critical1 High1 Medium1 Low2 Info
Critical

Unchecked Arithmetic in Balance Update

The _move function uses an unchecked block for balanceOf[to] += value;. If balanceOf[to] + value exceeds type(uint256).max, the sum will wrap around, leading to an incorrect (smaller) balance for the recipient. This effectively burns tokens from the recipient and represents a severe loss of funds vulnerability.C-01

Issue

The _move function uses an unchecked block for balanceOf[to] += value;. If balanceOf[to] + value exceeds type(uint256).max, the sum will wrap around, leading to an incorrect (smaller) balance for the recipient. This effectively burns tokens from the recipient and represents a severe loss of funds vulnerability.

Fix

Remove the unchecked block around balanceOf[to] += value;. Solidity 0.8+ by default checks for overflows/underflows, so explicit unchecked should only be used for intentional wrapping with clear justification and mitigation strategies.

Status

Unresolved

High

Potential Overflow in Restriction Calculations

The maxWallet() and maxTx() functions calculate limits using (totalSupply * maxWalletBps) / BPS and (w * 110) / 100. If totalSupply is extremely large, the intermediate multiplication totalSupply * maxWalletBps or w * 110 could overflow uint256 before the division. This would result in a wrapped-around, smaller-than-intended limit, potentially allowing users to bypass intended restrictions or causing incorrect economic behavior.H-01

Issue

The maxWallet() and maxTx() functions calculate limits using (totalSupply * maxWalletBps) / BPS and (w * 110) / 100. If totalSupply is extremely large, the intermediate multiplication totalSupply * maxWalletBps or w * 110 could overflow uint256 before the division. This would result in a wrapped-around, smaller-than-intended limit, potentially allowing users to bypass intended restrictions or causing incorrect economic behavior.

Fix

Implement safe math for these calculations. Ensure intermediate products do not exceed type(uint256).max by carefully reordering operations (e.g., (totalSupply / BPS) * maxWalletBps if totalSupply is divisible by BPS) or by explicitly checking for overflow before multiplication.

Status

Unresolved

Medium

Ambiguous maxTx and maxWallet Restriction Logic

The maxTx() function calculates a limit that is 110% of maxWallet(). While the _move function correctly checks value > maxTx() and then balanceOf[to] + value > maxWallet(), the maxTx limit being greater than maxWallet can be confusing. This design choice might lead to unexpected user experience or misinterpretation of the actual limits, as a transaction could pass the maxTx check but still fail the maxWallet check if the recipient's current balance is non-zero.M-01

Issue

The maxTx() function calculates a limit that is 110% of maxWallet(). While the _move function correctly checks value > maxTx() and then balanceOf[to] + value > maxWallet(), the maxTx limit being greater than maxWallet can be confusing. This design choice might lead to unexpected user experience or misinterpretation of the actual limits, as a transaction could pass the maxTx check but still fail the maxWallet check if the recipient's current balance is non-zero.

Fix

Clarify the intended behavior of maxTx relative to maxWallet. Consider if maxTx should always be less than or equal to maxWallet to prevent scenarios where a single transaction could theoretically exceed the wallet limit if the recipient's balance was zero. Alternatively, document this behavior clearly for users and developers.

Status

Unresolved

Low

Standard ERC-20 approve Front-Running Vulnerability

The approve function follows the standard ERC-20 implementation, which is susceptible to a known front-running vulnerability. If a user approves an amount X for a spender, and then decides to change it to Y (where Y < X), a malicious front-runner could observe the transaction changing the allowance to Y, quickly execute a transferFrom for amount X (or part of it), and then the user's transaction to set allowance to Y would still go through. The spender would then have Y allowance in addition to the X they just spent.L-01

Issue

The approve function follows the standard ERC-20 implementation, which is susceptible to a known front-running vulnerability. If a user approves an amount X for a spender, and then decides to change it to Y (where Y < X), a malicious front-runner could observe the transaction changing the allowance to Y, quickly execute a transferFrom for amount X (or part of it), and then the user's transaction to set allowance to Y would still go through. The spender would then have Y allowance in addition to the X they just spent.

Fix

While this is a common ERC-20 pattern, it's best practice to mitigate it. Recommend implementing the 'approve-and-call' pattern or requiring users to set allowance to zero before approving a new non-zero amount.

Status

Unresolved

Info

Immutability of Key Parameters

Several critical parameters such as factory, pairToken, positionManager, swapRouter, launchTime, maxWalletBps, and restrictionSeconds are declared as immutable. This means they cannot be changed after contract deployment. While this provides certainty, it also means that if any of these parameters are set incorrectly or require updates due to unforeseen circumstances (e.g., a change in the swapRouter address), the contract would need to be redeployed.I-01

Issue

Several critical parameters such as factory, pairToken, positionManager, swapRouter, launchTime, maxWalletBps, and restrictionSeconds are declared as immutable. This means they cannot be changed after contract deployment. While this provides certainty, it also means that if any of these parameters are set incorrectly or require updates due to unforeseen circumstances (e.g., a change in the swapRouter address), the contract would need to be redeployed.

Fix

Ensure that all immutable parameters are thoroughly reviewed and correctly configured prior to deployment. Consider if any of these parameters might require future flexibility and, if so, make them mutable with appropriate access control and upgrade mechanisms.

Status

Unresolved

Info

Centralized Control by factory Address

The factory address, set during construction, holds significant control over the contract. It is the only address authorized to call setPool and setInitialBuyRecipient. Additionally, the factory address is exempt from all transfer restrictions (_exempt function). This centralization of control means that the security of the factory address is paramount, as a compromise could lead to manipulation of the liquidity pool or initial buy recipient, and unrestricted token transfers.I-02

Issue

The factory address, set during construction, holds significant control over the contract. It is the only address authorized to call setPool and setInitialBuyRecipient. Additionally, the factory address is exempt from all transfer restrictions (_exempt function). This centralization of control means that the security of the factory address is paramount, as a compromise could lead to manipulation of the liquidity pool or initial buy recipient, and unrestricted token transfers.

Fix

Implement robust security measures for the factory address, such as multi-signature wallet control, to mitigate the risk of a single point of failure. Clearly document the responsibilities and capabilities of the factory address for transparency.

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 additional transfer restrictions based on wallet and transaction size, active during an initial period. The audit identified a critical vulnerability related to unchecked arithmetic in balance updates, which could lead to token loss. High-severity issues include potential overflows in restriction calculations. Medium and low-severity issues pertain to restriction logic clarity and standard ERC-20 front-running. Informational findings highlight centralized control and immutability of key parameters.

Technical7/10Low risk

The contract's architecture is a straightforward ERC-20-like token with custom transfer restrictions (7.1 Architecture). However, a critical code security flaw exists in the _move function where balanceOf[to] += value; is wrapped in an unchecked block, risking token loss due to integer overflow (7.2 Code Security). Additionally, calculations for maxWallet() and maxTx() are susceptible to overflow if totalSupply is extremely large, potentially leading to incorrect restriction enforcement. Access control (7.3 Access Control) for administrative functions like setPool is appropriately restricted to the factory address.

Governance1/10High risk

The economic model (7.4 Economic) includes initial transfer restrictions based on wallet and transaction size, which are active for a set restrictionSeconds period. The factory address holds significant governance (7.5 Governance) power, being able to set the liquidityPool and initialBuyRecipient and being exempt from all transfer restrictions. A potential ambiguity exists in the maxTx logic, which allows transactions up to 110% of maxWallet, potentially causing confusion despite the maxWallet check. Key parameters like maxWalletBps and restrictionSeconds are immutable, providing predictability but limiting future adaptability.

Upgrades5/10Medium risk

The OdysToken contract is not designed as an upgradeable proxy (7.7 Upgrades). All logic is contained within a single, immutable contract. This eliminates upgrade-related risks but means any future changes or bug fixes would require a new contract deployment and migration of assets.

Final RecommendationWhat to do about this score

It is imperative to address the critical unchecked arithmetic vulnerability in the _move function immediately to prevent potential token loss.

All arithmetic operations involving token balances and restriction calculations should be thoroughly reviewed for overflow/underflow conditions, ensuring safe math practices are consistently applied. Consider re-evaluating the maxTx and maxWallet logic for clarity and consistency, and implement robust security measures for the factory address, such as multi-signature control, given its centralized power. Thoroughly test all restriction mechanisms under various edge cases, including maximum possible values for totalSupply and maxWalletBps.

Contract & Record

1 audit on record
TypeOdysToken
NetworkArbitrum
Token age18d
Contract0x018d…2bd1
Deployer0x986d…b600
Badge for your website
ODYS 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. Aug 30, 202664Medium

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

Related Audits

6 more on the recordAll audits
Curve DAO TokenCRV · Arbitrum64MediumEspressoESP · Arbitrum63MediumLivepeer TokenLPT · Arbitrum63MediumOrderly NetworkORDER · Arbitrum63MediumGraph TokenGRT · Arbitrum63MediumSpell TokenSPELL · Arbitrum63Medium

Would You Like a More Detailed Audit of ODYS?

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