Actionable Insights

• The Solana network is distributed across 4,514 nodes, including 1,414 validators and 3,100 RPCs (epoch 685). No single validator controls more than 3.2% of the total stake.
• The Nakamoto Coefficient (NC) represents the smallest number of independent entities that can maliciously conspire to cause a liveness failure, denying the consensus needed for new block production. Solana’s Nakamoto Coefficient is frequently cited as 19. The actual figure is likely lower since individual entities can permissionlessly operate multiple validators anonymously.
• Solana’s validator set spans 37 countries and territories. The largest concentration is in America, with 508 validators. Four jurisdictions each hold over 10% of stake: the US with 18.3%, the Netherlands and the UK, both at 13.7%, and Germany with 13.2%.
• 68% of stake is delegated to European validators, with 20% delegated to North America. 50.5% of stake is delegated to validators operating within the European Union (European stake excluding Norway, Ukraine, and the UK).
• The validator set is dispersed across 135 different hosting providers. The two leading providers are Teraswitch, a privately owned U.S. company hosting validators with a combined 24% of stake, and Latitude.sh (formerly Maxihost), a Brazilian-based provider of low-cost bare metal servers used by validators with a combined 19% of stake.
• The Agave client codebase has 357 individual contributors. The Firedancer client, developed by a small team under the leadership of chief science officer Kevin Bowers, currently has 57 contributors.
• The Jito client, a fork of the original Agave codebase that includes an out-of-protocol block space auction, currently holds a dominant 88% share of the network’s stake. However, this is expected to change considerably over the next twelve months as the new Firedancer client is gradually introduced and integrated into the ecosystem. Solana and Ethereum stand out as the only Layer 1 blockchains currently offering multiple client implementations.
• Substantial changes to Solana’s core components undergo a formal and public Solana Improvement and Development (SIMD) proposal process. The most significant protocol-altering changes, especially those affecting economic parameters, undergo governance votes. So far, three such votes have taken place.
• The Solana Foundation, established in June 2019, is a Swiss-registered non-profit organization dedicated to growing and supporting the Solana ecosystem. The SF’s relatively lean team of 60-65 full-time employees oversees funding for grants, staking programs, and developer tools.
• Additionally, there is strong evidence of geographical diversity among the Solana developer community. The most recent bi-annual hackathon, Radar, drew 13,672 participants from 156 countries, with notable participation from India, Nigeria, the U.S., and Vietnam. SuperTeam, a network connecting Solana creatives, developers, and operators, has expanded to 1,300 members in 16 countries.

What is Decentralization?

Decentralization can be summarized as the lack of a single point of failure within a system. This multifaceted concept spans many dimensions, including token distribution, the influence of key figures, permissionless network participation, control over development, and software/hardware diversity. Quantifying a blockchain’s level of decentralization has few universally accepted standards outside of Balaji’s Nakamoto Coefficient. Many metrics are imperfect. Moreover, discussions around blockchain decentralization, often rooted in political philosophy, give rise to deeply ideological and, at times, almost religious debates.

‍

Solana has been the subject of substantial criticism and misinformation from a vocal subset of the blockchain community regarding a perceived lack of decentralization and censorship resistance. A recent example being former American intelligence contractor and whistleblower Edward Snowden, who voiced concerns during a Token2049 conference keynote presentation.

‍

“When you look back at the Bitcoin whitepaper, I think what you see is an adversarial approach to the system and that’s really what you have to be considering. A lot of people, and I don’t want to name names but, Solana, are taking good ideas and going, well, what if we just centralized everything? It will be faster, it will be more efficient, it’ll be cheaper… You have to be thinking for the adversarial case as opposed to the convenient, easy early case.”

‍

As with many of Solana’s critics, Snowden offered no data to substantiate his statements despite being publicly invited to do so. In the following sections of this work, we’ll analyze the decentralization of the Solana network through data, highlighting areas where the network demonstrates relatively strong decentralization while identifying areas where further progress is needed.

Dimensions of Decentralization

With this report, we will take a quantitative and multifaceted approach to analyzing Solana’s decentralization, basing our analysis on facts and publicly verifiable information.

‍

We will assess the following areas:

• Distribution of stake
• Geographical distribution of nodes
• Diversity of hosting providers
• Client software diversity
• Developer diversity
• Governance processes and entities

‍

When appropriate, we will compare Solana network’s metrics to those of other industry peer proof-of-stake L1 blockchains. Peer networks serve only as benchmarks, providing a broader context for Solana’s decentralization journey and highlighting areas where it may lag or outperform expectations.

‍

These comparisons should not be misconstrued as attempts to claim one network’s superiority over another.

‍

In many cases, Ethereum provides the most helpful benchmark as it is widely considered the most decentralized Layer 1 proof-of-stake blockchain. It is worth noting that Ethereum is more than twice as old as Solana, with its genesis block produced in July 2015, compared to Solana’s in March 2020. Decentralization is dynamic, and blockchains typically become more decentralized over time. Given similar conditions, it’s reasonable to expect older networks to achieve higher levels of decentralization.

Distribution of Stake

Stake distribution in a blockchain network refers to how the network’s staked tokens are allocated among its validators. In a well-distributed system, no single validator or small group holds a disproportionately large stake, reducing the risk of any one entity gaining undue influence or control over network consensus.

‍

A balanced stake distribution promotes decentralization by ensuring a diverse set of validators, making it harder for any malicious actor to compromise the network’s integrity. It also contributes to greater fault tolerance as the network becomes more resilient to individual validator failures.

‍

“You need a very large validator set, the larger it is on a gut level the network is more secure, but on the academic level, the bigger the set of nodes the easier it is to guarantee that honest nodes as a minority of that set always have a minimum spanning tree that can reach each other. That doesn’t even mean at the protocol layer; it’s literally people talking on the phone. The fact that people can get into Discord or IRC or call each other on a cell phone. That is us resolving a partition and figuring out what’s wrong. The more people we have, the easier it is for us to guarantee that partitions are impossible.”

• Anatoly Yakovenko, Breakpoint 2024

‍

Running a node on the Solana network is entirely permissionless, with a very low mandatory minimum stake (1 SOL) required to operate as a validator. The network natively supports delegated proof-of-stake (dPoS) and consists of 4,514 nodes, including 1,414 validators and 3,100 RPC nodes.

‍

The largest two validators by stake are operated by Helius and Galaxy, each holding roughly 3.2%. The minimum delegated stake required to enter the top one-third superminority and top two-thirds supermajority is 4.4 million and 1.23 million SOL, respectively.

‍

Above: validators ordered by stake, logarithmic scale

‍

The chart below groups validators by delegated stake for added clarity. At the upper end, 82 validators (5.87% of the total) hold over one million delegated SOL. Conversely, on the lower end, 825 validators (59.1% of the total) have under 50,000 delegated SOL, with most participating in the Solana Foundation Delegation Program (SFDP), a program designed to help fast-track smaller validators to sustainability. Approximately 72% of Solana validators benefit from SFDP support, and these validators collectively represent 19% of the total stake. For an in-depth exploration of SFDP, please refer to our earlier Helius report: SFDP & the Challenges Facing Long-tail Validators.

‍

Above: Solana validators grouped by stake

‍

Just as blockchain addresses do not equate to users, the validator count does not reflect the true number of distinct entities operating validators. The true number is lower as larger entities may chose to distribute their stake across multiple validators. For instance, Jito (1, 2), Coinbase (1, 2), and Mrgn (1, 2) operate several validators.

‍

There is no inherent issue with a single entity operating multiple validators; in fact, this could strengthen the network by increasing geographical and hosting provider diversity, provided the validators are distributed rather than collocated. However, risks may arise if these validators are configured identically with non-standard settings or firewall rules. Additionally, having numerous validators managed by a single entity on behalf of large companies or projects as part of a “validator-as-a-service” model could present further decentralization concerns.

Nakamoto Coefficient

In proof-of-stake networks, the Nakamoto Coefficient represents the minimum number of nodes required to control at least one-third of the total stake (i.e., the superminority). A higher Nakamoto Coefficient indicates a broader distribution of stake and, consequently, a higher level of decentralization. It can also be considered the smallest number of independent entities that can maliciously conspire to cause a liveness failure, denying the consensus needed for new block production. PoS and Byzantine Fault Tolerance-based blockchains require more than two-thirds of the stake to agree on the state of the network to continue transaction processing.

‍

To determine the Solana network’s Nakamoto Coefficient, we rank validators from highest to lowest by their stake share and count the number required to control one-third of the total stake. Solana’s Nakamoto Coefficient has historically ranged between a peak of 34 on August 13, 2023, and a low of 19, where it currently stands. The coefficient has been relatively stable for the past year.

Above: Solana’s historical Nakamoto Coefficient

‍

The Solana network’s Nakamoto Coefficient ranks in the middle compared to industry peer networks. These numbers do not consider that individual entities are free to permissionlessly operate multiple validators anonymously, so the true Nakamoto Coefficients are likely lower.

‍

Above: comparison of Nakamoto coefficients between various L1 blockchains

‍

Geographical Distribution of Validators and Stake

The geographical diversity of network nodes is essential for reducing risk and promoting network antifragility. When too many validators are concentrated in a single region, the network’s resilience becomes reliant on the regulatory frameworks of those specific jurisdictions.

‍

Natural disasters, including earthquakes, floods, hurricanes, and tsunamis, pose another risk. Such events strain national power grids and can severely disrupt data center operations, leading to abrupt outages. Manmade threats, such as war, cyberattacks, and damage to critical internet infrastructure, including undersea cables, pose further risks that could endanger network stability.

‍

Solana data for this section’s analysis was gathered from validators.app for epoch 685. The raw dataset is available in spreadsheet format here. These numbers reflect only staked validator nodes and do not include non-staked RPC nodes.

Solana Validator Count and Stake by Continent

When grouped by continent, the data shows that 632 Solana validators (46%) are based in Europe, with 550 (40%) in North America. In terms of stake distribution, 68% of stake is delegated to validators in Europe, with 20% delegated to those in North America. 50.5% of all stake is delegated to validators operating within the European Union (i.e., European stake excluding Norway, Ukraine, and the UK).

‍

Above: Solana validator and stake distribution by continent (map design: FreePik)

‍

Comparatively, Ethereum has a similar distribution of stake with higher weighting towards North America at 34.4%.

‍

Above: Ethereum validator and stake distribution by continent (map design: FreePik)

‍

Solana Validator Count by Country

The Solana network’s validator set spans 37 different countries and territories. The largest concentration is in America, with 508 validators (37%) operating from U.S. data centers, followed by 112 validators (8%) in the Netherlands and 111 validators (8%) in Russia.

‍

Above: Solana validator count by country, epoch 685

‍

Geographical Distribution of Solana by Stake

This distribution is more balanced when weighing the validator set by stake. Four key jurisdictions each hold over 10% of stake: the US with 18.3%, followed by the Netherlands and the UK, both at 13.7%, and Germany with 13.2%.

‍

Above: Geographical distribution of Solana stake (epoch 685)

‍

By comparison, Ethereum nodes are distributed across 83 different countries and territories, with almost half located in the US or Germany.

‍

Above: Ethereum nodes by country (source)

‍

Top 10 Cities by Solana Node Count and Stake

A more granular analysis of validator and delegated stake distribution by city shows Solana validators are distributed across 121 cities worldwide.

‍

Specifically, for the United States, validators are dispersed across all major regions, encompassing 35 cities in total. The most popular are Chicago (124 validators, 2.3% of stake), Los Angeles (57 validators, 2.3% of stake), and New York (32 validators, 3.5% of stake).

‍

‍

Earlier this year, Anza staff Rex St.John proposed strategies to improve the geographic diversity of Solana’s validators, notably by expanding the presence of operators in the global South.

‍

Several key challenges were identified:

‍

• Higher latency: nodes in remote regions face difficulty staying synchronized with the network.
• Bandwidth cost: some regions are notable for having a very high cost of bandwidth
• Regulatory restrictions: various jurisdictions impose laws that limit the feasibility of operating blockchain infrastructure
• Underdeveloped infrastructure: Insufficient network and data center infrastructure.
• Unfavorable tax and tariffs: high costs on hardware equipment.
• Talent shortage: a lack of local expertise in Solana and limited access to the capital required for staking

Hosting Providers

The validator set should ideally be hosted across a broad spectrum of independent providers rather than relying heavily on a few centralized ones. This diversification is essential to reducing the risk of network disruptions or censorship from any single provider.

‍

A notable incident in 2022 involved the German hosting provider Hetzner, which unexpectedly removed Solana validators from its services, taking over 20% of the active stake — around 1,000 validators — offline within hours. Despite this, Solana remained fully operational without liveness issues. Most impacted validators successfully migrated to new data centers within days, and nearly all delinquent stake was back online within a few weeks.

Above: the email notification sent to Hetzner customers instructing them to remove Solana client software from their servers

‍

Solana Validator Hosting Providers by Stake

The Solana validator set is dispersed across 135 different hosting providers. The two leading providers are Teraswitch, a privately owned U.S. company, hosting 24% of validators, and Latitude.sh (formerly Maxihost), a Brazilian-based provider of low-cost bare metal servers used by 19% of validators. These two providers combined account for 43.4% of stake.

‍

Other popular hosts include the French cloud computing company OVHcloud, with an 8.65% share, and Lithuanian-based Cherry Servers, hosting 8.45% of validators.

‍

Above: validator hosting providers by stake

‍

Solana Validator Hardware Requirements

Because Solana is a high-performance, high-throughput blockchain, it has more demanding node requirements than most industry peers. Hardware recommendations for Solana validators include the following key components:

‍

• CPU: 24 cores / 48 threads, or more, 4.2GHz base clock speed, or faster
• Memory: 512 GB
• Disk: PCIe Gen3 x4 NVME SSD, or better, 2 TB combined or larger. High TBW
• No GPU requirement

‍

In practice, Solana’s bandwidth requirements make home operations impractical, so validators are predominantly operated from bare metal servers in dedicated data centers.

Solana Client Diversity

Solana initially launched with a single validator client, developed by Solana Labs and written in Rust. While the Solana Labs client is no longer actively updated, a fork known as Agave is currently in active use. Relying entirely on a single client implementation is a significant vector of centralization because it poses the risk of a critical software bug that could cause a liveness failure across the entire network.

‍

Increasing client diversity has been a top priority for the Solana community, and this goal is now finally being realized with the rollout of Firedancer.

Solana Client Implementations

Today, multiple Solana client implementations are either operational or in development:

• Agave: a fork of the original Solana Labs client, written in Rust and maintained by Solana software development firm Anza.
• Firedancer: a complete ground-up rewrite of the original client in the C programming language maintained by Jump Crypto.
• Frankendancer: a hybrid validator combining the networking stack and block production components of Firedancer with the execution and consensus of Agave.
• Jito: an Agave client fork built by Jito Labs that introduces an out-of-protocol block space auction, providing validators with more economic incentives through tips.
• Sig: a reads-optimized Solana validator client written in Zig by Syndica.

‍

Additionally, Mithril is a client written in Golang and developed by Overclock to serve as a verifying full node with lower hardware requirements.

‍

Having multiple full-time core engineering teams reviewing each other’s codebases significantly boosts the likelihood of catching bugs while promoting knowledge sharing and collaboration.

‍

“We’ve learned a lot from the Firedancer client team; there are things that they’ve come up with that have been really clever solutions,” noted Anza engineer Joe Caulfield in a recent interview.

‍

Both Agave and Firedancer have significant bug bounty programs.

Solana Client Diversity vs. Ethereum

Solana and Ethereum are the only Layer 1 networks 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% adoption.

‍

On Solana, the Jito client currently has an 88% share of the network’s stake. However, this landscape is expected to change considerably over the next twelve months as new clients — Frankendancer and Firedancer — are gradually introduced and integrated into the ecosystem.

‍

Above: Solana and Ethereum client diversity (October 2024)

‍

Developer Decentralization

In Quantifying Decentralization, Balaji identifies developer decentralization as a critical factor for blockchain ecosystems, emphasizing the importance of minimizing reliance on individual contributors and reducing “key person risk.”

‍

All core client software on Solana is hosted publicly on GitHub under open-source licenses, allowing for open access and community contributions.

‍

The Agave validator, maintained by Anza — a software development firm established in early 2024 — plays a prominent role in this landscape. Anza was founded with around 45 employees, roughly half of the team previously employed by Solana Labs.

‍

In addition to managing Agave, the Anza team contributes to the broader Solana ecosystem by developing initiatives such as token extensions, cross-border payments infrastructure, and Solana Permissioned Environments.

Number of Agave Client Codebase Contributors

The Agave client codebase has 357 contributors and 26,408 commits, though raw commit counts alone are imperfect and do not fully capture the depth of individual contributions. Notably, a relatively small group of developers — primarily senior engineers and co-founders of Solana — have authored the majority of commits, with a long tail of smaller contributors.

‍

Above: commits to the Solana Agave client codebase by contributor. Dependabot is a dependency tracking/updating bot.

‍

For comparison, Ethereum’s popular Geth and Nethermind clients demonstrate a similar pattern of contributor concentration within a larger community. Geth has 1,098 contributors, while Nethermind has 142. Over half of all commits to Geth are attributable to three core contributors. Likewise, two developers account for over 50% of all commits to Nethermind.

‍

Number of Firedancer Client Codebase Contributors

The Firedancer client, developed by a small team under the leadership of Kevin Bowers at the prominent American high-frequency trading firm Jump, currently has 57 contributors and 3,722 commits. Contributor diversity remains limited given that Firedancer is a relatively new project — the first commit dates back to August 2022 — and became live on mainnet only recently.

‍

Above: commits to the Solana Agave client codebase by contributor.

‍

Solana Ecosystem Developers

Across the broader Solana ecosystem, there is strong evidence of geographical diversity among the developer community. Solana’s online bi-annual hackathons are some of the largest in the world by participation and play a large role in nurturing many of today’s most successful Solana protocols and applications teams, including Tensor, Drift, Jito, and Kamino.

‍

The most recent Radar hackathon drew 13,672 participants from 156 countries, with notable representation from India, Nigeria, the U.S., and Vietnam.

‍

Above: Radar hackathon registrations by country

‍

Superteam, a network connecting Solana creatives, developers, and operators, has expanded to 1,300 members in 16 countries. Its localized chapters facilitate collaboration through events and shared workspaces. Solana Allstars, an ambassador program run by Step Finance, has seen considerable success in Nigeria, running over 120 well-attended meetups across many regions

‍

Governance

Governance is an important vector for decentralization as it determines how decisions are made within the network. This impacts everything from protocol upgrades to economic policies and community rules. Decentralized governance strengthens transparency, fairness, and trust in the network.

Governance Voting and SIMDs

Solana Improvement and Development (SIMD) proposals are the formal documentation necessary for any substantial change to Solana’s core components. “Substantial” changes are defined as those that typically alter the network protocol, transaction validity, or interoperability.

‍

Non-substantial changes, such as minor code refactoring or objective performance improvements, do not require proposals. Proposals should document the rationale for the feature and enough documentation to understand the implementation.

‍

While submitting SIMDs is permissionless and open to any developer or researcher, most are submitted by client team developers working full-time on core protocol improvements.

‍

There are two types of proposals:

• Standard Proposals: affect core Solana features (e.g., consensus, networking, and API interfaces)
• Meta Proposals: address processes or guidelines outside the codebase

SIMD Process

SIMDs typically progress through idea vetting, drafting, review, and acceptance stages. A formal review occurs publicly on GitHub, with the proposal author being responsible for gathering feedback from relevant core contributors, who determine if it is accepted, revised, or withdrawn.

‍

Authors are not obligated to implement their proposals, but it is generally suggested they do so as the best way to ensure successful completion.

‍

If accepted, proposals often include an associated tracking issue for feature implementation and may require activation through Solana’s feature-gate mechanism. Feature gates are activated on epoch boundaries first on Testnet, then Devnet, before Mainnet activation.

‍

Discussions on improvements span the following venues:

• SIMD (Solana Improvement Document) Github repository
• sRFC (Solana Request for Comments) section of the official Solana forums
• The Solana Tech Discord
• Disperse social channels, including X (formerly Twitter) and Telegram

Solana Governance Voting Process

Significant protocol-altering SIMDs, especially those affecting economic parameters, undergo governance votes. The Solana governance voting process, a relatively new initiative spearheaded by longstanding members of the validator community, focuses solely on critical issues to maintain engagement and avoid governance fatigue.

‍

So far, three such votes have taken place:

• Initial Advisory Vote in October 2023 (14.3% stake participation)
• SIMD33 Timely Vote Credits in April 2024 (53% stake participation)
• SIMD96 Full Priority Fee to Validators in May 2024 (51% stake participation)

‍

Voting occurs via tokens deposited into each validator’s identity account, with each account receiving tokens proportional to its active stake in lamports.

‍

To cast a vote, validators transfer these tokens to one of several designated public keys corresponding to the available voting options, including an option to abstain. Once a vote is cast, it cannot be changed.

‍

In this structure, SOL token holders participate only indirectly by delegating their staked SOL to validators whose voting choices align with their values or preferences.

Governance Benchmarking

According to a benchmarking report by CCData released earlier this year, Solana is one of only four AA-graded assets among the top 40 digital assets evaluated for Environmental, Social, and Governance (ESG) standards. The report’s governance ratings, in which Solana was ranked fourth among L1 blockchains, assess factors including stakeholder participation, transparency, and the degree of decentralization.

‍

Above: Digital asset ESG benchmark governance ratings for L1 blockchains (source)

‍

The Solana Foundation

The Solana Foundation (SF), established in June 2019, is a Swiss-registered non-profit organization dedicated to decentralization, adoption, and security of the Solana ecosystem. With an initial treasury of 167 million SOL tokens, SF oversees funding for grants, its Delegation Program, and developer tools. It controls official brand assets, social media accounts, websites, and trademarks.

‍

The Foundation operates with a relatively lean team of 60-65 full-time employees under the leadership of Executive Director Daniel Albert and President Lily Liu, supervised by the Foundation board.

‍

SF’s mission is to cultivate a scalable and self-sustaining Solana network, focusing on education, research, and ecosystem development initiatives. SF organizes large-scale Solana events, including Hacker Houses and the annual Breakpoint conference, to foster developer engagement and community building.

‍

The SF developer relations team maintains official documentation, social channels, and developer education. In January 2024, SF transitioned the management of the flagship hackathons to Colosseum, a new independent accelerator co-founded by former SF Head of Growth Matty Taylor.

‍

“Our job is to work ourselves out of a job. Find scalable ways to support the network and ecosystem and then get out of their way,” noted Dan Albert at a recent debate, signaling SF’s long-term aim to establish a network that can sustain itself without oversight.

Conclusion

As outlined in this work, the Solana network’s decentralization is comparable to or exceeds that of its industry peers across numerous key metrics, including the Nakamoto Coefficient, geographical distribution of validators and stake, developer decentralization, and governance benchmarks. Client diversity remains a notable exception, which the new Firedancer client aims to address.

‍

Several opportunities exist to enhance Solana’s decentralization:

• Explore options to distribute the SF’s responsibilities across multiple organizations
• Increase transparency around Foundation spending and grant allocations
• Develop initiatives, such as ‘Solana Nations,’ to increase geographic diversity
• Reduce voting costs, which are the most significant expense for validator operators
• Explore strategies to reduce data egress demands on validators; these costs are notably high for operators outside the EU and US
• Encourage more active participation in governance voting
• Expand Solana’s core contributor and research communities to strengthen the network’s development

‍

The validator set remains somewhat concentrated in the U.S. and EU and reliant on a limited number of hosting providers. While this challenge is not unique to Solana, it highlights the potential for Solana to improve as one of the less centralized blockchains on the validator level.

‍

Many thanks to Overclock, Amira Valliani, Matt Sorg, Yelena Cavanaugh, Dan Albert, Tim Garcia, 0xIchigo, Anatoly Yakovenko, and Brady Werkheiser for reviewing earlier versions of this work.

Additional Resources

• The Solana Foundation Delegation Program - Helius
• The Solana Foundation Should Be Dissolved - Breakpoint 2024 Debate
• Solana Improvement Documents (SIMDs) repository - GitHub
• Why Solana is more decentralized than you think (2022) - Max Sherwood

Disclaimer：

1. This article is reprinted from [helius], All copyrights belong to the original author [Lostin]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.