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.

On-chain security analysis — is it a scam or legit?
Is Arbitrum Safe?
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 →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- 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 4Holders
as of audit · Sep 4, 2026- Walletsanonymous holders, free to sell61.4%
- Everyone elsethe rest of the supply38.6%
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- Uniswap v3WETHAnalysed$32.7K48.4%
- Uniswap v4ETH$16.9K24.9%
- Uniswap v3WETH$12.0K17.7%
- Uniswap v4ETH$6.1K9.0%
- SushiswapSUSHI$60.0%
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xe204…dad50xc08e…10e7No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
CriticalCritical 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
MediumPublic 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
registerTokenOnL2 Allows Arbitrary RegistrationsIssue
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
LowisArbitrumEnabled 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
isArbitrumEnabled Function Design LimitationIssue
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
InfoExternal 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
transferAndCall FunctionIssue
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 4The 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).
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).
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.
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
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- 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