Helius: Measuring Solana’s true decentralization from data

Author: Lostin, Helius

Compiled by: Yangz, Techub News

summary

• As of Epoch 685, Solana has 4,514 nodes, including 1,414 validators and 3,100 RPCs. No validator controls more than 3.2% of the stake.
• The Nakamoto Coefficient (NC) represents the minimum number of independent entities that can maliciously collude to invalidate validity and refuse to reach the consensus required for the production of new blocks. Solana’s Nakamoto Coefficient is currently 19, but the actual number is likely lower because a single entity can operate multiple validators anonymously.
• Solana’s validators are located in 37 countries and regions. The largest number of validators is concentrated in the United States, with a total of 508. In addition, four jurisdictions each account for more than 10% of the share, with the United States accounting for 18.3%, the Netherlands and the United Kingdom each accounting for 13.7%, and Germany accounting for 13.2%.
• 68% of the stake is delegated to validators in Europe, with 50.5% of the stake delegated to validators within the EU (excluding Norway, Ukraine, and the UK). In addition, 20% is delegated to North America.
• Validators are spread across 135 different hosting providers, with Teraswitch, a private US company that provides hosting services to validators, and Latitude.sh (formerly Maxihost), a Brazilian company that provides low-cost bare metal servers to validators, accounting for a combined 24% share, and Latitude.sh (formerly Maxihost), a Brazilian company that provides low-cost bare metal servers to validators, accounting for a combined 19% share.
• The Agave client codebase has 357 individual contributors. The Firedancer client is developed by a small team led by Chief Science Officer Kevin Bowers and currently has 57 contributors.
• The Jito client, a fork of the original Agave codebase that includes an off-protocol blockspace auction, currently has a dominant share of 88% of the network. However, this is expected to change significantly over the next 12 months as the new Firedancer client is gradually introduced and integrated into the ecosystem. Solana and Ethereum are the only L1s that currently offer multiple client implementations.
• Significant changes to core components of Solana are subject to a formal, public Solana Improvement and Development (SIMD) proposal process. The most significant protocol changes, especially those affecting economic parameters, are subject to a governance vote. So far, three such votes have taken place.
• Founded in June 2019, the Solana Foundation is a non-profit organization registered in Switzerland dedicated to developing and supporting the Solana ecosystem. The Foundation has a relatively lean team of 60-65 full-time employees responsible for overseeing funding for grants, delegation programs, and developer tools.
• In addition, the geographic diversity of the Solana developer community has been strongly demonstrated. The most recent hackathon event "Radar" attracted 13,672 participants from 156 countries, with high participation from India, Nigeria, the United States, and Vietnam. SuperTeam is a network connecting Solana creatives, developers, and operators, and has now expanded to 1,300 members in 16 countries.

Why decentralization?

Decentralization can be summarized as the absence of a single point of failure within a system. This multifaceted concept involves multiple aspects, including token distribution, influence of key individuals, participation in permissionless networks, development control, and software/hardware diversity. Aside from Balaji’s Satoshi coefficient, there are few universally accepted standards for quantifying the degree of decentralization of a blockchain. Many of the metrics are imperfect. Furthermore, discussions around blockchain decentralization are often rooted in political philosophy, sparking deep ideological debates that sometimes border on religious debate.

Solana’s level of decentralization has been criticized by some in the blockchain community, who believe that Solana lacks decentralization and censorship resistance. A recent example is former NSA whistleblower Edward Snowden, who expressed his concerns during his keynote speech at the Token2049 conference.

However, like many of Solana’s critics, Snowden did not provide any data to back up his claims, despite being publicly invited to do so. In the following sections of this article, we will analyze Solana’s decentralization with data, highlighting where the network demonstrates relatively strong decentralization while pointing out areas where further progress is needed.

Decentralization at all levels

Through this report, we will take a quantitative and multifaceted approach to analyzing Solana’s decentralization, based on facts and publicly verifiable information.

We will assess the following:

• Staking Distribution
• Geographical distribution of nodes
• Diversity of hosting providers
• Diversity of client software
• Diversity of developers
• Governance Processes and Entities

When appropriate, we will compare Solana’s metrics to other PoS L1s. To be clear, peer networks serve only as benchmarks to provide broader context for Solana’s decentralization journey and highlight areas where it may be lagging or exceeding expectations. These comparisons should not be misinterpreted as an attempt to claim that one network is superior to another.

In many cases, Ethereum provides the most useful benchmark, as it is widely considered the most decentralized PoS L1. Notably, Ethereum’s genesis block was mined in July 2015, while Solana’s genesis block was mined in March 2020. Decentralization is dynamic, and blockchains generally become more decentralized over time. Given similar conditions, it is reasonable to expect that older chains will be more decentralized.

Distribution of pledge

The staking distribution of a blockchain network refers to how the network's native tokens are distributed among validators. In a well-distributed system, no single validator or small group holds too much of the staking share, so the risk of any one entity gaining undue influence or control over the network consensus is reduced.

Balanced stake distribution ensures a diverse set of validators, which promotes decentralization and makes it difficult for any malicious actor to undermine the integrity of the network. It also helps improve fault tolerance as the network becomes more resilient to single validator failures.

“You need a very large validator set, and at an intuitive level, the larger the validator set, the more secure the network is, and at an academic level, the larger the node set, the easier it is to ensure that as a minority of honest nodes in the set, you always have a minimum spanning tree that can access each other. This is not even referring to the protocol layer, but to people talking on the phone. In fact, people can go into Discord or IRC, or talk to each other on their phones. And this is the key to solving the split problem and finding out what the problem is. The more people we have, the easier it is to ensure that the split is impossible.” - Anatoly Yakovenko, Breakpoint 2024

Running a node on Solana is completely permissionless and requires only a very low mandatory minimum stake (1 SOL) to run as a validator. The network natively supports delegated proof of stake (dPoS) and consists of 4514 nodes, including 1414 validators and 3100 RPC nodes.

The two largest validators by stake are Helius and Galaxy, each holding approximately 3.2% of the stake. 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 greater clarity, the following chart groups validators by delegated stake. Among them, 82 validators (5.87% of the total) hold more than 1 million delegated SOLs; 825 validators (59.1% of the total) have less than 50,000 delegated SOLs, and most of them participate in the Solana Foundation Delegation Program (SFDP), which aims to help smaller validators quickly achieve sustainable development. About 72% of Solana validators benefit from the support of SFDP, and these validators account for 19% of the total stake. For an in-depth discussion of SFDP, please refer to our earlier Helius report: "SFDP and the Challenges of Long-Tail Validators".

Just as blockchain addresses are not equivalent to users, the number of validators does not reflect the true number of different entities operating validators. Since large entities may choose to distribute their stake across multiple validators, the true number is lower. For example, Jito (1,2), Coinbase (1,2), and Mrgn (1,2) operate multiple validators.

There is nothing inherently problematic about a single entity operating multiple validators; in fact, as long as validators are distributed rather than centralized, they can strengthen the network by increasing the diversity of geographies and hosting providers. However, this can create risks if these validators are configured identically with non-standard settings or firewall rules. Additionally, having a single entity manage many validators on behalf of large companies or projects as part of a “validator-as-a-service” model can introduce further decentralization issues.

Satoshi Coefficient

In a proof-of-stake network, the Nakamoto Coefficient represents the minimum number of nodes required to control at least one-third of the total stake. The higher the coefficient, the more widely distributed the stake is, and the more decentralized it is. Additionally, it can be thought of as the minimum number of independent entities that can maliciously collude to cause validity failures, thereby denying the consensus required for new block production. Blockchains based on PoS and Byzantine Fault Tolerance require more than two-thirds of the staked nodes to reach a consensus on the state of the network before transaction processing can proceed.

To determine Solana’s Satoshi coefficient, we ranked validators by stake share from highest to lowest and calculated the number of validators needed to control one-third of the total stake. The result is that Solana’s Satoshi coefficient peaked at 34 on August 13, 2023, and is currently at 19. The coefficient has been relatively stable over the past year.

In comparison, Ethereum’s staking distribution is similar, but with a higher North American weighting at 34.4%.

Solana Validators by Country

Solana’s validators are located in 37 different countries and regions. The largest concentration is in the United States, with 508 validators (37%) running in US data centers, followed by 112 validators in the Netherlands (8%) and 111 validators in Russia (8%).

Solana validators’ geographic distribution by stake share

When measuring validators by staked share, the distribution is more even. Four major jurisdictions each account for more than 10% of the share, with the United States accounting for 18.3%, followed by the Netherlands and the United Kingdom, both at 13.7%, and Germany at 13.2%.

In contrast, Ethereum nodes are located in 83 different countries and regions, with nearly half of them located in the United States and Germany.

Top 10 cities by Solana node count and stake share

A more granular analysis of validator and delegated staking distribution by city shows that Solana validators are distributed in 121 cities around the world.

Specifically, in the United States, validators are spread across all major regions, including 35 cities. The most popular cities are Chicago (124 validators, 2.3% staked), Los Angeles (57 validators, 2.3% staked), and New York (32 validators, 3.5% staked).

Earlier this year, Anza employee Rex St. John proposed a strategy for improving the geographic diversity of Solana’s validators (particularly by expanding support for operators in the Global South) and identified several key challenges:

• Higher latency: Nodes in remote areas have difficulty keeping up with the network
• Bandwidth costs: Bandwidth costs are very high in some areas
• Regulatory restrictions: Laws implemented in different jurisdictions limit the feasibility of operating blockchain infrastructure
• Underdeveloped infrastructure: Inadequate network and data center infrastructure
• Unfavorable taxes and tariffs: High cost of hardware equipment
• Talent shortage: Lack of local Solana expertise and limited access to 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 outages or censorship from any single provider.

A notable incident in 2022 involved German hosting provider Hetzner, which accidentally removed Solana validators from its service, causing more than 20% of active staking nodes (about 1,000 validators) to go offline within a few hours. Despite this, Solana remained fully operational with no outages. Most of the affected validators were successfully migrated to new data centers within a few days, and almost all staking nodes were back online within a few weeks.

Solana Validator Hosts by Stake

Solana validators are spread across 135 different hosts, led by Teraswitch, a private US company that hosts 24% of validators, and Latitude.sh (formerly Maxihost), a Brazilian provider of low-cost bare metal servers that hosts 19%. Together, these two providers account for 43.4% of the market.

Other popular hosts include French cloud computing company OVHcloud (8.65% share) and Lithuania's Cherry Servers (8.45% share).

Solana Validator Hardware Requirements

As a high-performance, high-throughput blockchain, Solana’s node requirements are higher than most of its peers in the industry. 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 higher, 2TB combined or larger. High TBW
• No GPU required

In practice, Solana’s bandwidth requirements make home operations impractical, so validators are primarily run by bare metal servers in dedicated data centers.

Solana Client Diversity

Solana was launched with a single validator client written in Rust, developed by Solana Labs. While the Solana Labs client is no longer actively updated, a forked version called Agave is still in use. Complete reliance on a single client implementation is a major manifestation of centralization, as it introduces the risk of critical software bugs that could invalidate the validity of the entire network.

Increasing client diversity has been a priority for the Solana community, and with the launch of Firedancer, this goal has finally been achieved.

Solana Clients

Currently, several Solana client solutions are running or in development:

• Agave: A fork of the original Solana Labs client, written in Rust and maintained by Anza, the Solana software development company.
• Firedancer: Maintained by Jump Crypto, it is a complete rewrite of the original client in C.
• Frankendancer: A hybrid validator that combines the networking stack and block production components of Firedancer with the execution and consensus of Agave.
• Jito: A fork of the Agave client built by Jito Labs that introduces extra-protocol blockspace auctions to provide more economic incentives for validators through tipping.
• Sig: Syndica’s read-optimized Solana validator client written in Zig.

In addition, Mithril is a client written in Golang developed by Overclock that can be used as a validating full node with lower hardware requirements.

Having multiple full-time core engineering teams reviewing each other’s code bases greatly increases the likelihood of finding bugs while promoting knowledge sharing and collaboration. “We learned a lot from the Firedancer customer team; they came up with a lot of really smart solutions,” Anza engineer Joe Caulfield noted in a recent interview. In addition, both Agave and Firedancer have launched bug bounty programs.

Solana Client Diversity vs. Ethereum

Solana and Ethereum are the only L1s that offer 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% usage.

On Solana, the Jito client currently accounts for 88% of staking nodes. However, this landscape is expected to change significantly over the next 12 months as new clients (Frankendancer and Firedancer) are gradually introduced and integrated.

Developer Decentralization

In the book "Quantitative Decentralization", Balaji believes that developer decentralization is a key factor in the blockchain ecosystem, emphasizing the importance of minimizing dependence on individual contributors and reducing "key person risk".

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

Agave validators, maintained by Anza, a software development company founded in early 2024, play an important role in this area. Anza had about 45 employees when it was founded, about half of Solana Labs' previous workforce. In addition to managing Agave, the Anza team also contributes to the broader Solana ecosystem by developing projects such as 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 26,408 commits, but the data is not perfect in terms of raw commit counts and does not fully reflect the depth of individual contributions. It is worth noting that most commits are written by a small number of developers, mainly senior engineers and Solana's co-founders, in addition to a long list of small contributors.

In contrast, popular Ethereum clients Geth and Nethermind also show similar patterns of "centralization" of contributors in the larger community. Geth has 1,098 contributors, while Nethermind has 142. Among them, more than half of Geth's commits are attributed to three core contributors. Among all Nethermind commits, two developers contributed more than 50%.

Firedancer client code base contributors

The Firedancer client is developed by a small team led by Kevin Bowers of Jump, a well-known high-frequency trading company in the United States, and currently has 57 contributors and 3722 commits. Given that Firedancer is a relatively new project (the first commit dates back to August 2022) and was only recently launched on the mainnet, the diversity of contributors is still limited.

Solana Ecosystem Developers

Within the broader Solana ecosystem, the geographic diversity of the developer community is unquestionable. Solana’s biannual online hackathons are among the most well-attended in the world and have played an important role in fostering some of today’s most successful Solana protocol and application teams, including Tensor, Drift, Jito, and Kamino.

The most recent Radar attracted 13,672 participants from 156 countries, with India, Nigeria, the United States and Vietnam being particularly well represented.

In addition, as a network connecting Solana creatives, developers, and operators, Superteam has now expanded to 1,300 members in 16 countries. Its localized chapters promote collaboration by hosting events and shared workspaces. In addition, the Solana Allstars Ambassador Program, run by Step Finance, has been a huge success in Nigeria, with more than 120 gatherings held in many regions, with a constant stream of participants.

Governance

Governance is an important vehicle for decentralization because 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

The Solana Improvement and Development (SIMD) Proposal is the formal documentation required for any substantive changes to Solana’s core components. “Substantive” changes here are defined as those that generally alter the network protocol, transaction validity, or interoperability. Non-substantive changes, such as minor code refactorings or objective performance improvements, do not require a proposal.

While SIMD submissions do not require any permission and can be submitted by any developer or researcher, most SIMDs are submitted by developers on client teams who work full-time on core protocol improvements.

There are two types of proposals for SIMD:

• Standards proposals: affecting Solana core functionality (such as consensus, networking, and API interfaces)
• Meta proposals: involving processes or guidelines outside the codebase

SIMD Process

SIMD typically goes through stages such as idea review, drafting, review, and acceptance. The formal review is conducted publicly on GitHub, and the proposal author is responsible for collecting feedback from relevant core contributors, who decide whether to accept, modify, or withdraw the proposal. Authors are not obliged to implement their proposals, but they are generally recommended to do so as it is the best way to ensure successful completion of the proposal.

If a proposal is accepted, it will typically include an associated feature implementation tracking issue and may need to be activated via Solana’s feature-gate mechanism. Feature gates are activated first on Testnet, then on Devnet, and finally on Mainnet based on timelines.

Discussions on improvements covered the following areas:

• SIMD (Solana Improvement Files) Github Repository
• The Solana Forum’s sRFC (Solana Request for Comments) section
• Solana Technical Discussion Forum
• Social channels, including X (formerly Twitter) and Telegram

Solana Governance Voting Process

SIMDs that make significant changes to the protocol, especially those that impact economic parameters, are subject to a governance vote. The Solana governance voting process is a relatively new initiative, spearheaded by long-time members of the validator community, focusing only on critical issues to maintain engagement and avoid governance fatigue.

To date, three such votes have taken place, including:

• First advisory vote in October 2023 (14.3% of staked nodes participated)
• SIMD33 on timely voting points in April 2024 (53% of staked nodes participating)
• SIMD96 on paying full priority fees to validators in May 2024 (51% of staked nodes participating)

Voting is done via tokens deposited into each validator identity account, with each account receiving tokens proportional to its active stake share in Lamport.

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

In this structure, SOL token holders only participate indirectly by delegating their SOL holdings to validators who vote in ways that 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 evaluated on environmental, social, and governance (ESG) criteria. Solana ranked fourth among L1 in the report’s governance rating, which factors in stakeholder engagement, transparency, and decentralization.

Solana Foundation

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

Currently, SF is led by Executive Director Daniel Albert and President Lily Liu, and is operated by a relatively lean team of 60-65 full-time staff, supervised by the Foundation's Board of Directors.

The foundation's mission is to build a scalable, self-sustaining Solana ecosystem with a focus on education, research, and ecosystem development initiatives. SF organizes large-scale Solana events, including Hacker Houses and the annual Breakpoint conference, to promote developer participation and community building.

The SF Developer Relations team is responsible for maintaining official documentation, social channels, and developer education. In January 2024, SF handed over management of the flagship hackathon to Colosseum, a new independent accelerator co-founded by former SF Growth Director Matty Taylor.

Dan Albert pointed out in a recent debate: "Our job is to free ourselves from the work, find scalable ways to support the network and the ecosystem, and then let go." This shows that SF's long-term goal is to build a network that can sustain itself without supervision.

Summarize

As outlined in this article, Solana’s decentralization is on par with or better than its industry peers across many key metrics, including the Satoshi coefficient, geographic distribution of validators and staking nodes, developer decentralization, and governance benchmarks, while client diversity is currently a notable issue, which the new Firedancer client aims to address.

To strengthen Solana’s decentralization, we can consider the following aspects:

• Explore options for distributing SF responsibilities across multiple organizations
• Improving transparency into foundation spending and grant allocations
• Develop initiatives such as Solana Nations to increase geographic diversity
• Reduce the biggest expense for validator operators, i.e. voting costs
• Explore strategies to reduce validator data export requirements; data export costs are significantly higher for validator operators outside the EU and US
• Encouraging more active participation in governance voting
• Expand Solana’s core contributor and research community to strengthen the network’s development

Currently, the Solana validator set remains somewhat concentrated in the US and EU and relies on a limited number of hosting providers. While this challenge is not unique to Solana, it highlights the potential for improvement in Solana to reduce centralization at this level.

Finally, 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 article.