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

Is Arbitrum Intern a Scam?

INTERNArbitrum

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 recordNew Launch · 15h old

Chart

65/ 100

High RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical6/10 Governance1/10 Upgrades6/10 Checks passed5 of 7 Findings1 High · 2 Medium · 1 Low · 1 Info5

SummaryAI Copilot

The OdysToken contract implements an ERC-20-like token with initial anti-whale and anti-bot transfer restrictions.

Read the full analysis

What raised the score

Ownership status UNKNOWN
Top-10 concentration > 30%
LP lock status UNKNOWN — the pool's LP could not be read
Liquidity < $50k
Token age < 24h
1 High finding(s) from audit
2 Medium finding(s) from audit
1 Low finding(s) from audit

Exact 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)
LP lock status UNKNOWN — the pool's LP could not be read
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

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.

Security Checklist

as of audit · Sep 45 of 7 checks passed

Contract verifiedVerified

OwnershipUnknown

MintNo mint

Liquidity lockUnknown

UpgradeabilityFixed code

HoneypotNone found

Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

79.7%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking64.0%
Walletsanonymous holders, free to sell15.7%
Everyone elsethe rest of the supply20.3%

Effective concentrationwhat the score reads41.3%

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$14.1K

The risk score reads depth across every pair.

LP tokensUnknown

Whether the LP tokens are locked could not be determined.

Analysed pool$14.1KShare of depth100.0%

Security Findings

1 High2 Medium1 Low1 Info

High

Centralization Risk with `factory` Address

The 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.H-01

Issue

Fix

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

Status

Unresolved

Medium

Extensive Exemption List from Transfer Restrictions

The _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.M-01

Issue

Fix

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

Status

Unresolved

Medium

`maxTx` Calculation Allows Transfers Exceeding `maxWallet`

The 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.M-02

Issue

Fix

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

Status

Unresolved

Low

Lack of Events for Critical State Changes

The 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.L-01

Issue

Fix

Emit 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);`.

Status

Unresolved

Info

`maxWalletBps == 0` Disables All Restrictions

If 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.I-01

Issue

Fix

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

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

Technical6/10Medium risk

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

Governance1/10High risk

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

Upgrades6/10Medium risk

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.

Final RecommendationWhat to do about this score

It is recommended to carefully manage the private key associated with the factory address due to its significant control over initial token parameters and exemptions.

Consider implementing a multi-signature wallet for the factory address to enhance security and decentralize control. Review the maxTx calculation logic to ensure it aligns with the intended anti-whale mechanism, potentially capping maxTx at maxWallet or a smaller percentage. For better off-chain monitoring, emit events when critical parameters like liquidityPool or initialBuyRecipient are set.

Contract & Record

1 audit on record

TypeOdysToken

NetworkArbitrum

Token age15h

Contract0x2360…b3c8

Deployer0x40c8…db69

Badge for your website

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

Aug 31, 202665High

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

Frequently Asked Questions

What is the INTERN contract address?

The Arbitrum Intern (INTERN) contract on Arbitrum is 0x23607980905fad2199538509a1a262a31e36b3c8. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.