Validator Beat 2026 Survey

Part 1: Organization Profile

1.Organization Name:

2.Total Ethereum Validators Operated

Part 2: Client Diversity (Correlation Risk)

3.Consensus Layer (CL) Concentration: What percentage of your total validators run on your most-used CL client?

< 33%

34% – 66%

67% – 90%

more than 90%

4.Execution Layer (EL) Concentration: What percentage of your total validators run on your most-used EL client?

< 33%

34% – 66%

67% – 90%

more than 90%

Part 3: Infrastructure & Geography

5.Cloud/Hosting Concentration: What percentage of your total validators rely on your largest single hosting provider (e.g., AWS, GCP, a specific Bare Metal provider)?

< 33%

34% – 66%

67% – 90%

more than 90%

6.Geographic Concentration: What percentage of your total validators are hosted in your largest single geographic region (e.g., US-East, Europe-Central)?

< 33%

34% – 50%

51% – 75%

more than 75%

Key Security & Organization Independence

7.DVT Adoption: What percentage of your organization's active validators are currently secured using Distributed Validator Technology (DVT)?

8.For the validators in your organization not utilizing public DVT networks (e.g., Obol, SSV), what is your primary signing architecture?

Local Keystore (Standard): Keys reside in software directly on the active Validator Client machine.

Standard Remote Signer: Keys are isolated in a dedicated service (e.g., Web3Signer), but stored as software keys.

Hardware / Cloud Enclave: Keys are non-exportable and secured within Cloud KMS (AWS/GCP), Intel SGX enclaves, or physical HSMs.

High-Availability Decoupled Architecture (e.g., Vouch): Multi-node validator clients routing to redundant remote signers, backed by distributed, highly available slashing protection databases.

Proprietary MPC / Internal Threshold: Custom multi-party computation or threshold signing setups maintained entirely in-house.

N/A (We are 100% DVT)

9.Threshold & DVT Independence: For any threshold, MPC, or DVT setups you operate, how are the key shares and signing nodes distributed operationally?

Single Entity (Localized): We hold all key shares; nodes operate within a similar infrastructure perimeter.

Single Entity (Geographically/Cloud Distributed): We hold all key shares, but actively distribute the cluster nodes across distinct cloud providers and regions for internal high availability.

Multi-Entity (Independent Co-Signers): Key shares are distributed across distinct, legally and operationally independent organizations.

N/A (We only operate single-signature setups)

Part 5: Institutional Resilience & Independent Assurance

10.Failover Safety Architecture: In the event of a primary node or datacenter failure, how does your infrastructure guarantee that a failover event will not result in a double-signing slash?

Manual Intervention Only: We do not use automated failover. We prioritize strict safety and accept temporary downtime until human verification is complete.

Time-Delayed Automated Failover: Backup nodes initialize automatically, but only after a strict, hardcoded epoch/time delay to reduce the risk of concurrent active signers.

Synchronized Slashing DBs (Active-Passive): Automated failover relying on a high-availability, synchronized state database (e.g., highly available Web3Signer setup + distributed consensus DB) to prevent concurrent signing.

Consensus-Driven Safety (DVT/Threshold): Failover is handled natively via distributed consensus; safety is cryptographically guaranteed because no single node can unilaterally produce a signature.

11.Active Independent Assurance: Which of the following recognized third-party assessments is your validator infrastructure currently and actively certified for? (Select all that apply)

2 / 1

200%

Validator Beat 2026

Mapping Decentralization Across Ethereum Operators