This article details our Solana validator performance, key validator characteristics, and changes that resulted in higher APY and more resilient operations. This report covers Q1 2026 performance and infrastructure changes for our Solana staking operations.
Our Solana Validators at a Glance
40.48M SOL staked (9.52% of total staked SOL) across validators distributed across 6 countries and 2 bare metal providers
Delivering a 7.02% APY (vs. network 6.95%) and a skip rate of 0.041% (vs. network 0.198%)
Supporting 5 validator clients (Harmonic, Jito, JitoBAM, Firedancer, and Rakurai) as primary or secondary
Security-first operations include double-signing protections, near zero-downtime deployments (ZDD), and capped stake concentration with a goal of moving all validators out of the superminority
Runs on 100% bare metal servers (AMD EPYC 9275F and 9575F)
Validator Distribution
Coinbase's Solana validators are distributed across multiple geographic locations to support network decentralization and reduce the risk of simultaneous failures if local outages occur. For redundancy and disaster recovery purposes, each validator has a corresponding backup server in a separate location.
We operate validators in:
Amsterdam, Netherlands
Frankfurt, Germany
London, United Kingdom
Dublin, Ireland
Singapore, Singapore
Tokyo, Japan

We also distribute our validators between two bare metal providers: TeraSwitch and Latitude. Across the production cohort, 13 validators run on TeraSwitch and 10 run on Latitude. Splitting between providers limits the blast radius of a single-provider outage and avoids single-provider concentrations.
The Evolving Scheduler Landscape
The Solana scheduler landscape diverged in Q1. We observed some market participants running several newer implementations that began prioritizing peak MEV extraction through aggressive timing strategies, often at the expense of the network end-users. All Coinbase-operated stake - including that delegated to community and customer validators - runs only Solana Foundation-aligned strategies.

Our production fleet currently includes:
Harmonic (75% of our fleet): Built on the Jito Agave codebase with Solana Foundation-aligned scheduler logic. Largest deployment by stake share.
Jito (21% of our fleet): Widely deployed MEV-aware client that is in production for multiple quarters and has delivered competitive performance.
JitoBAM (3.9% of our fleet): Brought online in Q1 to evaluate block-auction scheduling under production stake.
Rakurai (0.1%): a new validator client built on the Jito Agave codebase with a redesigned scheduler.
In addition, we support Firedancer as an alternative. It is an independent client built from the ground up to bring true client diversity and high-performance block production to Solana.
Multi-client architecture is part of our operational design. Our bare-metal infrastructure, internal tooling, and near-zero-downtime deployment system let us promote new clients, shift stake between production clients, and re-allocate across the fleet without service disruption. As the network continues to evolve through new consensus mechanisms, scheduler bindings, and protocol-level changes, this optionality becomes increasingly important.
Beyond production, Coinbase runs self-funded experimental validators to evaluate emerging validator clients and schedulers before deploying them to the production environment, ensuring customers have access to battle-tested, performant optionality.
Skip Rate
Validator skip rate measures the percentage of time a validator fails to produce blocks for assigned slots. Higher missed slots can lead to lower block rewards, reduced validator performance and reliability.
As indicated below, our skip rate was lower than the network average over Q1 2026.

Source: Firedancer Report API, Q1 aggregate per identity account.
(Near) Zero-Downtime Deployments
Our hot-swap deployment system delivers near-zero downtime for validator updates while eliminating double-signing risk. Strict preflight checks and key transition validations ensure identical key pairs are never active on more than one machine simultaneously. This mechanism is integrated with our existing double signing protection system.
Upcoming Developments
Alpenglow Upgrade
Alpenglow is a ground-up rewrite of Solana’s consensus layer with the explicit goal of reducing finality from 12.8 seconds to 100–150 ms - approximately 100x faster. It removes several legacy components and replaces Solana’s current finality model with fast, certificate-based finality. This pushes crypto settlement latency into a range that is comparable to traditional card authorization latency.
Alpenglow is built around two core components:
Rotor: a block propagation layer that improves how data moves through the network.
Votor: a lightweight, stake-weighted voting engine that streams single-packet votes and aggregates them into compact on-chain certificates, eliminating the need for per-slot vote transactions.
Finality is achieved through a concurrent two-path notarization model:
Fast finality: one-round finality when more than 80% of stake reaches consensus within 100 ms target window.
Slow finality: two-round finality when more than 60% of stake reaches consensus, with a 150 ms target.
By moving to fast, certificate-based finality and more efficient propagation, Alpenglow opens the door to broader architectural upgrades: easier parallelism, a clearer path toward multiple concurrent leader workflows, and support for asynchronous execution. Together, these changes could enable real-time settlement use cases across trading, payments, gaming, and other latency-sensitive applications.
DoubleZero
Solana's core philosophy of "increase bandwidth, reduce latency" (IBRL) can only be fully realized if it is addressed from multiple angles. One technology working on this is DoubleZero, which addresses latency at the network infrastructure layer. DoubleZero provides a fiber-based backbone that directly links data centers.
Validators connected to this network effectively "bypass" the traditional internet, with the goal of lower latency and more consistent throughput.
In advance of the Alpenglow upgrade, we have already integrated our Solana testnet validators with DoubleZero's testnet and are preparing for the upcoming mainnet launch. In addition to latency and throughput improvements, we see DoubleZero as a potential lever for geographic decentralization. Today, global validator distribution is clustered in Europe due to the region's favorable voting latency. This creates a self-reinforcing dynamic that makes it increasingly difficult for other regions to remain competitive. If widely adopted, DoubleZero could narrow the latency gap that currently makes non-European regions less viable for validator operators.





