Quantum Audit Logo

Is Arbitrum Intern a Scam?

Early-stage security check — honeypot & rug-pull analysis

Arbitrum Intern INTERN
0x2360…b3c8
Arbitrum Not verifiedLast checked 2d ago 1 audit on record New Launch · 15h old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The OdysToken contract implements an ERC-20-like token with initial anti-whale and anti-bot transfer restrictions. The contract utilizes an immutable 'factory' address for initial configuration. While the core ERC-20 functionality is standard, the custom transfer logic and extensive exemption list introduce specific risks related to centralization and potential circumvention of restrictions. The contract is not upgradeable, which eliminates upgrade-related risks.

1 High2 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (15h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$1.9K
Liquidity
$14.1K
Price
$0.00001696
Token Age
15h
Top 10 Holders
79.7%

Security Findings

1 High2 Med1 Low1 Info
High

Centralization Risk with `factory` Address

H-01The `factory` address, set to `msg.sender` during deployment, possesses significant administrative control. It is the only address authorized to call `setPool` and `setInitialBuyRecipient`, which configure critical parameters like the `liquidityPool` and `initialBuyRecipient`. Furthermore, the `factory` address is explicitly exempt from all transfer restrictions (`maxWallet` and `maxTx`). A compromise of this single address could lead to unauthorized manipulation of the token's initial setup or unrestricted movement of tokens, potentially undermining the token's economic stability or initial distribution.
IssueThe `factory` address, set to `msg.sender` during deployment, possesses significant administrative control. It is the only address authorized to call `setPool` and `setInitialBuyRecipient`, which configure critical parameters like the `liquidityPool` and `initialBuyRecipient`. Furthermore, the `factory` address is explicitly exempt from all transfer restrictions (`maxWallet` and `maxTx`). A compromise of this single address could lead to unauthorized manipulation of the token's initial setup or unrestricted movement of tokens, potentially undermining the token's economic stability or initial distribution.
FixConsider implementing a multi-signature wallet for the `factory` address to distribute control and reduce the risk of a single point of failure. If a multi-sig is not feasible, ensure the private key for the `factory` address is secured with the highest possible standards.
StatusUnresolved
Medium

Extensive Exemption List from Transfer Restrictions

M-01The `_exempt` function includes a broad list of addresses (`factory`, `positionManager`, `swapRouter`, `liquidityPool`, `address(this)`, `address(0)`, `DEAD`, `initialBuyRecipient`) that are not subject to the `maxWallet` or `maxTx` transfer restrictions. While some exemptions are necessary (e.g., `address(0)`, `DEAD`), others like `positionManager`, `swapRouter`, `liquidityPool`, and `initialBuyRecipient` represent external contracts or designated recipients. If any of these external contracts are compromised or behave unexpectedly, they could be used to bypass the intended anti-whale/anti-bot mechanisms, potentially allowing large transfers that would otherwise be restricted.
IssueThe `_exempt` function includes a broad list of addresses (`factory`, `positionManager`, `swapRouter`, `liquidityPool`, `address(this)`, `address(0)`, `DEAD`, `initialBuyRecipient`) that are not subject to the `maxWallet` or `maxTx` transfer restrictions. While some exemptions are necessary (e.g., `address(0)`, `DEAD`), others like `positionManager`, `swapRouter`, `liquidityPool`, and `initialBuyRecipient` represent external contracts or designated recipients. If any of these external contracts are compromised or behave unexpectedly, they could be used to bypass the intended anti-whale/anti-bot mechanisms, potentially allowing large transfers that would otherwise be restricted.
FixCarefully review each address in the `_exempt` list. Ensure that the trust placed in these external contracts/addresses is justified and that their security posture is robust. Consider if all these addresses truly require full exemption from transfer limits, or if some could operate within certain bounds.
StatusUnresolved
Medium

`maxTx` Calculation Allows Transfers Exceeding `maxWallet`

M-02The `maxTx()` function calculates the maximum allowed transaction size as `110%` of `maxWallet()`. This design choice means that a single transfer can be larger than the maximum amount a wallet is permitted to hold. While this might be intended for flexibility, it could potentially allow sophisticated users to circumvent the `maxWallet` restriction by repeatedly buying `maxTx` amounts and distributing them across multiple controlled wallets, effectively accumulating more than the `maxWallet` limit across their holdings.
IssueThe `maxTx()` function calculates the maximum allowed transaction size as `110%` of `maxWallet()`. This design choice means that a single transfer can be larger than the maximum amount a wallet is permitted to hold. While this might be intended for flexibility, it could potentially allow sophisticated users to circumvent the `maxWallet` restriction by repeatedly buying `maxTx` amounts and distributing them across multiple controlled wallets, effectively accumulating more than the `maxWallet` limit across their holdings.
FixRe-evaluate the `maxTx` calculation. If the goal is to prevent large accumulations, consider capping `maxTx` at `maxWallet` or a smaller percentage to prevent easy circumvention of the anti-whale mechanism. Ensure the intended behavior aligns with the current implementation.
StatusUnresolved
Low

Lack of Events for Critical State Changes

L-01The `setPool` and `setInitialBuyRecipient` functions modify critical state variables (`liquidityPool` and `initialBuyRecipient`) but do not emit corresponding events. Without events, off-chain monitoring tools and users cannot easily track changes to these important addresses, making it harder to detect unauthorized or unexpected modifications.
IssueThe `setPool` and `setInitialBuyRecipient` functions modify critical state variables (`liquidityPool` and `initialBuyRecipient`) but do not emit corresponding events. Without events, off-chain monitoring tools and users cannot easily track changes to these important addresses, making it harder to detect unauthorized or unexpected modifications.
FixEmit events after successfully updating `liquidityPool` and `initialBuyRecipient`. For example, `event PoolSet(address indexed oldPool, address indexed newPool);` and `event InitialBuyRecipientSet(address indexed oldRecipient, address indexed newRecipient);`.
StatusUnresolved
Info

`maxWalletBps == 0` Disables All Restrictions

I-01If the `maxWalletBps` parameter is initialized to `0` in the constructor, both `maxWallet()` and `maxTx()` functions will return `type(uint256).max`. This effectively disables all anti-whale and anti-bot transfer restrictions for the entire duration of the `restrictionSeconds` period. While this might be an intentional configuration option to launch without restrictions, it's important to be aware that the core restriction logic can be entirely bypassed by this single parameter.
IssueIf the `maxWalletBps` parameter is initialized to `0` in the constructor, both `maxWallet()` and `maxTx()` functions will return `type(uint256).max`. This effectively disables all anti-whale and anti-bot transfer restrictions for the entire duration of the `restrictionSeconds` period. While this might be an intentional configuration option to launch without restrictions, it's important to be aware that the core restriction logic can be entirely bypassed by this single parameter.
FixEnsure that the implications of setting `maxWalletBps` to `0` are fully understood and align with the project's launch strategy. If restrictions are intended, ensure `maxWalletBps` is set to a non-zero value.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The OdysToken contract provides standard ERC-20 functionality with added transfer restrictions during an initial 'guarded' period (7.2 Code Security). The `factory` address, set at deployment, has exclusive control over setting the `liquidityPool` and `initialBuyRecipient` (7.3 Access Control). A significant number of addresses are exempt from transfer restrictions, including `factory`, `positionManager`, `swapRouter`, `liquidityPool`, and `initialBuyRecipient` (7.3 Access Control). While the `_move` function correctly handles `unchecked` arithmetic for additions, the extensive exemption list and the `factory`'s control introduce centralization risks (7.1 Architecture). No external calls are made in critical transfer paths, mitigating reentrancy risks (7.6 External).

GovernanceHigh1/10

The token's economic model includes temporary anti-whale and anti-bot measures via `maxWalletBps` and `restrictionSeconds` (7.4 Economic). The `maxTx` calculation allows transactions up to 110% of the `maxWallet` size, which could potentially allow users to accumulate more than the `maxWallet` limit across multiple addresses (7.4 Economic). The `factory` address holds significant administrative power, including setting the `liquidityPool` and `initialBuyRecipient`, and is exempt from all transfer restrictions, posing a centralization risk (7.5 Governance). If `maxWalletBps` is set to zero, all transfer restrictions are effectively disabled (7.4 Economic).

UpgradesMedium5/10

The OdysToken contract is not designed as an upgradeable proxy (7.7 Upgrades). It is a standard implementation contract, meaning its logic cannot be changed after deployment. This eliminates any risks associated with upgrade mechanisms, such as proxy misconfigurations or upgrade pauses.

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

79.7% in top 10
15.7% in wallets64.0% in contracts
Effective Concentration41.3%

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

$14.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.

Key Addresses

1 addresses
Deployer
0x40c8…db69

What Raised This Score

8 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 30% (79.7% total → 41.3% effective; 15.7% in EOAs, 64.0% in contracts — moderate)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • Liquidity < $50k ($14,128 across 1 pairs — thin market)
  • Token age < 24h (brand new — bot activity, unproven)
  • 1 High finding(s) from audit
  • 2 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
Dai Stablecoin (DAI)High RiskAethir Token (ATH)High RiskCurve DAO Token (CRV)High RiskODYSHigh RiskEspresso (ESP)High RiskLivepeer Token (LPT)High Risk

Would You Like a More Detailed Audit of Arbitrum Intern?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit