Quantum Audit Logo

Is Arbitrum Dog Safe?

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

Arbitrum Dog MILES
0x6bea…2ca7
Arbitrum Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 High1 Medium1 Low1 Informational
Volume 24h
$23.3K
Liquidity
$29.9K
Price
$0.00006464
Token Age
13d
Top 10 Holders
47.4%

Security Findings

1 High1 Med1 Low1 Info
High

Liquidity Pool Bypass of Max Transaction Limit

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

Initial Buy Recipient Bypasses All Restrictions

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

Unchecked Arithmetic for Balance Increment

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

Precision Loss in BPS Calculations

I-01The `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.
IssueThe `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.
FixThis 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceHigh1/10

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

UpgradesMedium6/10

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.

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

47.4% in top 10
18.3% in wallets29.1% in contracts
Effective Concentration30.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

$29.9K

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
0x38e2…933a
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.

What Raised This Score

10 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

Related Audits

6 more on the record
Subsquid (SQD)High RiskCoW Protocol Token (COW)High RiskEquilibria Token (EQB)High RiskWrapped BTC (WBTC)High RiskAutonomi (ANT)High RiskNOXCAT (NOX)High Risk

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