Is Arbitrum (ARB) Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 Med1 Low1 Info

Critical

Critical Trust Assumptions on External Bridge Contracts

C-01The `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).

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

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

StatusUnresolved

Medium

Public `registerTokenOnL2` Allows Arbitrary Registrations

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

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

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

StatusUnresolved

Low

`isArbitrumEnabled` Function Design Limitation

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

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

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

StatusUnresolved

Info

External Call in `transferAndCall` Function

I-01The `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).

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

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

StatusUnresolved

Category Ratings

TechnicalLow7/10

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

GovernanceHigh1/10

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

UpgradesHigh1/10

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.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent

AdminOZ ProxyAdmin

ImplementationVerified source

Upgrades (30d)0 · stable

Holder Composition

61.4% in top 10

61.4% in wallets0.0% in contracts

Effective Concentration61.4%

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

$67.7K across 5 pairs

Uniswap v3WETHanalysed$32.7K Uniswap v4ETH$16.9K Uniswap v3WETH$12.0K Uniswap v4ETH$6.1K SushiswapSUSHI$6

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 Holder98.8%

Top-3 Unlocked100.0%

Key Addresses

3 addresses

Deployer

0x1c8d…d72f

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.

What Raised This Score

9 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

Is Arbitrum Safe?

Security Findings

Critical Trust Assumptions on External Bridge Contracts

Public `registerTokenOnL2` Allows Arbitrary Registrations

`isArbitrumEnabled` Function Design Limitation

External Call in `transferAndCall` Function

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Arbitrum?