Layer 2 chains
Layer 2 systems extend Ethereum through additional execution and validation layers that rely on bridges, sequencers, and cross-domain verification. These components introduce new trust assumptions and failure modes that can affect asset safety and system liveness.
STRENGTHS
Public rollup security maturity framework
Rollup security assumptions are documented and tracked using a shared, public maturity model. Using this model, L2BEAT provides a transparent, comparable view of rollup trust assumptions.
Progressive removal of trusted operators
Leading rollups are actively reducing reliance on centralized sequencers and security councils over time.
Emergency controls paired with hardening paths
Temporary security councils provide emergency brakes while fault proofs and ZK systems mature.
Ethereum as a scalable data availability layer
Blobs (EIP-4844) significantly increase Ethereum’s capacity for rollup data publication, reducing costs and improving the security of Layer 2 data availability.
RISKS
Canonical bridges rely on concentrated validation and key management, creating single points of failure where a validation bug or key compromise could enable unauthorized withdrawals and drain L2 TVL.
Single sequencers can censor or halt withdrawals for 24+ hours. All major L2s (Optimism, Arbitrum, zkSync) remain centralized as of December 2025.
Data availability constraints can weaken Layer 2 verifiability. Rollups rely on publishing transaction data to Ethereum to ensure state can be reconstructed and withdrawals remain trust-minimized. Congestion or unavailable data can increase reliance on offchain paths and introduce new centralization risks.
RPC and node infrastructure
Most users and applications interact with Ethereum through RPC infrastructure rather than directly running nodes. This creates an abstraction layer where availability, integrity, censorship resistance, and privacy properties depend on external operators that are not visible or verifiable to end users.
STRENGTHS
Provider diversity with user-controlled switching
Users and wallets can switch between many public RPC providers or self-hosted nodes, reducing single-provider dependency.
Trust-minimized light client verification
Light clients like Helios can sync in seconds and verify Ethereum chain data locally, removing the need to trust RPC responses for correctness.
Private infrastructure as a realistic fallback
Teams can replace public RPCs with self-hosted or cloud-run nodes using standardized clients and APIs, without breaking wallets or applications.
RISKS
Malicious RPC endpoints can feed falsified balances or censor sanctioned transactions before they hit the mempool.
Centralized RPC dependencies create single points of failure and availability risk. Provider redundancy is improving, but many applications still rely on a small number of operators.
Software supply chain
Ethereum applications rely on complex frontend and build pipelines where small changes can have outsized impact. Securing this layer focuses on limiting blast radius, improving detectability, and reducing dependence on mutable, centralized delivery paths.
STRENGTHS
Decentralized frontend hosting patterns
Major dapps serve frontends via IPFS or Arweave with ENS, reducing DNS registrar and CDN compromise risk.
Shared frontend infrastructure enables faster supply-chain containment
High overlap in frontend stacks, shared security channels, and wallet-level mitigations enable faster detection and containment of JavaScript supply-chain attacks across Ethereum applications.
RISKS
Compromise of software dependencies, build pipelines, or update mechanisms can introduce malicious code or vulnerabilities into deployed systems.