Arbitrum smart contract audit

Arbitrum, as this product sees it

Incidents on Arbitrum

None of the 20 incidents in our Hall of Hacks happened on Arbitrum. That is a fact about our collection — the twenty largest losses we researched — and not a statement that Arbitrum is safe. Read it as "we have no case study here", nothing more.

What the scanner checks on Arbitrum

The same 201 detectors run on every chain. We do not have Arbitrum-specific rules and this page will not pretend otherwise — what differs by chain is the explorer, the RPC endpoints, the router used for the buy/sell simulation, and the incidents above. The analysis itself is one engine.

It covers 203 documented weaknesses across 20 categories:

• Access Control
• Arithmetic
• Best Practice
• Bridge / Cross-Chain
• Centralization
• DeFi Economic
• Denial of Service
• External Calls
• Governance
• Input Validation
• Logic / State
• Low-Level / Assembly
• MEV / Ordering
• Oracle / Price
• Randomness
• Reentrancy
• Signatures
• Time Dependence
• Token Standards
• Upgradeability

Each one has a page in the vulnerability database explaining the weakness, what it looks like in Solidity and how to fix it — generated from the detector table itself, so the explanation can never describe a different rule from the one that graded you.

If the contract is not verified on arbiscan.io

Most of what is worth checking is unverified, and for those the source engine has nothing to read. The bytecode analyser reads the deployed bytecode instead: the function selectors in the dispatcher, the opcodes present, proxy shape and the implementation slot, and the addresses compiled in.

It reports powers, not intent. A mint(address,uint256) selector proves a mint entry point exists; it cannot prove who is allowed to call it. Access control lives in control flow, and reconstructing that from bytecode is decompilation, which this is not.