Authors: Lostin, Helius
Compiled by: Yangz, Techub News
Summary
As of Epoch 685, Solana has 4,514 nodes, including 1,414 validators and 3,100 RPC. No validator controls more than 3.2% of the staking share.
The Nakamoto Coefficient (NC) represents the minimum number of independent entities that could collude maliciously to cause validity failure and refuse to reach consensus required for new block production. Solana's Nakamoto coefficient is currently at 19, but the actual number may be lower, as a single entity can anonymously operate multiple validators.
Solana validators are distributed across 37 countries and regions. The largest concentration is in the US, with 508 validators. Additionally, four jurisdictions each account for over 10% of the share, with the US at 18.3%, and the Netherlands and the UK at 13.7% each, and Germany at 13.2%.
68% of the stake is delegated to validators in Europe, with 50.5% delegated to validators within the EU (excluding Norway, Ukraine, and the UK). Additionally, 20% is delegated to North America.
Validators are distributed across 135 different hosting service providers. Among them, Teraswitch and Latitude.sh (formerly Maxihost) are two leading providers, with the former being a private US company providing hosting services for validators, accounting for 24% of the share; the latter is a Brazilian company providing low-cost bare-metal servers, accounting for 19% of the share.
The Agave client codebase has 357 individual contributors. The Firedancer client is developed by a small team led by Chief Scientist Kevin Bowers, currently with 57 contributors.
The Jito client is a fork of the original Agave codebase, incorporating an off-protocol block space auction, currently dominating the network with an 88% share. However, as the new Firedancer client is gradually introduced and integrated into the ecosystem, significant changes are expected in the next 12 months. Solana and Ethereum are currently the only L1s offering multiple client implementations.
Significant changes to Solana's core components require a formal and public Solana Improvement and Development (SIMD) proposal process. The most significant protocol changes, especially those affecting economic parameters, require governance voting. So far, three such votes have been conducted.
The Solana Foundation was established in June 2019 as a non-profit organization registered in Switzerland, dedicated to the development and support of the Solana ecosystem. The foundation's team is relatively lean, consisting of 60-65 full-time employees responsible for overseeing the funding sources for grants, delegation programs, and developer tools.
Furthermore, the geographical diversity of the Solana developer community has been strongly demonstrated. The recent hackathon event 'Radar' attracted 13,672 participants from 156 countries, with high participation from India, Nigeria, the US, and Vietnam. SuperTeam is a network connecting Solana creators, developers, and operators, and has now expanded to 1,300 members across 16 countries.
Why decentralization
Decentralization can be summarized as the absence of single points of failure within the system. This multi-faceted concept involves several aspects, including token distribution, influence of key individuals, participation in permissionless networks, development control, and software/hardware diversity. Aside from Balaji's Nakamoto coefficient, there are almost no recognized standards for quantifying the degree of decentralization of blockchains. Many metrics are imperfect. Furthermore, discussions around blockchain decentralization are often rooted in political philosophy, provoking profound ideological debates, sometimes even bordering on religious disputes.
Solana's degree of decentralization has been criticized by certain blockchain communities, which argue that Solana lacks decentralization and the ability to resist censorship. A recent example is former NSA whistleblower Edward Snowden, who expressed concerns during his keynote speech at the Token2049 conference.
However, like many critics of Solana, Snowden did not provide any data to support his claims, despite being publicly invited to do so. In the following sections of this article, we will analyze the decentralization of Solana using data, highlighting the aspects where the network has demonstrated relatively strong decentralization while pointing out areas where further progress is needed.
Various aspects of decentralization
Through this report, we will use facts and publicly verifiable information to analyze the degree of decentralization of Solana in a quantitative and multi-faceted manner.
We will evaluate the following aspects:
Staking distribution
Geographical distribution of nodes
Diversity of hosting service providers
Diversity of client software
Diversity of developers
Governance processes and entities
At the appropriate time, we will compare Solana's metrics with those of other PoS L1s. It should be noted that peer networks are only used as benchmarks to provide a broader context for Solana's decentralization journey and highlight areas where it may lag or exceed expectations. These comparisons should not be misconstrued as attempts to claim one network is superior to another.
In many cases, Ethereum provides the most useful benchmark as it is widely regarded as the most decentralized PoS L1. Notably, Ethereum's genesis block was produced in July 2015, while Solana's genesis block was produced in March 2020. Decentralization is dynamic, and blockchains often become more decentralized over time. Under similar conditions, it is reasonable to expect that older chains would have a higher degree of decentralization.
Distribution of staking
The staking distribution of 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 too much of the staking share, thus reducing the risk of any entity unduly influencing or controlling network consensus.
Balanced staking distribution ensures validator diversity, thereby promoting decentralization and making it difficult for any malicious actor to compromise the integrity of the network. As the network's ability to recover from individual validator failures improves, it also helps enhance fault tolerance.
"You need a very large set of validators. Intuitively, the larger the validator set, the more secure the network, and academically, the larger the node set, the easier it is to guarantee that a minimal spanning tree is always accessible among the few honest nodes in that set. This doesn't even refer to the protocol layer; it's about the conversations people have on the phone. In fact, people can enter Discord or IRC or call each other on their phones. And that's the key to solving the split problem and identifying issues. The more people we have, the easier it is to ensure that splits are impossible." — Anatoly Yakovenko, Breakpoint 2024
Running a node on Solana is completely permissionless, requiring only a very low mandatory minimum stake (1 SOL) to operate as a validator. The network natively supports delegated proof-of-stake (dPoS) with 4,514 nodes, including 1,414 validators and 3,100 RPC nodes.
By staking volume, the two largest validators are operated by Helius and Galaxy, each holding about 3.2% of the staking share. The minimum delegated stake required to enter the top third and top two-thirds is 4.4 million SOL 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% of the total) hold less than 50,000 delegated SOL, most of which participated in the Solana Foundation Delegation Program (SFDP), aimed at helping smaller validators achieve sustainable growth quickly. About 72% of Solana validators benefit from SFDP support, accounting for 19% of total staking.
Just as blockchain addresses do not equate to users, the number of validators does not reflect the true number of different entities operating validators. Large entities may choose to delegate their stake across multiple validators, thus the actual number is lower. For example, Jito (1,2), Coinbase (1,2), and Mrgn (1,2) operate multiple validators.
There is no inherent problem with a single entity operating multiple validators; in fact, as long as validators are distributed and not centralized, it can strengthen the network by enhancing regional and hosting service provider diversity. However, if these validators adopt non-standard settings or firewall rules for the same configuration, it could pose risks. Additionally, as part of the 'validator as a service' model, having one entity manage numerous validators on behalf of large companies or major projects could bring further decentralization issues.
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. The higher the coefficient, the broader the stake distribution and the greater the level of decentralization. Additionally, it can be considered the minimum number of independent entities that could collude maliciously to cause validity failure, thereby refusing to reach consensus required for new block production. Blockchains based on PoS and Byzantine Fault Tolerance require more than two-thirds of staking nodes to reach consensus on the network state to continue processing transactions.
To determine Solana's Nakamoto coefficient, we ranked validators by their staking share from high to low and calculated the number of validators required to control one-third of the total stake. The result was that Solana's Nakamoto coefficient reached a peak value of 34 on August 13, 2023, and is currently at 19. This coefficient has remained relatively stable over the past year.
In contrast, Ethereum's staking distribution is similar but with a higher weight in North America at 34.4%.
Solana validators classified by country and region
The distribution of Solana validators spans 37 different countries and regions. The largest concentration is in the US, with 508 validators (37%) running in US data centers, followed by 112 validators in the Netherlands (8%) and 111 validators in Russia (8%).
Geographical distribution of Solana validators by staking share
When measuring validators by staking share, the distribution is more balanced. Four major jurisdictions each account for over 10% of the share, with the US 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 different countries and regions, with nearly half located in the US and Germany.
Top 10 cities ranked by Solana node count and staking share
A more granular analysis of the distribution of validators and delegated stakes by city indicates that Solana validators are distributed across 121 cities globally.
Specifically, in the US, validators are distributed across all major regions, totaling 35 cities. The most popular cities are Chicago (124 validators, 2.3% staking share), Los Angeles (57 validators, 2.3% staking share), and New York (32 validators, 3.5% staking share).
Earlier this year, Anza employee Rex St.John proposed strategies for improving the geographical diversity of Solana validators (especially by expanding support for operators in the Global South) and identified several key challenges:
Higher latency: Nodes in remote areas struggle to stay synchronized with the network
Bandwidth costs: In some areas, bandwidth costs are very high
Regulatory restrictions: Legal limitations imposed by different jurisdictions restrict the viability of blockchain infrastructure operations
Underdeveloped infrastructure: Insufficient network and data center infrastructure
Unfavorable taxes and tariffs: High costs of hardware equipment
Talent shortage: Lack of local expertise in Solana, limited avenues for obtaining the capital required for staking
Hosting providers
Ideally, the validator set should be hosted by multiple independent providers rather than relying heavily on a few centralized providers. This diversification is critical to reducing the risk of network interruptions or censorship from any single provider.
A notable event in 2022 involved the German hosting service provider Hetzner, which unexpectedly removed Solana validators from its services, causing over 20% of active staking nodes (about 1000 validators) to go offline within hours. Nevertheless, Solana continued to operate normally without any failure issues. Most affected validators successfully migrated to new data centers within a few days, and nearly all staking nodes were back online within weeks.
Hosting providers for Solana validators classified by staking share
Solana validators are distributed across 135 different hosting providers, led by Teraswitch and Latitude.sh (formerly Maxihost), with the former being a private US company hosting 24% of validators, and the latter being a Brazilian low-cost bare-metal server provider hosting 19% of validators. Together, these two providers account for 43.4% of the share.
Other popular hosting providers include the French cloud computing company OVHcloud (8.65% share) and Cherry Servers in Lithuania (8.45% share).
Solana validator hardware requirements
As a high-performance, high-throughput blockchain, Solana has higher requirements for nodes than most of its industry peers. The hardware recommendations for Solana validators include the following key components:
CPU: 24 cores / 48 threads or higher, 4.2GHz base clock speed or faster
Memory: 512 GB
Disk: PCIe Gen3 x4 NVME SSD or higher, 2TB combined or larger. High TBW
No GPU requirements
In practice, Solana's bandwidth requirements make home operations impractical, so validators are primarily run on bare-metal servers in dedicated data centers.
Diversity of Solana clients
At its launch, Solana had only one validator client developed by Solana Labs, written in Rust. Although Solana Labs' client is no longer actively updated, a fork named Agave is still in use. Relying entirely on a single client implementation is a significant indicator of centralization, as it poses risks of critical software errors leading to the failure of the entire network's effectiveness.
Increasing client diversity has always been a priority for the Solana community, and with the launch of Firedancer, this goal is finally being realized.
Solana Client
Currently, multiple Solana client solutions are operating or in development:
Agave: A fork of the original client by Solana Labs, written in Rust, maintained by the Solana software development company Anza.
Firedancer: Maintained by Jump Crypto, a complete rewrite of the original client in C.
Frankendancer: A hybrid validator that combines Firedancer's network stack and block production components with Agave's execution and consensus.
Jito: A fork of the Agave client built by Jito Labs, introducing off-protocol block space auctions that provide more economic incentives for validators through tips.
Sig: A read-optimized Solana validator client written in Zig by Syndica.
Additionally, Mithril is a client written in Golang, developed by Overclock, and can serve as a validator full node with lower hardware requirements.
Having multiple full-time core engineering teams reviewing each other's codebases can significantly increase the likelihood of identifying errors while promoting knowledge sharing and collaboration. Anza engineer Joe Caulfield noted in a recent interview: "We learned a lot from the Firedancer client team; they came up with a lot of very smart solutions." Additionally, both Agave and Firedancer have launched bug bounty programs.
Diversity of Solana clients vs. Ethereum
Solana and Ethereum are the only L1s currently offering multiple client implementations. Ethereum has at least five major software clients, with the most widely adopted being Nethermind written in C, with a usage rate of 45%, and Geth written in Go, with a usage rate of 39%.
On Solana, the Jito client currently accounts for 88% of staking nodes. However, as new clients (Frankendancer and Firedancer) are gradually introduced and integrated, this landscape is expected to change significantly within the next 12 months.
Developer decentralization
In the book (Quantifying Decentralization), Balaji argues that developer decentralization is a key factor in the blockchain ecosystem, 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, maintained by the software development company Anza, which was established in early 2024, plays an important role in this area. When Anza was founded, it had about 45 employees, roughly half of the previous workforce at Solana Labs. In addition to managing Agave, the Anza team contributes to the broader Solana ecosystem through projects like token expansion, cross-border payment infrastructure, and Solana's permissioned environment.
Number of contributors to the Agave client codebase
The Agave client codebase has 357 contributors and 26408 commits, but the data is not perfect when it comes to the number of original commits, and it does not fully reflect the depth of individual contributions. Notably, most commits are authored by a small number of developers, primarily senior engineers and co-founders of Solana, in addition to a long list of minor contributors.
In contrast, the popular Geth and Nethermind clients on Ethereum also exhibit a similar contributor 'centralization' pattern across a larger community. Geth has 1,098 contributors, while Nethermind has 142. More than half of Geth's commits are attributed to three core contributors. In Nethermind, two developers contributed over 50% of all commits.
Number of contributors to the Firedancer client codebase
The Firedancer client is developed by a small team led by Kevin Bowers from Jump, a well-known high-frequency trading firm in the US, currently with 57 contributors and 3722 commits. Given that Firedancer is a relatively new project (its first commit dates back to August 2022) and has only recently launched on the mainnet, the diversity of contributors remains limited.
Solana ecosystem developers
In the broader Solana ecosystem, the geographical diversity of the developer community is unquestionable. Solana's biannual online hackathons are among the largest in the world, playing a significant role in cultivating today's most successful Solana protocol and application teams (including Tensor, Drift, Jito, and Kamino).
The recent 'Radar' attracted 13,672 participants from 156 countries/regions, with representatives from India, Nigeria, the US, and Vietnam being particularly prominent.
Additionally, as a network connecting Solana creators, developers, and operators, Superteam has now expanded to 1300 members across 16 countries. Its localized chapters promote collaboration by hosting events and sharing workspaces. Furthermore, Step Finance's Solana Allstars ambassador program has seen tremendous success in Nigeria, hosting over 120 meetups in various regions with strong attendance.
Governance
Governance is an important vehicle for decentralization as it determines how decisions are made within the network. This affects all aspects, from protocol upgrades to economic policies and community rules. Decentralized governance enhances the transparency, fairness, and trust of the network.
Governance voting and SIMD
Solana Improvement and Development (SIMD) proposals are formal documents required for any substantive changes to Solana's core components. Here, 'substantive' changes are defined as those that typically alter network protocols, transaction validity, or interoperability. Non-substantive changes, such as minor code refactoring or objective performance improvements, do not require a proposal.
While submitting SIMD does not require any permission, and any developer or researcher can submit, most SIMD are submitted by developers from client teams who work full-time on core protocol improvements.
There are two types of SIMD proposals:
Standard proposal: Impacts Solana's core functionalities (such as consensus, network, and API interfaces)
Meta proposal: Involves processes or guidelines outside the codebase
SIMD processes
SIMD typically goes through stages of creative review, drafting, review, and acceptance. Formal reviews are conducted publicly on GitHub, with proposal authors responsible for gathering feedback from relevant core contributors, who then decide whether to accept, modify, or withdraw the proposal. Authors are not obligated to implement their proposals, but it is generally advised to do so, as this is the best way to ensure successful completion of the proposal.
If a proposal is accepted, it typically includes a related feature implementation tracking issue and may require activation through Solana's feature-gate mechanism. The feature gate activates first on Testnet based on time constraints, followed by Devnet, and finally Mainnet.
Discussions on improvements involve the following areas:
SIMD (Solana Improvement Document) GitHub repository
sRFC (Solana Request for Comments) section of the Solana official forum
Solana Technical Discussion Area
Social channels, including X (formerly Twitter) and Telegram
Solana governance voting process
Significant changes to the protocol require governance voting, especially those affecting economic parameters. The Solana governance voting process is a relatively new initiative, initiated by long-term members of the validator community, focusing only on key issues to maintain participation and avoid governance fatigue.
So far, three such votes have been conducted, including:
First consultation vote in October 2023 (14.3% of staking nodes participated)
April 2024 vote on timely voting rewards SIMD33 (53% of staking nodes participated)
May 2024 vote on full priority fees payment to validators SIMD96 (51% of staking nodes participated)
Voting is conducted by depositing tokens into each validator's identity account, with the number of tokens received by each account proportional to its active staking share in lamports.
To vote, validators need to transfer tokens to one of several designated public keys corresponding to the voting options (including abstention). Once voted, changes cannot be made.
In this structure, SOL token holders participate indirectly by delegating their SOL to validators whose voting choices align with their values or preferences.
Governance benchmarks
According to a benchmark report released by CCData earlier this year, Solana is one of only four AA-rated assets among the top 40 digital assets assessed against Environmental, Social, and Governance (ESG) criteria. In the governance rating of this report, Solana ranks fourth among L1s, with evaluation factors including stakeholder participation, 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 has an initial fund of 167 million SOL tokens, responsible for overseeing the funding sources for grants, delegation programs, and developer tools. It controls the official brand assets, social media accounts, website, and trademarks.
Currently, SF is led by Executive Director Daniel Albert and President Lily Liu, and operates with a relatively lean team of 60-65 full-time employees under the oversight of the foundation's board.
The mission of the foundation is to establish a scalable, self-sustaining Solana ecosystem, focusing on education, research, and ecosystem development programs. SF organizes large-scale Solana events, including Hacker Houses and the annual Breakpoint conference, to promote developer engagement and community building.
The SF developer relations team is responsible for maintaining official documentation, social channels, and developer education. In January 2024, SF transferred the management of the 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 find scalable ways to support the network and ecosystem and then let go." This indicates that SF's long-term goal is to establish a network that can self-sustain without supervision.
Conclusion
As described in this article, Solana's decentralization is comparable to that of its industry peers on many key metrics, including Nakamoto coefficient, geographical distribution of validators and staking nodes, developer decentralization, and governance benchmarks, with the diversity of clients currently being a notable issue that the new Firedancer client aims to address.
To strengthen the decentralization of Solana, several approaches can be considered:
Exploring the distribution of SF's responsibilities among multiple organizations
Increase transparency in foundation spending and grant allocation
Develop initiatives like 'Solana Nations' to increase regional diversity
Reduce the maximum expenses for validator operators, namely voting costs
Explore strategies to reduce validator data output requirements; validators outside the EU and the US face significantly higher data output costs
Encourage more active participation in governance voting
Expand Solana's core contributors and research community to strengthen network development
Currently, the Solana validator set is still somewhat concentrated in the US and EU, relying on a limited number of hosting service providers. While this challenge is not unique to Solana, it highlights the potential for Solana to reduce its level of centralization in this regard.
Finally, thanks to Overclock, Amira Valliani, Matt Sorg, Yelena Cavanaugh, Dan Albert, Tim Garcia, 0xIchigo, Anatoly Yakovenko, and Brady Werkheiser for reviewing early versions of this article.
