Q2 2026 Solana Validator Performance Report

In Q2 2026, Coinbase's Solana validators delivered higher rewards and more reliable performance than the network average, while running only Solana Foundation-aligned software and maintaining our risk-adjusted operating posture:

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:

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 Solana scheduler landscape diverged in Q2. 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 strategies that are aligned with Solana Foundation.

Our production fleet currently includes:

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.

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 Q2 2026.

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.

We introduced Alpenglow in last quarter's report: the ground-up rewrite of Solana's consensus that cuts finality from roughly 12.8 seconds to 100 to 150 milliseconds, using Rotor for block propagation and Votor for certificate-based voting that removes per-slot vote transactions. This quarter the story is less about what Alpenglow is and more about getting ready to run it.

Running it in a live setting. We operate a validator on the Solana community cluster, the closest thing to an Alpenglow test network available today, and have kept it current through the cluster's periodic resets as the software moved onto the mainline Agave client. A live node surfaces the operational edge cases that only show up under real consensus, so we can work through them well ahead of mainnet.

Instrumenting consensus health. Alpenglow changes what a healthy validator looks like, and the existing monitoring does not carry over cleanly. Because Votor moves voting off-chain into aggregated certificates, the vote-rate metrics the industry has relied on for years no longer map to reality: a node can read low on the old metric while it is in fact voting on the first round and finalizing on the fast path. We have built first-party telemetry for the Alpenglow voting path and are redesigning our participation and consensus-health monitoring around the new model. Getting this right before mainnet is what lets us run Alpenglow with the same confidence we run the network today.

Preparing the fleet. We have validated the vote-account changes Alpenglow requires, including the new validator voting keys, so our validators can adopt the upgrade without disruption. We also stay in close coordination with the Solana Foundation as the rollout approaches mainnet. Doing this work now means that when Alpenglow reaches mainnet, targeted for later in 2026, the switch will be a routine upgrade for our validators and the customers who stake with us.

One thread ties back to earlier in this report: with finality measured in milliseconds, well-connected and reliable infrastructure matters more, not less. A validator that propagates and finalizes quickly helps the whole network reach its fast path. The DoubleZero work mentioned in our Q1 report is part of the same preparation.