Quantum Audit Logo

Is ODYS Safe?

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

ODYS ODYS
0x018d…2bd1
Arbitrum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive 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. 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.

1 Critical1 High1 Medium1 Low2 Informational
Volume 24h
$379.9K
Liquidity
$198.1K
Price
$0.002326
Token Age
18d
Top 10 Holders
24.5%

Security Findings

1 Crit1 High1 Med1 Low2 Info
Critical

Unchecked Arithmetic in Balance Update

C-01The `_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.
IssueThe `_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.
FixRemove 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.
StatusUnresolved
High

Potential Overflow in Restriction Calculations

H-01The `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.
IssueThe `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.
FixImplement 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.
StatusUnresolved
Medium

Ambiguous `maxTx` and `maxWallet` Restriction Logic

M-01The `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.
IssueThe `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.
FixClarify 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.
StatusUnresolved
Low

Standard ERC-20 `approve` Front-Running Vulnerability

L-01The `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.
IssueThe `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.
FixWhile 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.
StatusUnresolved
Info

Immutability of Key Parameters

I-01Several 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.
IssueSeveral 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.
FixEnsure 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.
StatusUnresolved
Info

Centralized Control by `factory` Address

I-02The `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.
IssueThe `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.
FixImplement 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.
StatusUnresolved

Category Ratings

TechnicalLow7/10

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.

GovernanceHigh1/10

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.

UpgradesMedium5/10

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.

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

24.5% in top 10
20.2% in wallets4.4% in contracts
Effective Concentration21.9%

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

$198.1K

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 Holder95.0%
Top-3 Unlocked98.7%

Key Addresses

11 addresses
Deployer
0x986d…b600
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.

What Raised This Score

10 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

Related Audits

6 more on the record
Curve DAO Token (CRV)High RiskEspresso (ESP)High RiskLivepeer Token (LPT)High RiskOrderly Network (ORDER)High RiskGraph Token (GRT)High RiskArbitrum Intern (INTERN)High Risk

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