How to Maximize Diversification and De-Risk Your ETH Staking Operations

We are often asked about the implied security benefits of diversifying across multiple staking providers. We took a deep dive into how to maximize the benefits of diversification, since engaging multiple staking providers may not actually achieve true diversification. While spreading your stake across several providers addresses counterparty risk, doing so doesn’t automatically protect from the deeper, protocol-level risks inherent in staking. True resilience requires looking at the operational diversity within each provider you select. The following provides a framework for evaluating those layers of risk mitigation.

A Framework for Evaluating Diversification

The ETH staking landscape has matured, but so have the operational, regulatory, and performance risks. As institutional token holders like Exchange Traded Products (ETPs) begin to incorporate ETH staking, there’s immense pressure on compliance teams to get staking risk management right.

Institutions need a framework for evaluating providers that goes beyond performance claims. Ethereum’s resilience is built on a foundation of diversity across its software, infrastructure, and operators. Understanding how to achieve true diversification is critical for managing risk and meeting compliance obligations, and the standard institutional approach to risk management often involves engaging multiple vendors. But what does effective diversification truly mean in the context of protocol staking?

This article provides a framework for how to properly evaluate and diversify staking risk, so you can look beyond surface-level metrics to reduce risk, optimize rewards, and maintain institutional trust.

Why Validator Diversity Matters

Diversifying across multiple providers may seem like a logical first step for any institution. Strategic operator diversity is a cornerstone of traditional risk management, designed to mitigate counterparty risk, avoid single points of failure, and ensure operational continuity.

Onchain, this principle extends to protecting the network itself:

• Network security: Reduce the impact of single-point failures or attacks.
• Censorship resistance: Broader client, geography, and operator diversity protects Ethereum’s neutrality.
• Performance stability: Avoid correlated downtime or reward volatility when providers or geographies fail.

While spreading your stake across several providers addresses counterparty risk, it doesn’t automatically protect you from the deeper, protocol-level risks inherent to staking. True resilience requires looking at the operational diversity within each provider you select.

The Layers of an Effective ETH Staking Diversity Strategy

Layer 1: Client Diversity and Concentrated Points of Failure

Every staking provider runs client software that allows their validators to communicate with the Ethereum network. If all of your chosen providers use the same dominant client software, your portfolio could be exposed to a single point of failure across all providers.

• The Risk: Today, over 45% of all Ethereum validator nodes are running Geth Execution Layer client software, and over 42% are running Lighthouse Consensus Layer client software. Relying on a single client implementation significantly increases the risk of correlated slashing if that client encounters a bug, especially at higher levels of concentration across the network.
• What to Look For: A provider that actively supports multiple clients, monitors client performance and concentration, and is consistently testing the performance of new client implementations. This demonstrates operational maturity and insulates your stake from a client monoculture event.

For more information on Ethereum’s staking architecture, visit our docs site.

Layer 2: Infrastructure and Geographic Diversity

Real infrastructure resilience goes beyond a simple data center map. It comes from a multi-layered strategy that protects against outages and instability across geographic regions and cloud providers.

• The Risk: If your providers all host their infrastructure in the same cloud region (e.g., AWS us-east-1), a cloud provider outage will take them all offline simultaneously, putting your staking portfolio at risk. Similarly, a broad geographic outage, caused by something like an earthquake, can take all providers offline that aren’t sufficiently distributing their node operations globally.
• What to Look For: A provider that distributes validators across different geographic jurisdictions and utilizes a mix of premier cloud services and bare-metal servers. This ensures no single point of failure can compromise your entire staking operation. When operating across multiple staking providers, an institution can request data to track its node distribution across regions, cloud services, and server types, though this data can be challenging to gather independently onchain.

Layer 3: MEV and Relay Diversity

A provider’s strategy for Maximal Extractable Value (MEV) is a direct indicator of their approach to risk, performance, and compliance. Running a diverse set of relays is important to maximize order flow exposure and ultimately rewards, but providers often diversify by adding non-compliant relays, exposing stakers to compliance and performance risk.

• The Risk: Not choosing a provider who runs compliant and high-performing relays. Some MEV relays are “OFAC-compliant,” meaning they actively filter blocks to exclude transactions involving addresses on the U.S. Treasury’s sanctions list, while other relays remain non-censoring. Choose a provider that selects the highest performing MEV strategy while retaining compliance.
• What to Look For: A provider that actively curates and transparently connects to a diverse set of strictly OFAC-compliant relays based on quantifiable data like win rates, latency, and reliability, balancing reward optimization and alignment with your company’s compliance needs. To manage across providers, an institution can perform diligence on each provider’s MEV strategy, which is often proprietary. Aggregating this data to understand the portfolio’s overall exposure to certain relays or censorship policies is one institutional strategy to ensure resilience across providers, but it can lack real-time visibility into a shifting landscape.

Layer 4: Risk Philosophy and Configuration

Every staking provider makes a choice: favor marginal uptime to maximize rewards, or prioritize safety by going briefly offline. This philosophical choice has tangible consequences, as every provider is subject to the same underlying protocol risks while operating as an agent on the Ethereum network—whether that’s slashing conditions, network-level downtime, or a bug in the core code governing block validation.

• The Risk: A provider focused solely on maximizing uptime might use aggressive failover systems. During network instability, this can easily lead to a double-signing event—the most severe and costly type of slashing penalty. While a non-custodial model contains the existential risk of an operator failing, the more pressing, day-to-day risk lies in these infrastructure choices that dictate performance and slashing mitigation.
• What to Look For: A provider with a stated failover philosophy like Figment’s “safety over liveness” approach. Prioritizing safety over liveness means that the provider deliberately chooses to be briefly offline (forgoing a negligible amount of staking rewards) to protect your overall stake from catastrophic loss. This isn’t a lack of performance; it’s a risk-managed strategy. A robust slashing coverage policy can provide an additional layer of protection against any penalties incurred from downtime or double-signing events. When managing across multiple providers, an institution should perform technical due diligence into each provider’s architecture, incident response plans, and slashing cover programs.

Layer 5: Custody and Contained Risk

Beyond operational choices, the fundamental structure of your staking relationship is a critical layer of risk management. The custody model determines who ultimately controls the assets and defines the boundaries containing your staking provider risk.

• The Risk: The ultimate risk in any arrangement with a staking provider is the loss of staked principal. Losing access to manually withdraw one’s staked ETH could stem from a provider becoming insolvent, acting maliciously, or ceasing operations. However, the severity of this risk is entirely dependent on the staking custody model.
• What to Look For: A non-custodial staking model where the customer retains exclusive control over the withdrawal keys, while the provider only manages the signing keys. This is a crucial distinction. As long as the staking operation is non-custodial, you can always exit the relationship and withdraw your tokens, subject to the Ethereum protocol’s exit queue. This structure ensures the provider can never access or transfer your principal, effectively containing the existential risk of using a sole provider. Staking with a non-custodial provider allows your due diligence to focus on what matters most for day-to-day staking performance and safety: the operational quality and risk philosophy detailed in Layers 1-4. Custodial diligence can be resourced through a trusted regulated custodian, or through an institution’s own custody protocols, such as using MPC-based signing or multisig operations. If your stake is distributed across multiple staking providers, but some are custodial, the benefit of the provider diversity is mitigated by the risk of losing access to that custodial stake.

A Better Framework for Resilience: Managing the Operational Layers

The truth is, staking resilience isn’t about the number of providers you use. Staking resilience is about choosing a provider that maintains underlying operational diversity within a responsive framework for assessing and diversifying staking risk, providing deep, multi-layered diversity.

Evaluating a provider’s risk philosophy requires technical due diligence into their architecture and incident response plans. Managing multiple providers means managing different, potentially conflicting, risk philosophies, which significantly complicates oversight. Institutional risk teams managing staking across multiple providers must reconcile different uptime metrics, fee structures, and communication channels, multiplying the operational burden on risk and compliance teams, creating new vectors for error and complicating oversight.

While it’s possible for an institution to manually manage these workflows across multiple providers, the operational reality is complex. Monitoring client distribution, tracking geographic and cloud infrastructure, and vetting MEV strategies across multiple providers requires significant, specialized internal resources.

The most effective approach is to work with a partner that has already engineered this deep diversification across all risk layers into its core infrastructure. Instead of focusing on adding more providers, your due diligence and risk mitigation can focus on the internal diversity of a single, expert provider, evaluating factors like their client diversity, geographic and infrastructure diversity, relay diversity, custody model, and safety-first infrastructure configuration.

Putting the Framework into Practice with Figment

Figment was built to solve this complexity, providing institutions with a single, deeply diversified staking partner that addresses every layer of risk from the ground up. Our approach focuses on providing institutional clients with verifiable, multi-layered internal diversification built on a foundation of operational excellence.

• Multi-Client Architecture: Figment’s multi-client architecture is a core component of our strategy to de-risk exposure to a client monoculture. By actively maintaining a diverse set of clients for Ethereum, we help ensure both validator and network-level resilience.
• Redundant, Diverse Infrastructure: We operate a redundant infrastructure spread across multiple jurisdictions and a mix of premier cloud providers and bare-metal servers. This physical and digital diversification is designed to insulate our operations from single points of failure, ensuring high performance and security.
• MEV and Relay Strategy: Our MEV-Boost strategy for Ethereum uses strictly OFAC-compliant relays, designed to meet institutional compliance needs while maximizing resilience and access to network rewards.
• Enterprise-Grade Compliance Frameworks: Figment’s operational environment is SOC 2 Type II certified, providing independent validation of our security controls. Our operations include rigorous stress testing, controlled rollouts for any software updates, and constant performance benchmarking against the network to ensure peak performance and stability.
• 0 Double-Signing Slashing Incidents: Our ‘safety over liveness’ philosophy directly informs our infrastructure design, prioritizing the security of staked assets over chasing marginal uptime. This deliberate, risk-managed approach is reflected in our track record because Figment has never experienced a double-signing slashing event on Ethereum.

Ultimately, effective risk management in staking requires looking past surface-level metrics like the number of providers. By focusing your diligence on the critical layers of diversity, including client, geography, relay, and risk philosophy, you can select a partner that provides genuine, built-in resilience and allows you to stake with confidence.