Is Arbitrum (ARB) Safe? Smart Contract Security Analysis

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyFail

Audit History

4 audits on record

Jul 2266Jul 2342Jul 2332Jul 2331

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

The L2ArbitrumToken contract serves as the L2 counterparty for the Arbitrum token, implementing ERC20 functionality with extensions for burning, permitting, voting, and transfer-and-call. It is deployed as an upgradeable proxy, utilizing OpenZeppelin's TransparentUpgradeableProxy pattern. The contract incorporates a controlled minting mechanism (2% annual cap) and a system for tracking total delegated votes, crucial for governance. While the contract leverages battle-tested OpenZeppelin libraries and follows best practices for upgradeability, certain centralized control points and an external dependency introduce a medium level of risk. The owner, a RoleGatedExecutor, manages critical functions like minting and delegation adjustments, which is a common pattern for governance tokens but requires robust governance oversight.

Final Recommendation: It is recommended to conduct a thorough audit of the `TransferAndCallToken` contract to ensure its security and compatibility. For the `L2ArbitrumToken` itself, consider adding an event for the `mint` function to enhance transparency and off-chain monitoring. Review the consistency in handling negative `_totalDelegationHistory` values to ensure clarity and prevent potential misinterpretations of governance data.

Category Ratings

TechnicalLow

7/10

The contract demonstrates good technical architecture (7.1) by extending well-audited OpenZeppelin ERC20, Burnable, Permit, and Votes standards, ensuring robust core token functionality. Code security (7.2) is enhanced by using Solidity 0.8.16, which includes SafeMath by default, and by implementing

GovernanceMedium

6/10

The economic model (7.4) includes a controlled minting function, allowing the owner to mint up to 2% of the total supply annually, which introduces a predictable inflation mechanism. Governance (7.5) is centralized around an `OwnableUpgradeable` contract, with the owner being a `RoleGatedExecutor`,

UpgradesHigh

2/10

The contract is designed for upgradeability (7.7) using OpenZeppelin's `Initializable` pattern and deployed behind a TransparentUpgradeableProxy. The constructor correctly calls `_disableInitializers()`, and the `initialize` function uses the `initializer` modifier. A dedicated `postUpgradeInit

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent

AdminOZ ProxyAdmin

ImplementationVerified source

Upgrades (30d)0 · stable

LP Distribution

Top-1 Unlocked Holder53.2%

Top-3 Unlocked67.4%

What Raised This Score

8 factors

Ownership NOT renounced — owner is a role-gated executor contract
Mintable supply, but capped at 2.0%/year
Proxy contract (upgradeable — admin can replace logic)
Top-10 concentration > 20% (48.4% total → 28.2% effective; 14.7% in EOAs, 33.7% in contracts — mild)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 53.2% (independent LP — depth risk, pool = 54% of DEX liquidity)
1 Medium finding(s) from audit
2 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 Findings

5 total

1 Medium 2 Low 2 Info

M-01MediumUnresolved

Centralized Control over Token Parameters (Minting & Delegation Adjustment)

The `owner` of the `L2ArbitrumToken` contract, identified as a `RoleGatedExecutor`, possesses significant centralized control. This includes the authority to mint new tokens annually, capped at 2% of the total supply, and to manually adjust the `_totalDelegationHistory` via the `adjustTotalDelegation` function. While this pattern is common for governance tokens where a robust governance mechanism (like a multi-sig or DAO) acts as the owner, these functions represent powerful capabilities that directly impact the token's supply and the integrity of governance quorum calculations (7.3 Access Control, 7.4 Economic, 7.5 Governance).

Recommendation: Ensure that the `RoleGatedExecutor` controlling the `owner` address has extremely robust security measures, including a high multi-signature threshold and a well-defined, transparent governance process. Regular audits of the governance mechanism itself are crucial to mitigate risks associated with this centralized power.

L-01LowUnresolved

Dependency on Unaudited `TransferAndCallToken` Implementation

The `L2ArbitrumToken` contract inherits from `TransferAndCallToken`, but the source code for this external dependency was not provided for audit. The security and correctness of `TransferAndCallToken` are critical to the overall integrity and functionality of the `L2ArbitrumToken`. Any vulnerabilities or unexpected behaviors within `TransferAndCallToken` could directly impact the main token contract (7.6 External).

Recommendation: Obtain and thoroughly audit the source code for the `TransferAndCallToken` contract. Verify its implementation against known vulnerability patterns, especially regarding reentrancy and external calls, to ensure it does not introduce any weaknesses into the `L2ArbitrumToken` system.

L-02LowUnresolved

Potential for Initial `_totalDelegationHistory` Estimate Manipulation

The `postUpgradeInit` function, used to set the initial `_totalDelegationHistory`, includes a comment acknowledging that this initial estimate 'may be manipulable with artificial delegation/undelegation prior to the upgrade.' While the comment states that the risk/impact is low due to quorum clamping by governors, it highlights a known edge case where the initial state of a critical governance parameter could be influenced (7.4 Economic, 7.5 Governance, 7.7 Upgrades).

Recommendation: While the impact is noted as low, consider if there are further measures to minimize the window or opportunity for such manipulation, or to provide clearer documentation on how the 'estimate' is derived and validated. Ensure the quorum clamping mechanism is robust and well-understood.

I-01InformationalUnresolved

Missing Event for Minting Operations

The `mint` function, which allows the owner to create new tokens, does not emit an explicit event. While ERC20 `_mint` internally emits a `Transfer` event from `address(0)`, a dedicated `Mint` event could provide clearer, more specific information for off-chain monitoring, indexing, and transparency regarding token supply changes (7.2 Code Security, 7.8 Operations).

Recommendation: Consider adding a custom `event Mint(address indexed recipient, uint256 amount)` within the `mint` function to provide more explicit signaling of minting operations. This enhances transparency and simplifies off-chain analysis.

I-02InformationalUnresolved

Inconsistent Handling of Negative `_totalDelegationHistory` Values

The contract exhibits inconsistent handling of potentially negative values for `_totalDelegationHistory`. In `_updateDelegationHistory`, if `newValue` becomes negative, it is clamped to `0` (`uint256(newValue < 0 ? int256(0) : newValue)`). In contrast, the `adjustTotalDelegation` function uses a `require(newValue >= 0)` statement, which would revert if `newValue` is negative. While both approaches prevent underflow, the clamping in `_updateDelegationHistory` might silently mask an underlying issue if the calculated delta is unexpectedly large and negative, potentially leading to an inaccurate `_totalDelegationHistory` without an explicit error (7.2 Code Security).

Recommendation: Review the logic for `_totalDelegationHistory` adjustments to ensure consistent error handling or clamping behavior. If a negative value indicates an error state, consider reverting in `_updateDelegationHistory` as well, or provide clear documentation on why clamping is preferred in one context and reverting in another.

Is Arbitrum Safe? ARB