Quantum Audit Logo
Launch App

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

Is Arbitrum Safe?

ARBEthereum
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
SummaryAI Copilot

The L1ArbitrumToken contract serves as the L1 representation of the Arbitrum token, utilizing OpenZeppelin's upgradeable ERC20 standard and integrating with Arbitrum bridge components.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Proxy contract
  • Top-10 concentration > 50%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 98.8%
  • LP top3 unlocked holders = 100.0%
  • 1 Critical 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)
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 50% (61.4% total → 61.4% effective; 61.4% in EOAs, 0.0% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 98.8% (independent LP — depth risk, pool = 48% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 48% of DEX liquidity)
  • 1 Critical 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 44 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
61.4%Wallets38.6%Everyone else
61.4%Wallets38.6%Everyone else
WalletsEveryone elseBubble area = share of supply
61.4%of supply sits with the top 10 holders
  • Walletsanonymous holders, free to sell61.4%
  • Everyone elsethe rest of the supply38.6%
Effective concentrationwhat the score reads61.4%
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$67.7K across 5 pairs
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$32.7KShare of depth48.4%
Top-1 Unlocked Holder98.8%
Top-3 Unlocked100.0%
Unlocked LP held by
0xe204…dad50xc08e…10e7

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

Security Findings

1 Critical1 Medium1 Low1 Info
Critical

Critical Trust Assumptions on External Bridge Contracts

The L1ArbitrumToken contract's core functionality, including bridgeMint and bridgeBurn, is entirely dependent on the arbOneGateway contract. Similarly, registerTokenOnL2 relies on novaGateway and novaRouter. These external contracts are critical for the token's supply control and L2 integration. A compromise or malfunction of any of these trusted external bridge components would directly lead to unauthorized minting, burning, or manipulation of the token's L2 registration, severely impacting the token's integrity and value (7.6 External).C-01

Issue

The L1ArbitrumToken contract's core functionality, including bridgeMint and bridgeBurn, is entirely dependent on the arbOneGateway contract. Similarly, registerTokenOnL2 relies on novaGateway and novaRouter. These external contracts are critical for the token's supply control and L2 integration. A compromise or malfunction of any of these trusted external bridge components would directly lead to unauthorized minting, burning, or manipulation of the token's L2 registration, severely impacting the token's integrity and value (7.6 External).

Fix

Ensure that the arbOneGateway, novaGateway, and novaRouter contracts are rigorously audited, highly secure, and managed with robust access controls (e.g., multisig, time-locks). Implement continuous monitoring for any suspicious activity originating from or targeting these addresses. Consider a multi-layered security approach for these critical components.

Status

Unresolved

Medium

Public registerTokenOnL2 Allows Arbitrary Registrations

The registerTokenOnL2 function is public and payable, allowing any external address to call it and initiate a token registration on L2. While this does not directly affect the L1 token balance, a malicious actor could repeatedly call this function with arbitrary or suboptimal RegistrationParams, incurring gas costs for the transaction and potentially registering the token with undesirable parameters on L2. This could lead to griefing attacks or inefficient L2 setups, consuming network resources and potentially causing confusion (7.3 Access Control, 7.4 Economic).M-01

Issue

The registerTokenOnL2 function is public and payable, allowing any external address to call it and initiate a token registration on L2. While this does not directly affect the L1 token balance, a malicious actor could repeatedly call this function with arbitrary or suboptimal RegistrationParams, incurring gas costs for the transaction and potentially registering the token with undesirable parameters on L2. This could lead to griefing attacks or inefficient L2 setups, consuming network resources and potentially causing confusion (7.3 Access Control, 7.4 Economic).

Fix

Consider restricting access to the registerTokenOnL2 function to a trusted entity, such as a governance contract or a multisig wallet. This would prevent arbitrary calls and ensure that L2 registrations are performed only by authorized parties with carefully chosen parameters.

Status

Unresolved

Low

isArbitrumEnabled Function Design Limitation

The isArbitrumEnabled function includes a `require(shouldRegisterGateway, "L1ArbitrumToken: not expecting gateway registration"); statement. Since shouldRegisterGateway is a private variable that is only temporarily set to true within the registerTokenOnL2 function, isArbitrumEnabled will almost always revert when called externally. This design makes the external view` function effectively unusable as a public informational query, which might be counter-intuitive for integrators or users expecting to check the token's Arbitrum enablement status (7.1 Architecture, 7.2 Code Security).L-01

Issue

The isArbitrumEnabled function includes a `require(shouldRegisterGateway, "L1ArbitrumToken: not expecting gateway registration"); statement. Since shouldRegisterGateway is a private variable that is only temporarily set to true within the registerTokenOnL2 function, isArbitrumEnabled will almost always revert when called externally. This design makes the external view` function effectively unusable as a public informational query, which might be counter-intuitive for integrators or users expecting to check the token's Arbitrum enablement status (7.1 Architecture, 7.2 Code Security).

Fix

If isArbitrumEnabled is intended to be a publicly queryable status, consider removing the shouldRegisterGateway check or modifying the logic to reflect a persistent state. If its current behavior is intentional for internal bridge logic, consider making it internal or adding comments to clarify its specific use case and limitations.

Status

Unresolved

Info

External Call in transferAndCall Function

The transferAndCall function performs an external call to the onTokenTransfer function of the recipient contract if the recipient is a contract. While the token transfer (super.transfer) occurs before the external call, adhering to the Checks-Effects-Interactions pattern, any external call introduces a potential reentrancy vector for other functions within the L1ArbitrumToken contract or other interacting protocols. This is a standard pattern for transferAndCall functionality (7.2 Code Security, 7.6 External).I-01

Issue

The transferAndCall function performs an external call to the onTokenTransfer function of the recipient contract if the recipient is a contract. While the token transfer (super.transfer) occurs before the external call, adhering to the Checks-Effects-Interactions pattern, any external call introduces a potential reentrancy vector for other functions within the L1ArbitrumToken contract or other interacting protocols. This is a standard pattern for transferAndCall functionality (7.2 Code Security, 7.6 External).

Fix

No direct vulnerability is identified, as the pattern is correctly implemented. However, it is crucial for any contract interacting with L1ArbitrumToken via transferAndCall to be aware of this external call and ensure its own functions are reentrancy-safe, especially if they rely on the L1ArbitrumToken's state after the transfer.

Status

Unresolved

Analysis

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

The L1ArbitrumToken contract serves as the L1 representation of the Arbitrum token, utilizing OpenZeppelin's upgradeable ERC20 standard and integrating with Arbitrum bridge components. The audit identified a critical dependency on the security and integrity of external bridge contracts for token minting, burning, and L2 registration. While the contract adheres to good coding practices and uses a secure upgradeability pattern, the significant trust assumptions on external systems elevate the overall risk. Minor issues related to public function access and design limitations were also noted.

Technical7/10Low risk

The L1ArbitrumToken contract is an upgradeable ERC20 token leveraging OpenZeppelin's ERC20Upgradeable and ERC20PermitUpgradeable for robust token functionality and standard upgradeability. It also includes a TransferAndCallToken extension, allowing for atomic token transfers and external contract calls. A critical aspect is its reliance on external Arbitrum bridge components (arbOneGateway, novaGateway, novaRouter) for bridgeMint, bridgeBurn, and L2 token registration, which introduces significant trust assumptions (7.6). The transferAndCall function correctly implements a Checks-Effects-Interactions pattern, mitigating reentrancy risks on the token transfer itself (7.2).

Governance1/10High risk

The economic model of the L1ArbitrumToken is primarily driven by its minting and burning mechanisms, which are exclusively controlled by the arbOneGateway contract (7.4). This centralizes control over the token supply to a single external entity, making its security paramount. The registerTokenOnL2 function, while public, allows anyone to initiate L2 registration processes by paying associated gas and value, potentially leading to inefficient or griefing registrations (7.5). The initialize function ensures proper setup of critical bridge addresses upon deployment, preventing re-initialization (7.3).

Upgrades1/10High risk

The contract utilizes the Transparent Upgradeable Proxy pattern with OpenZeppelin's Initializable base, ensuring a secure and well-understood upgrade mechanism (7.7). The constructor correctly calls _disableInitializers() to prevent re-initialization of the implementation contract. The initialize function is properly guarded by the initializer modifier, allowing it to be called only once. This setup provides a robust framework for future upgrades without affecting existing state or logic.

Final RecommendationWhat to do about this score

It is recommended to conduct a thorough audit of the arbOneGateway, novaGateway, and novaRouter contracts, as their security directly impacts the L1ArbitrumToken's integrity and token supply.

Implement robust monitoring for these external bridge components to detect any unauthorized activity. Consider restricting access to the registerTokenOnL2 function to a trusted entity or a multisig to prevent potential griefing or suboptimal L2 registrations.

Contract & Record

1 audit on record
TypeTransparentUpgradeableProxy
NetworkEthereum
Token age3y
Contract0xb507…4ad1
Deployer0x1c8d…d72f
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → RoleGatedExecutor
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Arbitrum 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 1, 202656Medium

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

Frequently Asked Questions

What is the ARB contract address?

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

Is Arbitrum a scam?

Quantum Audit's risk score for Arbitrum is 56/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Upgradeable; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is ARB liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $67.7K.

Who holds ARB?

As of Sep 4, 2026, the 10 largest holders own 61.4% of the supply. The Holders section on this page shows who they are by holder type.

Would You Like a More Detailed Audit of Arbitrum?

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