Quantum Audit Logo
Launch App

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

Is Arbitrum Dog Safe?

MILESArbitrum
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 · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The OdysToken contract implements an ERC-20-like token with custom anti-whale and anti-bot mechanisms during a restricted launch 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
  • Liquidity < $50k
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • Token age < 30 days
  • 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% (47.4% total → 30.0% effective; 18.3% in EOAs, 29.1% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($29,913 across 1 pairs — thin market)
  • LP top1 unlocked holder = 100.0% (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
  • 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
29.1%Contracts18.3%Wallets52.6%Everyone else
29.1%Contracts18.3%52.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
47.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking29.1%
  • Walletsanonymous holders, free to sell18.3%
  • Everyone elsethe rest of the supply52.6%
Effective concentrationwhat the score reads30.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$29.9K

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$29.9KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x4aca…9f1a0x6951…648d0xee60…2c74

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

Security Findings

1 High1 Medium1 Low1 Info
High

Liquidity Pool Bypass of Max Transaction Limit

The _move function's anti-bot/anti-whale logic exempts the liquidityPool from the MaxTxExceeded check when it is the from address. This means that during the restricted period, any amount of tokens can be transferred from the liquidity pool to a non-exempt address in a single transaction. This directly bypasses the intended maxTx limit, allowing bots or large buyers to acquire an unlimited amount of tokens from the pool in one go.H-01

Issue

The _move function's anti-bot/anti-whale logic exempts the liquidityPool from the MaxTxExceeded check when it is the from address. This means that during the restricted period, any amount of tokens can be transferred from the liquidity pool to a non-exempt address in a single transaction. This directly bypasses the intended maxTx limit, allowing bots or large buyers to acquire an unlimited amount of tokens from the pool in one go.

Fix

Re-evaluate the exemption logic for liquidityPool when it acts as the sender. Consider applying MaxTxExceeded checks for transfers *from* the liquidity pool *to* non-exempt addresses. This may require a more granular exemption mechanism or a specific handler for liquidity pool interactions to ensure the anti-bot measures are effective.

Status

Unresolved

Medium

Initial Buy Recipient Bypasses All Restrictions

The initialBuyRecipient address is included in the _exempt list, which means it is not subject to MaxWalletExceeded or MaxTxExceeded checks during the restricted period. This allows the designated recipient to accumulate an unlimited amount of tokens and transfer any amount in a single transaction, potentially enabling a large holder to bypass anti-whale measures or distribute tokens without limits, which could be exploited for market manipulation or an unfair advantage.M-01

Issue

The initialBuyRecipient address is included in the _exempt list, which means it is not subject to MaxWalletExceeded or MaxTxExceeded checks during the restricted period. This allows the designated recipient to accumulate an unlimited amount of tokens and transfer any amount in a single transaction, potentially enabling a large holder to bypass anti-whale measures or distribute tokens without limits, which could be exploited for market manipulation or an unfair advantage.

Fix

Clarify the intended role and necessity of initialBuyRecipient being fully exempt from all restrictions. If its purpose is for initial distribution, consider if it truly needs to bypass *all* restrictions. If not, remove it from the _exempt list or implement specific, limited exemptions that align with its intended function without compromising the anti-whale mechanism.

Status

Unresolved

Low

Unchecked Arithmetic for Balance Increment

The balanceOf[to] += value; operation within the _move function is placed inside an unchecked block. While an overflow of uint256 is highly unlikely in practical scenarios for token balances, if balanceOf[to] were to be near type(uint256).max, adding value could cause a wraparound, resulting in an incorrect and significantly lower balance for the recipient.L-01

Issue

The balanceOf[to] += value; operation within the _move function is placed inside an unchecked block. While an overflow of uint256 is highly unlikely in practical scenarios for token balances, if balanceOf[to] were to be near type(uint256).max, adding value could cause a wraparound, resulting in an incorrect and significantly lower balance for the recipient.

Fix

Remove the unchecked block around balanceOf[to] += value;. Solidity 0.8+ provides default checked arithmetic, which would cause a revert on overflow, preventing incorrect state and ensuring balance integrity. The performance gain from unchecked in this context is negligible compared to the potential risk.

Status

Unresolved

Info

Precision Loss in BPS Calculations

The maxWallet() and maxTx() functions use integer division for calculations involving BPS (basis points), specifically (totalSupply * maxWalletBps) / BPS. Integer division truncates any fractional remainders, which can lead to minor precision loss in the calculated maximum wallet and transaction sizes.I-01

Issue

The maxWallet() and maxTx() functions use integer division for calculations involving BPS (basis points), specifically (totalSupply * maxWalletBps) / BPS. Integer division truncates any fractional remainders, which can lead to minor precision loss in the calculated maximum wallet and transaction sizes.

Fix

This is a common and generally accepted pattern for basis point calculations in Solidity. No direct action is required unless exact fractional precision is a critical requirement for the token's economic model, in which case a fixed-point math library would be necessary (which adds complexity). Document this behavior if not already clear to stakeholders.

Status

Unresolved

Analysis

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

The OdysToken contract implements an ERC-20-like token with custom anti-whale and anti-bot mechanisms during a restricted launch period. The contract utilizes immutable variables for critical parameters and employs a factory pattern for initial setup and access control. While the core ERC-20 functionality is standard, the anti-bot/anti-whale logic contains significant bypasses for the liquidity pool and an initial buy recipient, which could undermine the intended launch strategy. Additionally, an unchecked arithmetic operation for balance increments poses a minor risk.

Technical8/10Low risk

The contract demonstrates good adherence to ERC-20 standards for basic token operations (7.2 Code Security). Key parameters like factory, launchTime, and restriction settings are correctly set as immutable in the constructor, enhancing architectural stability (7.1 Architecture). Access control for critical functions like setPool and setInitialBuyRecipient is appropriately restricted to the factory address (7.3 Access Control). However, the _move function's anti-bot/anti-whale logic contains a significant flaw where the liquidityPool is exempt from transaction size limits when sending tokens, allowing large buys during the restricted period.

Governance1/10High risk

The contract incorporates anti-whale and anti-bot mechanisms (maxWalletBps, restrictionSeconds) designed to control token distribution during the initial launch phase (7.4 Economic). These measures aim to prevent large single transactions and excessive wallet holdings. However, the exemption of the liquidityPool from MaxTxExceeded checks when it is the sender allows for unlimited buys from the pool, directly undermining the anti-bot mechanism. Furthermore, the initialBuyRecipient is fully exempt from all restrictions, which could be exploited for market manipulation or an unfair advantage, impacting the token's economic stability and fair distribution (7.5 Governance).

Upgrades6/10Medium risk

The OdysToken contract is not designed with upgradeability features, meaning its logic cannot be modified after deployment (7.7 Upgrades). This eliminates risks associated with proxy patterns, such as upgradeability pauses, storage collisions, or malicious upgrades. The immutability of the contract provides certainty regarding its long-term behavior.

Final RecommendationWhat to do about this score

It is crucial to address the identified bypasses in the anti-bot/anti-whale mechanisms to ensure the intended launch strategy and fair distribution are maintained.

Specifically, re-evaluate the exemption logic for the liquidityPool and initialBuyRecipient to prevent unintended circumvention of transaction and wallet size limits. Additionally, remove the unchecked block for balance increments to enhance safety against potential, albeit unlikely, overflows. Thorough testing of the revised restriction logic is recommended before deployment.

Contract & Record

1 audit on record
TypeOdysToken
NetworkArbitrum
Token age13d
Contract0x6bea…2ca7
Deployer0x38e2…933a
Badge for your website
Arbitrum Dog 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, 202653Medium
  2. Sep 2, 202658Medium

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

Related Audits

6 more on the recordAll audits
SubsquidSQD · Arbitrum52MediumCoW Protocol TokenCOW · Arbitrum54MediumEquilibria TokenEQB · Arbitrum55MediumSperax USDUSDS · Arbitrum51MediumWrapped BTCWBTC · Arbitrum57MediumAutonomiANT · Arbitrum49Medium

Would You Like a More Detailed Audit of Arbitrum Dog?

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