Measuring Solana's True Decentralization from a Data Perspective
TechFlow Selected TechFlow Selected
Measuring Solana's True Decentralization from a Data Perspective
This report analyzes Solana's decentralization using a quantitative and multifaceted approach based on facts and publicly verifiable information.
Navigating Web3 tides with focused insightsAuthor: Lostin, Helius
Translation: Yangz, Techub News
Executive Summary
-
As of Epoch 685, Solana has 4,514 nodes, including 1,414 validators and 3,100 RPCs. No single validator controls more than 3.2% of staked SOL.
-
The Nakamoto Coefficient (NC) represents the minimum number of independent entities that could collude maliciously to compromise validity or prevent consensus on new block production. Solana’s NC is currently 19, though the actual number may be lower since a single entity can anonymously operate multiple validators.
-
Solana validators are distributed across 37 countries and regions. The largest concentration is in the United States, with 508 validators. Additionally, four jurisdictions each account for over 10% of stake share: the U.S. at 18.3%, the Netherlands and the UK both at 13.7%, and Germany at 13.2%.
-
68% of stake is delegated to validators based in Europe, with 50.5% going to validators within the EU (excluding Norway, Ukraine, and the UK). Another 20% is delegated to North America.
-
Validators are spread across 135 different hosting providers. Teraswitch and Latitude.sh (formerly Maxihost) are the two leading providers—Teraswitch, a U.S.-based private company providing hosting services, holds a combined 24% share; Latitude.sh, a Brazilian provider offering low-cost bare-metal servers, holds 19%.
-
The Agave client codebase has 357 individual contributors. The Firedancer client, led by Chief Scientist Kevin Bowers, is being developed by a small team and currently has 57 contributors.
-
The Jito client is a fork of the original Agave codebase featuring an off-protocol blockspace auction and currently dominates the network with 88% market share. However, this landscape is expected to shift significantly within the next 12 months as the new Firedancer client is gradually introduced and integrated into the ecosystem. Solana and Ethereum are currently the only L1s offering multiple client implementations.
-
Major changes to Solana’s core components require formal, public Solana Improvement and Development (SIMD) proposals. The most significant protocol changes, especially those affecting economic parameters, undergo governance voting. To date, three such votes have been conducted.
-
The Solana Foundation was established in June 2019 as a non-profit organization registered in Switzerland, dedicated to growing and supporting the Solana ecosystem. The foundation operates with a lean team of 60–65 full-time employees responsible for overseeing funding sources for grants, delegation programs, and developer tools.
-
Furthermore, the geographic diversity of the Solana developer community is strongly demonstrated. The recent “Radar” hackathon attracted 13,672 participants from 156 countries, with high engagement from India, Nigeria, the U.S., and Vietnam. SuperTeam, a network connecting Solana creators, developers, and operators, has expanded to 1,300 members across 16 countries.
Why Decentralization Matters
Decentralization can be summarized as the absence of single points of failure within a system. This multi-faceted concept spans various dimensions, including token distribution, influence of key individuals, permissionless participation in the network, control over development, and software/hardware diversity. Beyond Balaji's Nakamoto Coefficient, there are almost no universally accepted standards for quantifying blockchain decentralization. Many metrics are imperfect. Moreover, discussions around blockchain decentralization often stem from political philosophy and can lead to deep ideological debates, sometimes bordering on religious fervor.
Solana’s level of decentralization has been criticized by certain blockchain communities who argue it lacks true decentralization and censorship resistance. A recent example is former NSA whistleblower Edward Snowden, who voiced concerns during a keynote speech at Token2049.
However, like many critics of Solana, Snowden did not provide any data to back his claims, despite being publicly invited to do so. In the following sections of this article, we will analyze Solana’s decentralization through data, highlighting areas where the network demonstrates relatively strong decentralization while identifying areas needing further progress.
Dimensions of Decentralization
Through this report, we will take a quantitative and multi-dimensional approach to analyzing Solana’s decentralization, grounded in facts and publicly verifiable information.
We will assess the following aspects:
-
Stake distribution
-
Geographic distribution of nodes
-
Diversity of hosting providers
-
Client software diversity
-
Developer diversity
-
Governance processes and entities
Where appropriate, we will compare Solana’s metrics with other PoS L1s. It should be noted that peer networks serve only as benchmarks, providing broader context for Solana’s decentralization journey and highlighting areas where it may lag behind or exceed expectations. These comparisons should not be interpreted as attempts to claim one network is superior to another.
In many cases, Ethereum provides the most useful benchmark, widely regarded as the most decentralized PoS L1. Notably, Ethereum’s genesis block was produced in July 2015, whereas Solana’s was in March 2020. Decentralization is dynamic, and blockchains typically become more decentralized over time. All else being equal, older chains would reasonably be expected to exhibit higher levels of decentralization.
Stake Distribution
Stake distribution on a blockchain network refers to how the network’s native tokens are allocated among validators. In a well-distributed system, no single validator or small group holds an excessive share of stake, reducing the risk that any entity gains undue influence or control over network consensus.
Balanced stake distribution ensures validator diversity, promoting decentralization and making it harder for any malicious actor to compromise the network’s integrity. As the network becomes more resilient to individual validator failures, fault tolerance also improves.
“You need a very large validator set. Intuitively, the larger the validator set, the more secure the network. Academically, the larger the node set, the easier it is to guarantee that even a minority of honest nodes in the set always has access to a minimal spanning tree. This isn’t even about the protocol layer—it’s about people talking on the phone. In fact, people can go on Discord or IRC, or call each other on their phones. And that’s how we solve splits, figure out what went wrong. The more people we have, the easier it is to guarantee that splits are impossible.” — Anatoly Yakovenko, Breakpoint 2024
Running a node on Solana is fully permissionless, requiring only a minimal mandatory stake (1 SOL) to operate as a validator. The network natively supports delegated Proof-of-Stake (dPoS), consisting of 4,514 nodes, including 1,414 validators and 3,100 RPC nodes.
The two largest validators by stake are operated by Helius and Galaxy, each holding approximately 3.2% of total stake. The minimum delegated stake required to enter the top third and top two-thirds of validators is 4.4 million and 1.23 million SOL, respectively.
For clarity, the chart below groups validators by delegated stake. Among them, 82 validators (5.87% of the total) hold over 1 million delegated SOL; 825 validators (59.1%) hold less than 50,000 delegated SOL, most of whom participate in the Solana Foundation Delegation Program (SFDP), designed to help smaller validators achieve sustainability quickly. Approximately 72% of Solana validators benefit from SFDP support, collectively accounting for 19% of total stake. For an in-depth analysis of SFDP, refer to our earlier Helius report: “SFDP and Challenges Facing Long-Tail Validators.”
Just as blockchain addresses do not equate to users, the number of validators does not reflect the true number of distinct entities operating them. Since large entities may choose to distribute their stake across multiple validators, the real number is likely lower. For example, Jito (1,2), Coinbase (1,2), and Mrgn (1,2) all operate multiple validators.
There is nothing inherently problematic about a single entity operating multiple validators; in fact, if these validators are geographically and provider-diverse, they can strengthen the network. However, risks arise if these validators use identical configurations or non-standard firewall rules. Additionally, the "validator-as-a-service" model, where one entity manages numerous validators on behalf of large companies or projects, may introduce further centralization concerns.
Nakamoto Coefficient
In proof-of-stake networks, the Nakamoto Coefficient (NC) represents the minimum number of nodes required to control at least one-third of the total stake. A higher coefficient indicates broader stake distribution and greater decentralization. It can also be interpreted as the minimum number of independent entities that could collude maliciously to cause validity failure and prevent consensus on new block production. Blockchains based on PoS and Byzantine Fault Tolerance require over two-thirds of staked nodes to agree on the network state to continue processing transactions.
To determine Solana’s NC, we ranked validators by stake share from highest to lowest and calculated how many were needed to control one-third of total stake. The result shows that Solana’s NC peaked at 34 on August 13, 2023, and is currently 19. The coefficient has remained relatively stable over the past year.
In comparison, Ethereum exhibits a similar stake distribution pattern but with a higher concentration in North America at 34.4%.
Solana Validators by Country and Region
Solana validators are spread across 37 different countries and regions. The largest concentration is in the United States, with 508 validators (37%) running in U.S. data centers, followed by the Netherlands with 112 (8%) and Russia with 111 (8%).
Geographic Distribution of Solana Validators by Stake Share
When measured by stake share, the distribution is more balanced. Four major jurisdictions each account for over 10%: the U.S. at 18.3%, followed by the Netherlands and the UK at 13.7% each, and Germany at 13.2%.
In contrast, Ethereum nodes are distributed across 83 countries, with nearly half located in the U.S. and Germany.
Top 10 Cities by Number of Solana Nodes and Stake Share
A more granular analysis of validator and delegated stake distribution by city reveals that Solana validators operate across 121 cities globally.
In the U.S., validators are distributed across all major regions, spanning 35 cities. The most popular cities are Chicago (124 validators, 2.3% stake share), Los Angeles (57 validators, 2.3% stake share), and New York (32 validators, 3.5% stake share).
Earlier this year, Anza employee Rex St.John proposed strategies to improve geographic diversity among Solana validators—particularly by expanding support for operators in the Global South—and identified several key challenges:
-
High latency: Nodes in remote areas struggle to stay synchronized with the network
-
Bandwidth costs: Bandwidth is extremely expensive in some regions
-
Regulatory restrictions: Legal frameworks in different jurisdictions limit the feasibility of operating blockchain infrastructure
-
Underdeveloped infrastructure: Insufficient network and data center infrastructure
-
Unfavorable taxes and tariffs: High hardware equipment costs
-
Talent shortage: Lack of local Solana expertise and limited access to capital required for staking
Hosting Providers
Ideally, the validator set should be hosted across multiple independent providers rather than relying heavily on a few centralized ones. Such diversification is crucial to mitigate risks associated with any single provider experiencing outages or censorship.
A notable incident in 2022 involved German hosting provider Hetzner, which unexpectedly removed Solana validators from its services, causing over 20% of active staked nodes (around 1,000 validators) to go offline for several hours. Nevertheless, Solana continued operating fully without any failure. Most affected validators successfully migrated to new data centers within days, and nearly all staked nodes came back online within weeks.
Solana Validator Hosting Providers by Stake Share
Solana validators are distributed across 135 different hosting providers, led by Teraswitch and Latitude.sh (formerly Maxihost). Teraswitch, a privately held U.S. company, hosts 24% of validators, while Latitude.sh, a Brazilian low-cost bare-metal server provider, hosts 19%. Together, these two providers account for 43.4% of total stake.
Other popular hosting providers include French cloud computing company OVHcloud (8.65% share) and Lithuania-based Cherry Servers (8.45% share).
Solana Validator Hardware Requirements
As a high-performance, high-throughput blockchain, Solana imposes higher node requirements than most industry peers. Recommended hardware specifications for Solana validators include the following key components:
-
CPU: 24 cores / 48 threads or higher, base clock speed of 4.2GHz or faster
-
Memory: 512 GB
-
Disk: PCIe Gen3 x4 NVMe SSD or higher, 2TB aggregate or larger. High TBW
-
No GPU requirement
In practice, Solana’s bandwidth demands make home operation impractical, so validators are primarily run on bare-metal servers in dedicated data centers.
Solana Client Diversity
At launch, Solana had only one validator client, developed by Solana Labs and written in Rust. While Solana Labs’ client is no longer actively updated, a fork called Agave remains in use. Relying solely on a single client implementation is a major point of centralization, as it introduces the risk of critical software bugs leading to network-wide validity failure.
Increasing client diversity has long been a priority for the Solana community, and this goal is now being realized with the introduction of Firedancer.
Solana Clients
Currently, multiple Solana client implementations are either operational or under development:
-
Agave: A fork of Solana Labs’ original client, written in Rust and maintained by Anza, a Solana software development company.
-
Firedancer: Fully rewritten in C, maintained by Jump Crypto.
-
Frankendancer: A hybrid validator combining Firedancer’s networking stack and block production components with Agave’s execution and consensus layers.
-
Jito: A fork of the Agave client built by Jito Labs, introducing an off-protocol blockspace auction that offers validators additional economic incentives via tips.
-
Sig: A read-optimized Solana validator client written in Zig by Syndica.
Additionally, Mithril is a Golang-written client developed by Overclock, usable as a full node with lower hardware requirements.
Having multiple full-time core engineering teams independently reviewing codebases greatly increases the likelihood of catching bugs while fostering knowledge sharing and collaboration. Anza engineer Joe Caulfield noted in a recent interview: “We’ve learned a lot from the Firedancer client team; they’ve come up with many clever solutions.” Both Agave and Firedancer have launched bug bounty programs.
Solana Client Diversity vs. Ethereum
Solana and Ethereum are the only L1s currently offering multiple client implementations. Ethereum has at least five major software clients. The most widely adopted are Nethermind (written in C) with 45% usage, and Geth (written in Go) with 39%.
On Solana, the Jito client currently accounts for 88% of staked nodes. However, this landscape is expected to change significantly within the next 12 months as new clients (Frankendancer and Firedancer) are gradually introduced and integrated.
Developer Decentralization
In “Quantifying Decentralization,” Balaji argued that developer decentralization is a critical factor in blockchain ecosystems, emphasizing the importance of minimizing reliance on individual contributors and reducing “key person risk.”
All core client software on Solana is publicly hosted on GitHub under open-source licenses, allowing open access and community contributions.
The Agave validator client, maintained by Anza—a software development company founded in early 2024—plays a significant role in this area. Anza launched with around 45 employees, roughly half of Solana Labs’ former workforce. In addition to managing Agave, the Anza team contributes to the broader Solana ecosystem through projects such as token extensions, cross-border payment infrastructure, and Solana permissioned environments.
Number of Contributors to the Agave Client Codebase
The Agave client codebase has 357 contributors and 26,408 commits. However, raw commit counts alone are imperfect and do not fully reflect the depth of individual contributions. Notably, the majority of commits are authored by a small group of developers, primarily senior engineers and Solana co-founders, followed by a long tail of minor contributors.
In comparison, popular Ethereum clients Geth and Nethermind show similar patterns of contributor “centralization” across larger communities. Geth has 1,098 contributors, Nethermind has 142. Over half of Geth’s commits are attributed to just three core contributors, while two developers account for over 50% of all Nethermind commits.
Number of Contributors to the Firedancer Client Codebase
The Firedancer client is developed by a small team led by Kevin Bowers of Jump, a renowned U.S. high-frequency trading firm, and currently has 57 contributors and 3,722 commits. Given that Firedancer is a relatively new project (first commit dates to August 2022) and only recently launched on mainnet, contributor diversity remains limited.
Solana Ecosystem Developers
Within the broader Solana ecosystem, the geographic diversity of the developer community is undeniable. Solana’s biannual virtual hackathons are among the most participated events globally and have played a crucial role in nurturing today’s most successful Solana protocols and application teams—including Tensor, Drift, Jito, and Kamino.
The recent “Radar” hackathon attracted 13,672 participants from 156 countries, with particularly strong representation from India, Nigeria, the U.S., and Vietnam.
Additionally, SuperTeam, a network connecting Solana creators, developers, and operators, has grown to 1,300 members across 16 countries. Its localized chapters promote collaboration through events and shared workspaces. Step Finance’s Solana Allstars ambassador program has seen great success in Nigeria, hosting over 120 meetups across many regions with consistently high attendance.
Governance
Governance is a key vehicle for decentralization, as it determines how decisions are made within the network. This affects everything from protocol upgrades to economic policies and community rules. Decentralized governance enhances transparency, fairness, and trust in the network.
Governance Voting and SIMD
Solana Improvement and Development (SIMD) proposals are formal documents required for any substantial changes to Solana’s core components. “Substantial” changes are defined as those that typically alter network protocol, transaction validity, or interoperability. Non-substantial changes, such as minor code refactoring or objective performance improvements, do not require proposals.
While submitting a SIMD requires no permission—any developer or researcher can submit—most SIMDs are authored by client team developers who work full-time on core protocol improvements.
SIMD proposals fall into two categories:
-
Standard proposals: Affect core Solana functionalities such as consensus, networking, and API interfaces
-
Meta-proposals: Address processes or guidelines outside the codebase
SIMD Process
SIMDs typically go through stages of idea review, drafting, review, and acceptance. Formal reviews occur publicly on GitHub, with proposal authors responsible for gathering feedback from relevant core contributors, who decide whether to accept, modify, or withdraw the proposal. Authors are not obligated to implement their proposals, although it is generally recommended, as this is the best way to ensure successful completion.
If a proposal is accepted, it usually includes a related feature implementation tracking issue and may require activation via Solana’s feature-gate mechanism. Feature gates activate first on Testnet according to time-bound criteria, then on Devnet, and finally on Mainnet.
Discussions about improvements take place in the following areas:
-
SIMD (Solana Improvement Documents) GitHub repository
-
sRFC (Solana Request for Comments) section on the official Solana forum
-
Solana Technical Discussion Zone
-
Social channels, including X (formerly Twitter) and Telegram
Solana Governance Voting Process
SIMDs that involve significant protocol changes, especially those affecting economic parameters, undergo governance voting. The Solana governance voting process is a relatively new initiative pioneered by long-standing members of the validator community, focusing only on critical issues to maintain engagement and avoid governance fatigue.
To date, three such votes have been conducted:
-
First advisory vote in October 2023 (14.3% of staked nodes participated)
-
April 2024 vote on timely voting credits (SIMD33) (53% of staked nodes participated)
-
May 2024 vote on paying validators full priority fees (SIMD96) (51% of staked nodes participated)
Voting is conducted by depositing tokens into designated accounts for each validator identity, with the number of voting tokens received proportional to their active stake share in lamports.
To vote, validators must transfer tokens to one of several designated public keys corresponding to voting options (including abstention). Once cast, votes cannot be changed.
In this structure, SOL token holders participate indirectly by delegating their SOL to validators whose voting choices align with their values or preferences.
Governance Benchmarking
According to a benchmark report released earlier this year by CCData, among the top 40 digital assets evaluated under Environmental, Social, and Governance (ESG) criteria, Solana is one of only four rated AA. In governance scoring, Solana ranks fourth among L1s, assessed on factors including stakeholder engagement, transparency, and decentralization.
Solana Foundation
The Solana Foundation (SF) was established in June 2019 as a non-profit organization registered in Switzerland, dedicated to the decentralization, adoption, and security of the Solana ecosystem. SF began with an initial endowment of 167 million SOL tokens and oversees funding sources for grants, delegation programs, and developer tools. It controls official brand assets, social media accounts, websites, and trademarks.
Currently led by Executive Director Daniel Albert and President Lily Liu, SF operates with a lean team of 60–65 full-time employees, overseen by a foundation board.
The foundation’s mission is to build a scalable, self-sustaining Solana ecosystem, with a focus on education, research, and ecosystem development programs. SF organizes large-scale Solana events, including Hacker Houses and the annual Breakpoint conference, to foster developer engagement and community building.
SF’s developer relations team maintains official documentation, social channels, and developer education. In January 2024, SF transferred management of its flagship hackathon to Colosseum, a new independent accelerator co-founded by former SF growth lead Matty Taylor.
Dan Albert noted in a recent debate: “Our job is to make ourselves obsolete—find scalable ways to support the network and ecosystem, then step away.” This reflects SF’s long-term goal of building a self-sustaining network that functions without oversight.
Conclusion
As shown in this report, Solana’s decentralization compares favorably with industry peers—and in many key metrics, surpasses them—particularly in areas such as Nakamoto Coefficient, geographic distribution of validators and staked nodes, developer decentralization, and governance benchmarks. Client diversity remains a notable weakness, one that the new Firedancer client aims to address.
To further strengthen Solana’s decentralization, the following measures could be considered:
-
Explore distributing SF responsibilities across multiple organizations
-
Increase transparency around foundation spending and grant allocations
-
Launch initiatives like “Solana Nations” to enhance geographic diversity
-
Reduce the largest expense for validator operators—voting costs
-
Explore strategies to reduce validator data egress requirements; data egress costs are significantly higher for operators outside the EU and U.S.
-
Encourage more active participation in governance voting
-
Expand Solana’s core contributor and research community to strengthen network development
Currently, Solana’s validator set remains somewhat concentrated in the U.S. and EU and relies on a limited number of hosting providers. While this challenge is not unique to Solana, it highlights opportunities for improvement in reducing centralization at this level.
Finally, we thank Overclock, Amira Valliani, Matt Sorg, Yelena Cavanaugh, Dan Albert, Tim Garcia, 0xIchigo, Anatoly Yakovenko, and Brady Werkheiser for reviewing earlier versions of this article.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@heliuslabs
