Quantum Audit Logo

Is Arbitrum Safe?

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

Arbitrum ARB
0x912c…6548
Arbitrum
Not verifiedThis 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.
Last checked 18d ago 2 audits on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

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.

1 Medium2 Low2 Informational
Volume 24h
$5.05M
Liquidity
$2.61M
Price
$0.1346
Token Age
3y
Top 10 Holders
48.1%

Security Findings

1 Med2 Low2 Info
Medium

Centralized Control over Token Parameters (Minting & Delegation Adjustment)

M-01The `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).
IssueThe `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).
FixEnsure 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.
StatusUnresolved
Low

Dependency on Unaudited `TransferAndCallToken` Implementation

L-01The `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).
IssueThe `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).
FixObtain 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.
StatusUnresolved
Low

Potential for Initial `_totalDelegationHistory` Estimate Manipulation

L-02The `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).
IssueThe `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).
FixWhile 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.
StatusUnresolved
Info

Missing Event for Minting Operations

I-01The `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).
IssueThe `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).
FixConsider 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.
StatusUnresolved
Info

Inconsistent Handling of Negative `_totalDelegationHistory` Values

I-02The 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).
IssueThe 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).
FixReview 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.
StatusUnresolved

Category Ratings

TechnicalLow7/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 checks for zero addresses and initial supply. However, the reliance on the unaudited `TransferAndCallToken` (7.6 External) introduces an unknown security surface. The `_totalDelegationHistory` logic includes a clamping mechanism to prevent underflow, but its consistency with other checks could be improved.

GovernanceLow7/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`, implying a robust multi-signature or similar governance setup. This owner has significant power, including minting and adjusting the `_totalDelegationHistory`, which is critical for quorum calculations. While the `postUpgradeInit` function acknowledges potential manipulation of the initial delegation estimate, its impact is deemed low due to external quorum clamping.

UpgradesHigh2/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` function is provided for specific post-upgrade setup of `_totalDelegationHistory`, with a check to prevent re-initialization. The proxy's admin is a `RoleGatedExecutor`, ensuring secure and governed upgrade control (7.3 Access Control).

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

48.1% in top 10
15.9% in wallets32.2% in contracts
Effective Concentration28.8%

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

$5.90M across 30 pairs
UniswapWBTCanalysed$2.61M44.2%UniswapWETH$1.50M25.4%UniswapUSDC$659.3K11.2%UniswapUSDC$307.6K5.2%UniswapWETH$149.1K2.5%UniswapWETH$102.1K1.7%
Show 4 more pairsShow less
UniswapUSD₮0$92.8K1.6%Camelot v3WETH$72.4K1.2%UniswapUSDC$70.8K1.2%Camelot v3USDC$38.7K0.7%

The 20 remaining pairs hold $303.6K between them and are not listed.

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 Holder36.1%
Top-3 Unlocked47.3%

Key Addresses

11 addresses
Deployer
0xdec5…4d29
Unlocked LP Held By
0xaa5c…6e240xc40e…7cc70x82ef…40ce0x0919…e5060x37b7…0db80x74e6…78250x8b69…eff80x785d…98b70xeee4…8af10x3f74…e4b3

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

What Raised This Score

7 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.1% total → 28.8% effective; 15.9% in EOAs, 32.2% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 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

Related Audits

6 more on the record
PendleMedium RiskLayerZero (ZRO)Medium RiskPearMedium RiskChainLink Token (LINK)Medium RiskPepeMedium RiskWrapped liquid staked Ether 2.0 (WSTETH)Medium Risk

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