Ethereum

Version: 1.0

Authors: David Cervigni

Executive Summary

This section contains an executive summary of the identified threats and their mitigation status

There are 6 unmitigated threats without proposed operational controls.

Threat IDCVSSAlways valid?
Ethereum.
EVM_PROTOCOL_VULNERABILITY 		9.1 (Critical) Yes
Ethereum.
GOVERNANCE_ATTACK_FORK 		8.9 (High) Yes
Ethereum.
CLIENT_SOFTWARE_BUG 		8.7 (High) Yes
Ethereum.
POS_CONSENSUS_ATTACK 		8.1 (High) Yes
Ethereum.
STAKING_CENTRALIZATION_RISK 		6.5 (Medium) Yes
Ethereum.
MEV_CENSORSHIP_REORDERING 		6.5 (Medium) Yes

Threats Summary

This section contains an executive summary of the threats and their mitigation status

There are a total of 6 identified threats of which 6 are not fully mitigated by default, and 6 are unmitigated without proposed operational controls.

Threat IDCVSSValid when (condition)Fully mitigatedHas Operational
countermeasures
Ethereum.
EVM_PROTOCOL_VULNERABILITY 		9.1 (Critical) Always valid ❌ No
Ethereum.
GOVERNANCE_ATTACK_FORK 		8.9 (High) Always valid ❌ No
Ethereum.
CLIENT_SOFTWARE_BUG 		8.7 (High) Always valid ❌ No
Ethereum.
POS_CONSENSUS_ATTACK 		8.1 (High) Always valid ❌ No
Ethereum.
STAKING_CENTRALIZATION_RISK 		6.5 (Medium) Always valid ❌ No
Ethereum.
MEV_CENSORSHIP_REORDERING 		6.5 (Medium) Always valid ❌ No

Ethereum - scope of analysis

Overview

This threat model focuses on the Ethereum Mainnet protocol layer, specifically after the transition to Proof-of-Stake (PoS) via "The Merge". It examines the security properties and potential threats related to the PoS consensus mechanism (Gasper: Casper FFG + LMD GHOST), the Ethereum Virtual Machine (EVM) as the foundation for smart contracts, the ETH native asset, and interactions between key participants (validators, users, client software, staking pools). While Layer 2 solutions and individual Decentralized Applications (DApps) are built upon Ethereum, this model primarily addresses the foundational L1 protocol security, acknowledging that L1 vulnerabilities impact the entire ecosystem.

Ethereum security objectives

Core Ledger Security:

Operational Security:

Network Properties:

Asset Protection:

Core Ledger Security:

Diagram: Details:

Censorship Resistance (CENSORSHIP_RESISTANCE)

Ensure the network's ability to eventually include any valid transaction submitted with sufficient fees, resisting systematic exclusion based on sender, receiver, or transaction content (e.g., interactions with specific contracts).

Priority: High

Attack tree:

ETH Asset Security (ASSET_SECURITY)

Protect the integrity of the ETH asset, its supply mechanics (issuance vs. burn via EIP-1559), prevent unauthorized creation/destruction, and maintain its utility within the ecosystem (e.g., as gas, stake).

Priority: High

Attack tree:

Ledger Consistency (Canonical Chain) (LEDGER_CONSISTENCY)

Ensure all honest participating nodes eventually agree on the single, canonical sequence of blocks and state transitions, resolving temporary forks according to the fork-choice rule (LMD GHOST).

Priority: High

Attack tree:

Ledger Integrity (LEDGER_INTEGRITY)

Ensure the Ethereum blockchain accurately reflects the outcome of all valid state transitions dictated by processed transactions and blocks, prevents double-spending of ETH, and maintains a consistent history according to consensus rules.

Priority: High

Attack tree:

Network Availability and Liveness (AVAILABILITY)

Ensure the Ethereum network remains operational, producing new blocks, processing valid transactions, and achieving finality in a timely manner, remaining resilient to disruptions and validator downtime.

Priority: High

Attack tree:

Network Decentralization (DECENTRALIZATION)

Ensure control over network validation (stake distribution), client software development, and protocol governance is sufficiently distributed to prevent single points of failure, control, or capture by any single entity or small group.

Priority: High

Attack tree:

Smart Contract Platform Integrity (SMART_CONTRACT_PLATFORM_INTEGRITY)

Ensure the foundational security and correct execution semantics of the Ethereum Virtual Machine (EVM) and precompiled contracts, providing a reliable base for deploying DApps. (Does not cover individual DApp bugs).

Priority: High

Attack tree:

Transaction Finality (TRANSACTION_FINALITY)

Ensure that once a block containing a transaction reaches finality (typically after 2 epochs, ~13 minutes, via Casper FFG checkpoints), it cannot be reverted or changed by the protocol without incurring massive economic penalties (slashing).

Priority: High

Attack tree:

Ethereum Threat Actors

Actors, agents, users and attackers may be used as synonymous.

Standard unauthenticated network attacker attempti[...] (EXTERNAL_ATTACKER)
Description:

Standard unauthenticated network attacker attempting to exploit network protocols, client vulnerabilities, or flood the network.

In Scope as threat actor:

Yes

An operator of one or more validators attempting t[...] (MALICIOUS_VALIDATOR)
Description:

An operator of one or more validators attempting to disrupt consensus, double-sign, censor transactions/blocks, or gain unfair advantages (e.g., excessive MEV). Includes potential collusion between validators.

In Scope as threat actor:

Yes

An Ethereum user attempting to spam the network, e[...] (MALICIOUS_USER)
Description:

An Ethereum user attempting to spam the network, exploit EVM/contract interactions at the protocol level, or defraud others via transaction manipulation.

In Scope as threat actor:

Yes

An attacker focusing on network-level attacks like[...] (NETWORK_MANIPULATOR)
Description:

An attacker focusing on network-level attacks like partitioning, BGP hijacking, or large-scale DoS against client nodes or the P2P network.

In Scope as threat actor:

Yes

A government or regulatory body attempting to enfo[...] (REGULATOR_OR_STATE_ACTOR)
Description:

A government or regulatory body attempting to enforce censorship, surveillance, or control over the network, potentially by pressuring validators, client developers, or staking pools.

In Scope as threat actor:

Yes

Operators of large staking pools (liquid or centra[...] (STAKING_POOL_OPERATOR)
Description:

Operators of large staking pools (liquid or centralized exchanges) who could potentially collude, censor, or become central points of failure or regulatory pressure due to concentrated stake.

In Scope as threat actor:

Yes

Actors within the MEV supply chain (searchers iden[...] (MEV_SEARCHER_BUILDER_RELAY)
Description:

Actors within the MEV supply chain (searchers identifying opportunities, builders creating blocks, relays connecting builders/proposers) who could collude, censor, or manipulate transaction ordering for profit.

In Scope as threat actor:

Yes

The Ethereum Foundation, while primarily focused o[...] (ETHEREUM_FOUNDATION)
Description:

The Ethereum Foundation, while primarily focused on research and stewardship, holds influence through funding, research direction, and coordination, potentially creating perceived centralization or steering governance outcomes (less direct control than RippleCo).

In Scope as threat actor:

Yes

Assumptions

CRYPTOGRAPHY_SOUNDNESS

Standard cryptographic primitives used (ECDSA, Keccak-256, BLS signatures for consensus) are computationally secure against current threats.

PUBLIC_NETWORK

The Ethereum network operates over the public internet and peer discovery allows broad participation.

VALIDATOR_RATIONALITY

Validators are generally rational economic actors motivated by maximizing staking rewards and avoiding slashing penalties.

CLIENT_IMPLEMENTATION_CORRECTNESS

Assume client software implementations generally adhere to the Ethereum specification, though bugs are a known risk (modeled as a threat). Client diversity is assumed to exist as a mitigating factor.

NETWORK_LIVENESS

Assume the underlying network generally allows for timely propagation of messages (blocks, attestations) required for consensus liveness, though partitions are a threat.

Assets

Summary Table

Title(ID)TypeIn Scope
Ethereum Blockchain (State Machine)
ETHEREUM_BLOCKCHAIN 		system ✔️
Ether (ETH)
ETH 		data ✔️
Validator Nodes
VALIDATORS 		system ✔️
Ethereum Virtual Machine (EVM)
EVM 		system ✔️
Proof-of-Stake Consensus (Gasper)
POS_CONSENSUS 		process ✔️
Ethereum Transactions
TRANSACTIONS 		dataflow ✔️
User Accounts (EOAs & Contracts)
USER_ACCOUNTS 		system ✔️
Staked ETH
STAKED_ETH 		data ✔️
Execution Clients (e.g., Geth, Nethermind)
EXECUTION_CLIENTS 		system ✔️
Consensus Clients (e.g., Prysm, Lighthouse)
CONSENSUS_CLIENTS 		system ✔️

Details

Ethereum Blockchain (State Machine) (system in scope - ID: ETHEREUM_BLOCKCHAIN)

The distributed ledger maintaining the global state of accounts, balances, and smart contract storage.

Ether (ETH) (data in scope - ID: ETH)

The native cryptocurrency of the Ethereum network, used for gas fees and staking.

Validator Nodes (system in scope - ID: VALIDATORS)

Entities running client software, having staked ETH, responsible for proposing and attesting to blocks in the PoS consensus.

Ethereum Virtual Machine (EVM) (system in scope - ID: EVM)

The computation engine that executes smart contract code during state transitions.

Proof-of-Stake Consensus (Gasper) (process in scope - ID: POS_CONSENSUS)

The combination of Casper FFG (finality gadget) and LMD GHOST (fork-choice rule) governing block production and validation.

Ethereum Transactions (dataflow in scope - ID: TRANSACTIONS)

Signed messages broadcast to the network, initiating state changes (transfers, contract calls, deployments). Includes the concept of the mempool.

User Accounts (EOAs & Contracts) (system in scope - ID: USER_ACCOUNTS)

Externally Owned Accounts (controlled by private keys) and Contract Accounts (controlled by code).

Staked ETH (data in scope - ID: STAKED_ETH)

ETH deposited into the Beacon Chain deposit contract to activate and run validators, subject to slashing penalties.

Execution Clients (e.g., Geth, Nethermind) (system in scope - ID: EXECUTION_CLIENTS)

Software responsible for executing transactions, managing state, and handling the EVM.

Consensus Clients (e.g., Prysm, Lighthouse) (system in scope - ID: CONSENSUS_CLIENTS)

Software responsible for managing the Beacon Chain, PoS consensus logic, attestations, and block production.

Ethereum Analysis

Ethereum's transition to Proof-of-Stake aims to provide scalability, security, and energy efficiency while maintaining decentralization. Its core strength lies in the EVM, enabling a vast ecosystem of DApps. The PoS consensus (Gasper) relies on economic incentives (staked ETH) and penalties (slashing) to secure the network. Key security concerns revolve around potential stake centralization (via liquid staking pools and exchanges), the complexities and potential for censorship introduced by MEV (Maximal Extractable Value), the security of multiple client implementations, and ensuring robust censorship resistance against external pressures. Compared to XRPL's FBA, Ethereum targets stronger decentralization and censorship resistance guarantees but historically had lower base-layer throughput and longer finality times, driving innovation towards Layer 2 scaling solutions. Governance is managed off-chain through a social consensus process around Ethereum Improvement Proposals (EIPs).

Ethereum Attack tree

Ethereum Threats

Note This section contains the threat and mitigations identified during the analysis phase.

Proof-of-Stake Consensus Attack (Stake Dominance) (POS_CONSENSUS_ATTACK)

Threat actors:
Threat Description

An attacker (or colluding group) acquires sufficient staked ETH to disrupt or manipulate consensus. Thresholds include >1/3 stake for liveness attacks (preventing finality), >51% stake for certain censorship/reorg attacks (before finality), or >2/3 stake potentially needed to finalize alternative malicious forks (extremely difficult and costly due to slashing). Actions could include censoring blocks/transactions, attempting short-term reorgs, or halting finality.

Impact

Network fails to finalize blocks, valid transactions are persistently censored, temporary chain reorganizations cause confusion and potential double-spends (if finality is broken), loss of confidence in the network's security.
LEDGER_INTEGRITY
LEDGER_CONSISTENCY
TRANSACTION_FINALITY
AVAILABILITY
CENSORSHIP_RESISTANCE
ASSET_SECURITY

CVSS
Environmental score: 8.1 (High)
Vector:CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

Counter-measures for POS_CONSENSUS_ATTACK

SLASHING_PENALTIES Slashing Penalties

Validators detected performing malicious actions (e.g., double-signing, surrounding votes) have a significant portion of their stake burned and are ejected from the validator set, creating a strong economic disincentive.

Countermeasure in place? ✔ Public and disclosable? ✔

INACTIVITY_LEAK Inactivity Leak Mechanism

If the chain fails to finalize for several epochs, validators who are not participating correctly gradually lose stake, ensuring the chain can eventually recover finality once >2/3 of active stake resumes participation. Discourages liveness attacks.

Countermeasure in place? ✔ Public and disclosable? ✔

ATTESTATION_REQUIREMENTS Attestation Participation Requirements

Validators are rewarded for timely attestations supporting the canonical chain and penalized for missing them, incentivizing participation and convergence.

Countermeasure in place? ✔ Public and disclosable? ✔

SOCIAL_COORDINATION_RECOVERY Social Coordination for Recovery

In extreme attack scenarios (e.g., successful >51% attack breaking guarantees), the community can potentially coordinate off-chain to hard-fork and slash the attacker's funds, acting as a final backstop (highly contentious).

Countermeasure in place? ❌ Public and disclosable? ✔

Staking Centralization Risk via Pools/Exchanges (STAKING_CENTRALIZATION_RISK)

Threat actors:
Threat Description

Market dynamics lead to a large percentage of staked ETH being concentrated in a small number of liquid staking protocols (e.g., Lido) or centralized exchanges. This concentration creates systemic risks, potential censorship vectors (if pool operators are coerced or act maliciously), and reduces the effective decentralization of validation power.

Impact

Increased risk of censorship if dominant pools comply with external pressure, potential for large-scale slashing events if a dominant pool's infrastructure fails or acts maliciously, reduced resilience to bugs affecting a dominant pool's setup, erosion of network's perceived decentralization and neutrality.
DECENTRALIZATION
CENSORSHIP_RESISTANCE
AVAILABILITY

CVSS
Base score: 6.5 (Medium)
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L

Counter-measures for STAKING_CENTRALIZATION_RISK

PROMOTE_SOLO_STAKING Encourage Solo Staking

Efforts to lower the technical barriers and promote the benefits of individuals running their own validators to increase decentralization.

Countermeasure in place? ❌ Public and disclosable? ✔

DIVERSE_STAKING_SOLUTIONS Foster Diverse Staking Solutions

Support the development and adoption of multiple competing liquid staking protocols and staking providers to avoid single points of dominance.

Countermeasure in place? ❌ Public and disclosable? ✔

STAKING_POOL_TRANSPARENCY Staking Pool Transparency

Encourage staking pools to be transparent about their operations, infrastructure, governance, and compliance stances.

Countermeasure in place? ❌ Public and disclosable? ✔

CLIENT_DIVERSITY_VALIDATORS Validator Client Diversity

Encouraging validators (including those run by pools) to use diverse combinations of consensus and execution clients reduces the impact of a bug in any single client software affecting a large portion of stake.

Countermeasure in place? ✔ Public and disclosable? ✔

MEV-driven Censorship or Transaction Reordering (MEV_CENSORSHIP_REORDERING)

Threat actors:
Threat Description

Actors in the MEV supply chain (searchers, builders, relays, proposers) prioritize, reorder, front-run, sandwich, or exclude transactions based primarily on the MEV profit they generate, rather than gas price alone or arrival time. This can lead to systematic censorship of certain transaction types (e.g., those interacting with sanctioned addresses) or unfair economic outcomes for users.

Impact

Users experience transaction delays or failures if their transactions are not profitable enough for builders/proposers. Certain applications or users may face censorship. Economic value is extracted from users via front-running/sandwich attacks. Undermines network neutrality.
CENSORSHIP_RESISTANCE
LEDGER_INTEGRITY
ASSET_SECURITY

CVSS
Base score: 6.5 (Medium)
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L

Counter-measures for MEV_CENSORSHIP_REORDERING

PROPOSER_BUILDER_SEPARATION Proposer-Builder Separation (PBS)

Separates the role of proposing a block header from constructing the block's payload, aiming to reduce the proposer's ability to directly censor or reorder transactions by relying on a competitive market of builders. (e.g., via MEV-Boost currently, enshrined PBS in future).

Countermeasure in place? ✔ Public and disclosable? ✔

ENCRYPTED_MEMPOOLS Encrypted Mempools Research

Research and development into techniques that hide transaction details until they are included in a block, reducing the potential for front-running and certain types of MEV extraction.

Countermeasure in place? ❌ Public and disclosable? ✔

CRLISTS_INCLUSION_LISTS Inclusion Lists / crLists (Future)

Proposed mechanisms where proposers commit to including certain transactions, potentially forcing builders to include them, thereby improving censorship resistance.

Countermeasure in place? ❌ Public and disclosable? ✔

LAYER_2_SCALING Utilize Layer 2 Solutions

Moving transaction execution to Layer 2 networks can reduce the MEV impact on the Layer 1 base chain and potentially offer different sequencing/MEV mitigation strategies.

Countermeasure in place? ✔ Public and disclosable? ✔

Critical Bug in Consensus/Execution Client Software (CLIENT_SOFTWARE_BUG)

Threat actors:
Threat Description

A severe bug in a widely used execution client (e.g., Geth) or consensus client (e.g., Prysm) leads to nodes crashing, failing to process blocks correctly, reaching incorrect consensus (forking), processing invalid state transitions, or exposing a denial-of-service vulnerability. If a bug affects clients representing >1/3 or >2/3 of the stake, it can halt finality or cause incorrect finalization.

Impact

Network stalls or fails to finalize. Potential chain split requiring social intervention. Validators using the faulty client may be slashed for incorrect attestations or inactivity. Significant disruption to DApps and users. Loss of confidence.
AVAILABILITY
LEDGER_CONSISTENCY
LEDGER_INTEGRITY
TRANSACTION_FINALITY

CVSS
Base score: 8.7 (High)
Vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:H

Counter-measures for CLIENT_SOFTWARE_BUG

CLIENT_DIVERSITY_ECOSYSTEM Maintain Client Diversity

Actively supporting and encouraging the use of multiple, independent implementations of both execution and consensus clients is the primary defense. If one client fails, the network can continue operating with others (provided no single client has supermajority stake).

Countermeasure in place? ✔ Public and disclosable? ✔

RIGOROUS_TESTING_AUDITS Rigorous Software Testing and Audits

Extensive unit testing, integration testing, fuzzing, formal verification (where applicable), and third-party security audits of client software before release.

Countermeasure in place? ✔ Public and disclosable? ✔

BUG_BOUNTY_PROGRAMS Bug Bounty Programs

Incentivizing security researchers to find and responsibly disclose vulnerabilities in client software.

Countermeasure in place? ✔ Public and disclosable? ✔

Protocol-Level EVM or Precompile Vulnerability (EVM_PROTOCOL_VULNERABILITY)

Threat actors:
Threat Description

An attacker discovers and exploits a fundamental flaw in the EVM specification, an opcode's implementation across clients, or a precompiled contract provided by the protocol. This could allow for bypassing intended execution semantics, causing state inconsistencies, denial-of-service via resource exhaustion (e.g., infinite loops not caught by gas limits), or unauthorized access/manipulation of contract state at the protocol level.

Impact

Potential for mass exploitation of smart contracts relying on the flawed component. Inconsistent state between different client implementations. Chain halt or requirement for an emergency hard fork to correct the state or patch the EVM. Massive loss of funds or locked assets.
SMART_CONTRACT_PLATFORM_INTEGRITY
LEDGER_INTEGRITY
AVAILABILITY
ASSET_SECURITY

CVSS
Environmental score: 9.1 (Critical)
Vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H

Counter-measures for EVM_PROTOCOL_VULNERABILITY

EVM_SPECIFICATION_RIGOR Rigorous EVM Specification and Testing

Maintaining a clear, unambiguous specification for the EVM and extensive test suites (e.g., Ethereum Tests) covering edge cases for all opcodes and precompiles.

Countermeasure in place? ✔ Public and disclosable? ✔

FORMAL_VERIFICATION_EVM Formal Verification Efforts

Applying formal methods to mathematically prove properties of the EVM specification and critical components.

Countermeasure in place? ❌ Public and disclosable? ✔

CLIENT_IMPLEMENTATION_TESTING Cross-Client Implementation Testing

Ensuring multiple client teams implement the specification correctly and consistently through shared test vectors and consensus tests.

Countermeasure in place? ✔ Public and disclosable? ✔

EVM_AUDITS_BOUNTIES Audits and Bug Bounties for EVM/Precompiles

Targeted security reviews and bug bounties focused on the core EVM and protocol-level contracts.

Countermeasure in place? ✔ Public and disclosable? ✔

Contentious Hard Fork or Governance Capture (GOVERNANCE_ATTACK_FORK)

Threat actors:
Threat Description

A powerful faction (e.g., large pools, influential developers, EF) pushes through a controversial EIP or protocol change via the off-chain governance process, leading to significant community dissent. Alternatively, disagreement on a critical issue results in a persistent chain split (hard fork) where portions of the community and validator set adopt incompatible protocol rules.

Impact

A permanent split of the Ethereum network, creating two (or more) competing chains with duplicated history but diverging futures (e.g., ETH/ETC split). Causes massive disruption, ecosystem fragmentation, confusion for users, potential replay attacks across chains initially, and loss of network effect and value. Could also lead to adoption of changes harmful to neutrality or decentralization if governance is captured.
LEDGER_INTEGRITY
LEDGER_CONSISTENCY
ASSET_SECURITY
DECENTRALIZATION

CVSS
Base score: 8.9 (High)
Vector:CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:H

Counter-measures for GOVERNANCE_ATTACK_FORK

OPEN_EIP_PROCESS Open Ethereum Improvement Proposal (EIP) Process

A publicly accessible process for proposing, debating, and refining protocol changes, allowing for broad community input and scrutiny.

Countermeasure in place? ✔ Public and disclosable? ✔

ROUGH_CONSENSUS_MODEL Rough Consensus and Running Code Model

Decisions are generally based on the rough consensus of the core developers, client teams, researchers, and the wider community, rather than formal voting. Requires demonstrated implementation feasibility.

Countermeasure in place? ✔ Public and disclosable? ✔

SOCIAL_LAYER_CONSENSUS Strong Social Layer and Community Cohesion

A strong, engaged community provides a check against unpopular or harmful changes and facilitates coordination to maintain a single canonical chain.

Countermeasure in place? ✔ Public and disclosable? ✔

CLIENT_TEAM_INDEPENDENCE Independence of Client Teams

Having multiple independent client teams provides checks and balances, as widespread adoption of a change requires buy-in from several teams.

Countermeasure in place? ✔ Public and disclosable? ✔

Requests For Information

    Operational Security Hardening Guide

    SeqCountermeasure Details

    Testing guide

    This guide lists all testable attacks described in the threat model

    SeqAttack to testPass/Fail/NA

    Keys classification