Arbitrum ARB

Claim: Arbitrum documentation and source code describe ECDSA secp256k1 for transactions/accounts and BLS12-381 for AnyTrust DAC signatures; no quantum threat model published.

Coverage basis: Public documentation and source code inventory classical cryptographic mechanisms; no quantum-specific threat model exists.

Implementation score: 0.25 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: No project-published quantum threat model or risk assessment exists

Assurance: Cryptographic mechanisms are well-documented in official sources. Absence of quantum threat model is confirmed by exhaustive search of docs.arbitrum.io, GitHub repositories, and Arbitrum DAO governance forum.

External analysis (LayerQu, BMIC, academic papers) provides effective quantum risk assessment based on public documentation. The project itself has not published any quantum-specific analysis.

• https://docs.arbitrum.io/intro/glossary
• https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro
• https://github.com/OffchainLabs/nitro
• https://docs.arbitrum.io/nitro-whitepaper.pdf

Claim: Source code (Nitro, token-bridge-contracts), protocol specification (Nitro whitepaper), audit reports, and third-party analysis are publicly available.

Coverage basis: Public GitHub repositories, published audit reports, and independent third-party analyses document classical cryptography usage.

Implementation score: 0.5 · Evidence confidence: High

Issue classification: none · Score treatment: note-only

Assurance: Audits (Trail of Bits through Feb 2026, OpenZeppelin, Consensys Diligence) are current for classical security scope. No quantum-specific audit exists. Third-party quantum assessments (LayerQu, BMIC) are secondary sources but consistent with primary evidence.

The public evidence record is sufficient for external evaluators to assess quantum vulnerability even though the project has not published its own quantum assessment.

• https://github.com/OffchainLabs/nitro
• https://github.com/OffchainLabs/token-bridge-contracts
• https://docs.arbitrum.io/audit-reports
• https://docs.arbitrum.io/nitro-whitepaper.pdf
• https://layerqu.com/chains/arbitrum/

Claim: Arbitrum uses ECDSA secp256k1 for all externally owned account (EOA) transaction signatures, inherited from Ethereum's account model.

Coverage basis: All production transactions on Arbitrum One and Nova require ECDSA secp256k1 signatures for EOAs.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Active production spend authorization remains entirely ECDSA-only

Assurance: ECDSA usage is confirmed in Nitro source code (Geth fork), protocol documentation, and all audit reports. No PQC or hybrid-PQC signature path exists on mainnet.

ERC-4337 smart contract accounts can theoretically use PQ signatures, but this is opt-in, not default, and applies only to new smart contract wallets, not existing EOAs.

• https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro
• https://github.com/OffchainLabs/nitro
• https://docs.arbitrum.io/intro/glossary

Claim: Ethereum account model exposes secp256k1 public keys on first transaction. All EOAs that have sent transactions have exposed public keys vulnerable to offline Shor's algorithm attacks.

Coverage basis: All transacted EOAs on Arbitrum One and Nova have exposed public keys. Per Etherscan/Arbiscan, millions of addresses have sent transactions.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Long-exposure quantum-vulnerable public keys exist for all transacted EOAs with no migration or deprecation path

Assurance: The Ethereum account model's public-key exposure properties are well-understood and documented in academic literature. All EOAs that have sent ≥1 transaction have recoverable public keys in transaction signatures.

Unlike Bitcoin P2PKH (hash-protected until spend), Ethereum/Arbitrum EOAs expose public keys on first transaction, making them vulnerable to offline at-rest attacks immediately after first use.

• https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro
• https://blog.projecteleven.com/posts/quantum-attack-vectors-in-ethereum
• https://www.arxiv.org/pdf/2603.28846

Claim: Arbitrum uses a centralized sequencer (Offchain Labs) with ECDSA keys for batch posting. BoLD validation protocol uses classical cryptography. AnyTrust DAC uses BLS12-381 aggregated signatures.

Coverage basis: Sequencer batch posting to L1 SequencerInbox contract uses ECDSA-signed transactions. AnyTrust DACerts use BLS12-381 over BLS12-381 curve.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Sequencer uses ECDSA keys; AnyTrust DAC uses BLS12-381; both quantum-vulnerable

Assurance: SequencerInbox.sol source code confirms batch poster authorization model. Nitro whitepaper Section 7 documents BLS12-381 usage for AnyTrust DACerts. No PQ alternative exists.

The sequencer is currently centralized (Offchain Labs). Transition to distributed sequencing is planned but not yet implemented. BoLD permissionless validation was activated but relies on classical cryptography for bond posting and dispute resolution.

• https://docs.arbitrum.io/nitro-whitepaper.pdf
• https://github.com/OffchainLabs/nitro-contracts/blob/dcc51066b26b84cb157cbeba2f9f492ab33f9093/src/bridge/SequencerInbox.sol
• https://docs.arbitrum.io/intro/glossary

Claim: Data availability relies on Ethereum L1 (EIP-4844 blobs with KZG commitments, or calldata). AnyTrust mode uses BLS-signed DACerts. Fraud proofs rely on deterministic execution replay.

Coverage basis: EIP-4844 KZG commitments are quantum-vulnerable (pairing-based). AnyTrust DACerts use BLS12-381. Fraud-proof correctness depends on L1 settlement finality.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: KZG commitments (EIP-4844) and BLS DACerts are quantum-vulnerable; DA and state-integrity depend on L1 quantum-vulnerable primitives

Assurance: Arbitrum's DA and state-integrity mechanisms are documented in the Nitro whitepaper and source code. Quantum vulnerability of KZG and BLS is well-established in cryptographic literature.

Fraud-proof correctness depends on L1 settlement finality, which in turn depends on Ethereum's quantum-vulnerable validator BLS signatures and KZG commitments.

• https://docs.arbitrum.io/nitro-whitepaper.pdf
• https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro
• https://postquantum.com/quantum-threat-crypto/ethereum-quantum-vulnerabilities/

Claim: Arbitrum has no native privacy layer or shielded transaction pool.

Coverage basis: Arbitrum does not implement shielded transactions, confidential assets, or zero-knowledge privacy features at the protocol level.

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Third-party privacy applications on Arbitrum would have their own quantum-vulnerability profile separate from this base-protocol evaluation.

• https://docs.arbitrum.io/

Claim: Nitro nodes use standard Ethereum P2P networking (devp2p) with classical cryptography for node identity and peer authentication.

Coverage basis: Nitro forks Geth and inherits its P2P stack including ECDSA-based node identities (enode addresses) and RLPAx transport.

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: P2P node identity is not directly spend, bridge, or custody-critical. Compromise would enable eclipse attacks or transaction censorship but not direct asset theft. Scored as note-only per QRI v3.1 P2P guidance.

P2P layer quantum vulnerability is secondary to spend authorization and bridge vulnerabilities. Node identity compromise would require active network-level attacks rather than offline key recovery.

• https://github.com/OffchainLabs/nitro
• https://docs.arbitrum.io/run-arbitrum-node/run-full-node

Claim: No production PQ wallet, custody, or HSM path exists for Arbitrum. Existing wallets (MetaMask, Rabby, etc.) use ECDSA exclusively.

Coverage basis: All production Arbitrum wallets and custody solutions use ECDSA secp256k1 for key generation and signing.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Third-party PQ smart wallet POCs exist (multivmlabs/pq-smart-wallet) but are unaudited, use RC dependencies, and are not production-ready. No hardware wallet supports PQ signing for Arbitrum.

ERC-4337 and Stylus provide infrastructure for future PQ wallet support but no production path exists today.

• https://docs.arbitrum.io/

Claim: Essentially 0% of Arbitrum's value-at-risk is protected from quantum key-recovery attacks. All L2 TVL, bridged assets, and native ARB tokens are controlled by ECDSA keys.

Coverage basis: Arbitrum One TVL (approximately $2-3B as of mid-2026 per L2Beat/DefiLlama) plus Arbitrum Nova TVL. All value controlled by ECDSA-based EOAs or smart contracts with ECDSA admin keys.

Implementation score: 0.05 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Material long-exposure quantum-vulnerable value exists with no migration, freeze, deprecation, burn, recovery, or policy path

Assurance: Value-at-risk is estimated from public L2 analytics. Exact coverage is unmeasurable because no PQ migration has begun and no vulnerable-value inventory has been published. All value controlled by transacted EOAs, exposed multisigs, and bridge admin keys is at risk.

<25% coverage qualifies for Score 1 per QRI v3.1 coverage thresholds. In practice coverage is near 0% since no production PQC protection exists.

• https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro
• https://docs.arbitrum.io/build-decentralized-apps/token-bridging/token-bridge-erc20

Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations, major protocols) on Arbitrum have migrated to PQ protection.

Coverage basis: Arbitrum Foundation treasury, DAO treasury, bridge admin multisigs, sequencer keys, and major DeFi protocol admin keys all use ECDSA.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Major value pools (bridge escrow, DAO treasury, foundation wallets) remain quantum-vulnerable with no migration path

Assurance: Bridge admin and DAO treasury addresses are publicly documented. No evidence of PQ key migration for any critical wallet.

The Arbitrum Security Council (12-member multisig) and DAO governance contracts control protocol upgrades and bridge parameters. All use ECDSA.

• https://docs.arbitrum.foundation/deployment-addresses
• https://docs.arbitrum.io/audit-reports

Claim: No identification, measurement, deprecation, or migration of quantum-vulnerable accounts has been performed.

Coverage basis: No public inventory of vulnerable EOAs, exposed public keys, or at-risk value pools exists.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: Absence of vulnerable-account inventory is confirmed by exhaustive search of Arbitrum documentation, governance forum, and GitHub repositories.

The Ethereum account model makes identification straightforward in principle (all EOAs with ≥1 transaction have exposed keys), but no project-led effort has been undertaken.

Claim: Arbitrum/Offchain Labs has published no post-quantum migration roadmap, ECDSA deprecation timeline, or PQ upgrade plan.

Coverage basis: Exhaustive search of docs.arbitrum.io, arbitrum.foundation, governance forum, and Offchain Labs GitHub repositories yields no PQ roadmap.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Quantum blocker: No public migration roadmap; contrast with Optimism's published 10-year ECDSA deprecation plan (January 2026)

Assurance: Secondary sources (BlockEden, Medium research) confirm Arbitrum has not published a PQ roadmap. Optimism's January 2026 roadmap provides a peer-L2 contrast.

Arbitrum will likely need to align with Ethereum L1's PQC roadmap for bridge settlement and fraud-proof security. No independent L2-specific plan exists.

• https://blockeden.xyz/blog/2026/05/02/optimisms-10-year-quantum-clock/
• https://medium.com/@junghualiu/post-quantum-roadmaps-for-blockchain-ecosystems-2026

Claim: No PQ migration tooling, wallet paths, user education, or migration prompts exist. ERC-4337 and Stylus provide infrastructure but no migration mechanism.

Coverage basis: No PQ account creation, transaction paths, custody paths, or user-facing warnings exist in production.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: ERC-4337 bundlers (Alto, Pimlico, etc.) are operational on Arbitrum. Stylus is live (ArbOS 31 Bianca). But these are general-purpose infrastructure, not PQ migration tooling.

The existence of ERC-4337 and Stylus means application-layer PQC migration is technically feasible without protocol changes. However, no migration tooling, defaults, or user education exists.

• https://hacken.io/discover/erc-4337-account-abstraction/
• https://medium.com/@niolabs/arbitrum-stylus-poseidon-in-rust-gas-efficient-zk-hashing

Claim: No enforcement mechanisms (deprecation, freeze, disabled legacy signing, restricted withdrawals, mandatory migration deadlines) exist.

Coverage basis: All ECDSA-based transactions remain fully valid and unrestricted. No quantum-aware access controls exist.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Arbitrum DAO governance could theoretically enact migration enforcement, but no proposal has been made or discussed.

Claim: Arbitrum has a Security Council, bug bounty program, and governance process, but no quantum-specific incident-response playbook or disclosure process.

Coverage basis: The Arbitrum Security Council can enact emergency upgrades. The bug bounty program covers smart contract and protocol vulnerabilities. Neither addresses quantum-specific scenarios.

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: The Security Council provides an emergency response mechanism that could theoretically respond to quantum threats, but no quantum-specific planning, scenarios, or playbooks have been developed. Scored as note-only per QRI v3.1: absence of a formal quantum-specific IR playbook is an assurance caveat, not a QRI Score deduction.

General incident-response capability exists through the Security Council's emergency upgrade powers and the bug bounty program.

• https://docs.arbitrum.io/audit-reports
• https://arbitrum.foundation/grants

Claim: Arbitrum does not use any PQC or hybrid-PQC algorithms in production. All cryptography is classical (ECDSA, BLS, Keccak-256).

Coverage basis: No PQC algorithm deployment in Nitro, bridge contracts, or any production component.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Third-party POCs use ML-DSA-65 (FIPS 204) and SLH-DSA (FIPS 205) on Stylus, but these are not part of the Arbitrum protocol.

• https://github.com/OffchainLabs/nitro
• https://github.com/OffchainLabs/token-bridge-contracts

Claim: No quantum-specific audit has been performed. Classical audits (Trail of Bits, OpenZeppelin, Consensys Diligence) cover Nitro, BoLD, Stylus, and bridge contracts but do not evaluate quantum resistance.

Coverage basis: Dozens of classical audits exist through Feb 2026. Zero quantum-specific audits.

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Classical audits are current and high-quality but scope-mismatched for quantum evaluation. The absence of a quantum audit is scored as note-only because no PQC implementation exists to audit; this is a gap to address when PQC is deployed.

Audit reports page lists dozens of audits including Trail of Bits (Nitro v3.2.0, DVP, 2026), OpenZeppelin, Consensys Diligence, and others. All are classical in scope.

• https://docs.arbitrum.io/audit-reports

Claim: Nitro and bridge contracts are open source (Apache 2.0/MIT). No PQC implementation exists to evaluate for reproducibility.

Coverage basis: All production code is publicly available on GitHub under open-source licenses.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Open-source status is confirmed. The subfactor evaluates PQC implementation reproducibility; none exists to evaluate.

Code is open source and buildable. Third-party PQC POCs (pq-smart-wallet) are also open source but not part of the Arbitrum protocol.

• https://github.com/OffchainLabs/nitro
• https://github.com/OffchainLabs/token-bridge-contracts

Claim: No PQC parameter agility or upgrade path is documented. Arbitrum's upgrade mechanism (ArbOS upgrades via DAO governance) could theoretically support future PQC but no plan exists.

Coverage basis: ArbOS upgrade mechanism exists (governance-approved hardforks) but no PQC-specific upgrade path is designed or documented.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: ArbOS upgrade history (20 Atlas, 30, 31 Bianca, 40 Callisto, 51 Dia, 60 Elara) demonstrates mature upgrade infrastructure. However, no parameter agility for cryptographic primitives is documented.

The existence of regular ArbOS upgrades through DAO governance provides a plausible future vehicle for PQC deployment, but this is not a documented upgrade path.

• https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro

Claim: No PQC implementation exists to evaluate for stateful-signature safety or side-channel resistance.

Coverage basis: Not applicable; no PQC deployment.

Implementation score: 0 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Subfactor is applicable in principle but no PQC implementation exists to evaluate.

Third-party POC (pq-smart-wallet) uses stateless ML-DSA-65 (FIPS 204), which does not require state management. This is noted for future reference.

Claim: No project-published performance analysis for PQ signature verification, block validation, gas/fee market impact, or node hardware requirements exists.

Coverage basis: No PQC performance analysis published by Arbitrum/Offchain Labs.

Implementation score: 0 · Evidence confidence: High

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Third-party POC benchmarks show ML-DSA-65 verification at ~374K gas on Stylus (3.7x ECDSA overhead) but these are local devnode measurements, not production-validated. Scored as note-only: no PQC deployment exists, so absence of performance analysis does not affect current quantum-attack readiness.

PQ transaction cost projections from third-party POC: $2-8 per PQ transaction (dominated by L1 calldata costs for 3,309-byte ML-DSA signatures vs 65-byte ECDSA). This is significant for user adoption but not a current quantum-readiness blocker.

• https://github.com/multivmlabs/pq-smart-wallet