The Heartbeat of a Global State Machine
A deep dive into the importance of and challenges faced by validators on Solana
Special thanks to Solana validators Martin Tromp (from Superfast), 7Layer from Overclock, and Lucky Staking for helping me with first-hand insights on the topic. I’ve referenced them by name throughout this piece.
Solana is one giant global state machine that unifies the entire world at the speed of light (as fast as physics allows) so that we can have this magical, composable, giant interface for finance, gaming, social, and all the stuff that we want to do with cryptography. - Anatoly Yakovenko, cofounder of Solana
Solana’s mission is an ambitious one. The project started with the goal of reducing information asymmetry in global financial markets but has since morphed into something much bigger - the fastest platform for trustless and permissionless human coordination. Currently worth over $60b, Solana secures almost $2bn of financial assets and is home to 10m monthly active addresses, 650+ projects, and 2500+ monthly active developers.
At the center of it all lie the chain validators. These are the nodes, the individual computers, that make up the global state machine. They’re run by various entities, from corporate giants to small independent operators. They’re located across the globe, from the US to Europe to Africa to India. Thousands of computers form one planet-wide mesh, working in synchrony to keep the Solana network ticking.
Over the past few weeks, I’ve immersed myself in the world of Solana validators. In this piece, I break down what it takes to become one, the rewards they earn for securing the network, the challenges they face across different dimensions, and how they do their bit to contribute to the overall growth and health of the ecosystem.
But before we get into all of that, let’s start with understanding why validators are the pillars of the House of Solana.
What do validators do?
You get a gist of the role validators play from the first figure in the Solana whitepaper.
Validators are independent computers that secure the Solana network by processing and verifying transactions. Each transaction is nothing but a change to one or more pieces of state (like a balance, a variable, or an NFT owner) on the global computer. Each validator maintains a copy of the current state, processes the changes made by incoming transactions, and votes on whether they agree on the new state. This repeats on 1600+ separate computers across the world, in real-time, and when a majority of them agree on the new state, there is consensus.
That’s the high level. Let’s go into some detail.
The basic unit of time on the Solana network is a 400ms slot. Each slot has a leader who receives transactions from across the network, verifies if they are valid, bundles them into a discrete unit called a block, and propagates it to all other validators in the network. Each verifier then independently processes the block and, if their final state change matches the one they received from the leader, casts a vote that signals validity. Once the leader receives a majority of votes, they signal consensus and the network proceeds to the next slot.
The leader changes every four slots. 432,000 slots make up an epoch (around 2 days).
Each validator also has a delegated SOL stake. This is their skin in the game. If they vote correctly, they secure the network, earn rewards, and their stake increases. If they vote incorrectly, they weaken the network and face punishment in the form of their stake being reduced (this process is called slashing). In this way, the SOL token acts as a coordination mechanism that aligns the interests of all actors in the ecosystem.
A validator’s delegation can come from either their own SOL, users looking to earn a staking reward, liquid staking pools, or the Solana Foundation. The higher their delegation, the likelier they are to become a leader, and the greater their rewards. We’ll look at all of this in more detail in a bit.
Solana is a high throughput, low latency blockchain. Blocks, as we discussed, are processed every 400ms. This cannot be achieved without the support of the validators. Put another way, the validators are Solana. They make up the individual strands of the blockchain. If there is a problem that plagues them, it plagues the entire ecosystem. And vice versa.
Nuts and Bolts
Being a validator for Solana prepares you to be the validator for any other blockchain. It is the most demanding. - Frank Mathis, GenesysGo
We’ve understood what validators do and their importance in securing the network. But what does it take to become one in practice?
Hardware
To become a high throughput, low latency blockchain, Solana had to adopt an architectural (and philosophical) strategy that was very different from predecessors like Ethereum. While competitors focussed on maximizing the number of computers that could run nodes, Anatoly realized this would always come at the expense of speed.
Thus, Solana adopted a hardware-first approach. To keep up with the demands of the network, each validator node needs to be a high-performance computer with fast, high-bandwidth internet. There are different ways of approaching this.
Self Hosting
This video from Solana provides a great overview of what it takes to self-host a validator. In summary:
A multi-core CPU with low thread counts and high-core clock frequencies. AMD third-generation CPUs currently meet this requirement and are the preferred choice.
A minimum of 128GB RAM (though 256GB is recommended)
Monthly egress bandwidth of 50-300 terabytes depending on validator delegation and location. To be high-performing, this translates to a dedicated 10 gb/s connection, with high availability. This can make running nodes in regions with unreliable electricity challenging.
The struggles with running a node in a region with electricity outages (source) The closer a validator is to a network, the faster it can receive and send consensus messages. This leads validators to cluster geographically.
Validator clusters in the US, Europe, and Japan (source) Validators are securing a financial network with billions of dollars at stake. Following best security practices is as important for them as anyone in crypto.
Hyperscalers
You can also run nodes on hyperscaler cloud platforms like AWS and Azure. While this reduces upfront costs, the machines on these services are general-purpose and not specifically designed to run high-performance blockchain nodes. This means that in practice, validators who take this route often can’t keep up with the network, leading to lost revenue.
Bare Metal Providers
Bare metal computer servers are cloud services that provide customers with dedicated computers that are not shared with other tenants. Latitude is one such service with globally distributed infrastructure specialized to run blockchain nodes. Using a bare metal can also be highly cost-efficient, with services starting from $250/month.
It is crucial for a validator to choose the right hardware setup. 7Layer’s biggest concern as a validator is the fear of server outages, leading to downtime and lost rewards.
How does the network scale?
High-performance hardware is at the core of Solana’s philosophy. This means that when the network decides to scale, as it will someday, validators will be expected to upgrade their hardware to do so.
Whether self-hosted or using hyper scalers and bare metal providers, this will lead to increased costs.
Neither Martin nor Lucky Staking mind this increased cost, though. They look at scaling as one of Solana’s competitive advantages and are prepared to upgrade and make changes accordingly.
Clients
A validator client is the software that enables validator computers to perform their duties. In other words, they process transactions and take part in consensus.
Currently, the Solana ecosystem has two client choices:
The default client, shipped when Solana launched in 2020
The more recently released Jito-Solana client (covered in more detail later), which is a fork of the default client
Relying on a single base client is incredibly risky. The default client was built many years ago and shipped to market quickly. Apart from being unoptimized, it also carries the risk of zero-day bugs that if exposed, can take down the entire network (again, since all validators currently run variants of the same software).
Mature blockchains need multiple clients (Ethereum currently has six while Bitcoin has over ten). Anatoly calls this Solana’s final single point of failure. Apart from directly affecting the validators, this also concerns every other stakeholder in the ecosystem.
Enter Firedancer, an independent Solana validator client built by the folks at Jump. Here are some reasons this is an incredibly important development:
Jump is building the client from scratch in the programming language C (the original client is in Rust). Every piece of software has bugs. The same goes for the default client. However, it is extremely unlikely for two completely different software implementations to have the same type of bugs. In other words, the default and Jump client will act as fail-safes for each other.
Solana has halted (stopped producing blocks) multiple times in its history (most recently this month). These occur not because of the design of the protocol itself but because of bugs in the client software. The Jump client will look to address these issues at a fundamental level.
By picking lessons from the current implementation and other general developments in the blockchain space, the new client will make Solana exponentially faster and more efficient. Minimum hardware requirements would drop to 8 cores and 16GB RAM, much less than currently needed. This also means that if validators maintain the same hardware, the network capacity can increase 2-4x, without additional changes (more revenue for validators).
This post provides an excellent technical breakdown of Firedancer.
Currently live on the test net, Marty says Firedancer is “the most important project in crypto right now” because of its implications on the future of Solana and other fast blockchains.
It will be interesting to track the validator adoption of Firedancer. If the performance gains are as substantial as we expect, it could lead to a client ‘flipping’, where most validators make the switch to the new client. There is also the potential of an outage if validators running different clients disagree with each other. However, this is healthy for the chain in the long term and would surface underlying bugs.
Apart from Firedancer, there are two other clients in the works for Solana:
Sig, a read-per-second (RPS) focussed client built in the language Zig
Agave, a fork of the default client that will focus on “ecosystem-wide improvements such as token extensions and Solana permissioned environments”
Rewards
Being a validator on Solana is not easy. It is technically complex, requires being online and available almost all the time, and mandates upfront and recurring investments. Moreover, because of the early-stage nature of blockchain technology in general (and Solana in particular, being less than 5 years old), it is a risky business to get into. Like anything in life, there is an opportunity cost attached.
This makes the design of incentives for an individual or an organization to run a Solana validator very important. Rewards can be broken down into:
Inflation Rewards - rewards received as a % of SOL inflation
Transaction fees (or block rewards) - the leader of a given block receives a % of the fees paid by users for transactions included in that block
Maximal Extractable Value (MEV) - additional profits that can be made via manipulation of the transactions included in a block
Let’s look at each one of these in more detail.
Inflation Rewards
Inflation is the process of new SOL being periodically created and added to the existing supply, with the intention of incentivizing behavior like network security, staking, and protocol growth.
The network’s inflation schedule is determined by three parameters:
Initial inflation rate: 8%
Disinflation rate: -15%
Long-term inflation rate: 1.5%
This is what the inflation schedule graph (and corresponding SOL supply) is expected to look like over time:
According to Solana Compass, SOL inflation currently sits at 5.48%.
What happens to these newly generated tokens? 100% of these go to validators and accounts that delegate SOL to them. An individual validator’s share is roughly calculated as:
Let’s break down the individual factors.
Validator Stake
A validator’s claim to the inflationary reward pool is directly proportional to the percentage of total staked SOL delegated to them. Naturally, reputed and established validators command greater trust and a bigger SOL delegation. As Marty puts it, “Stake attracts stake.” Overall, this can lead to a centralizing effect on the network.
To boost new validators and increase network decentralization, the Solana Foundation runs the Delegation Program. The foundation matches the delegated stake (up to 100k SOL) for validators that meet certain criteria, increasing their rewards and perceptive trust. Note that this program is currently undergoing changes.
Recently, we’ve seen the emergence of liquid staking protocols like Marinade. Users delegate their SOL to Marinade. The protocol then distributes it dynamically among the most high-performing validators. This has boosted revenues for new validators with small delegations but high performance. Another interesting addition to the LST scene is Sanctum. This protocol allows each validator to create their own liquid tokens (instead of relying on an aggregator), against guaranteed instant liquidity. To get into the weeds of LSTs, this post is great.
Both Superfast and Lucky are relatively smaller validators, with about 200k SOL delegated to each. Unsurprisingly, attracting more delegation is the single biggest challenge for both. I’ll cover some non-obvious ways they can do this later in the post.
Commission
The commission is the percentage of inflation rewards a validator distributes to delegators. This varies greatly across validators, ranging from 0 to 10%.
Youtuber Blockchain Bernie, who runs staking service Xandeum, shares some great insights into the thinking behind how a validator chooses their commission in this video.
For new validators, the goal is to maximize their delegation. One way to do this is to set low commissions. This attracts delegators looking for a higher APY. Once established, they can then gradually increase commission, a price users are willing to pay for more trusted ecosystem players.
The Cogent Validator Profit Calculator is a great tool to understand validator profitability. Play around with and you’ll realize that keeping all other factors constant, the commission % is the greatest lever validators have to make more money. Marty’s Superfast, for example, currently charges a 3% commission and thus makes 57% of its total revenue from commissions. If they increase this to 5% (standard for established validators), that number would change to 69%. On the other hand, if they decrease it to 1%, the commission % goes down to 31%. Choosing the right commission at the right moment is the most important decision a validator makes.
This table also illustrates a huge concern for both Lucky and Superfast. Given how competitive it is being a validator, especially at the lower delegation rungs, they often have to compete with validators offering 0% commissions. This is a race to the bottom and might not be sustainable for everyone, eventually leading to validators leaving for other networks. Marty sums up his expectations well - “Pay your validators!”
Voting
A validator’s primary duty is to validate transactions on the network. Each epoch has 432,000 slots. Most slots have a block with a set of transactions that validators verify and then vote for. For each vote that is correct and successful, validators earn a credit.
Thus, a validator is incentivized to vote for as many blocks as correctly as possible. This can only happen when they run high-performing nodes (i.e. they meet the hardware requirements). Performance is measured by a parameter called skip rate.
Having a low skip rate is a great way for smaller (or newer) validators like Superfast to punch above their weight and differentiate themselves from the pack. This can help them stand out among delegators (build more trust) and stand a chance to receive more stakes from the emerging liquid staking protocols.
(Michael Hubbard of Laine, a top Solana validator, has a great (albeit slightly outdated) blog post on the nuances of voting here)
There are, however, some problems validators face with the current voting process.
At the time of writing, voting costs about 2 SOL per epoch (or 1 SOL per day). Every validator, irrespective of how big their stake is, has to pay this. Over a year, at current SOL prices, these fees add up to almost $40k. This amount can be prohibitive for new or smaller validators, and carry centralization effects.
The Solana Foundation, for its part, acknowledges this and addresses it by fronting some of these costs for validators that take part in the delegation program.
Upcoming changes to subsidize voting costs Because voting transactions are treated like any other transaction, there are concerns that their fees are too high relative to the amount of compute they consume. Moreover, voting is what secures the network and leads to SOL becoming more valuable. Yet, if the price of SOL increases, voting costs increase. Validators pay for their own success. Potential solutions could be to move these transactions to a different block space or assign fixed, low fees for them.
In normal circumstances, a block is proposed, validators process it, and send a vote if valid. However, there can be circumstances where the voted-on block is not eventually added to the final chain, leading to the vote (and resources) being wasted. Such wasted votes are a part and parcel of functioning blockchains.
Some validators, however, attempt to game this system via a process called vote lagging. Essentially, they only cast votes towards the end of each slot, once they see a majority of other validators vote towards it. This hampers consensus and artificially inflates their vote credits. SIMD 0033 proposes making credits awarded a function of vote latency as a solution to this. According to the latest Solana Community Validator Discussion meeting, this proposal will be voted on and integrated into the test net soon.
Transaction Fees
Transaction fees are the fees paid by users to include their transactions on a blockchain. They serve three primary purposes:
compensation for validators
blockchains have limited real estate and need a mechanism for spam prevention - transaction fees add a real-time cost to use a chain
defining the characteristics of the protocol and securing its long-term economic stability (the reason people call bitcoin digital gold or ETH ultrasound money)
Each of these is fundamentally important, making transaction fee design a core pillar of any blockchain. From users to validators to app and infrastructure developers, it affects every stakeholder and sets their incentives. Getting it right is crucial.
I’ll break down the fee markets in Solana. A complete analysis is outside the scope of this piece (but is a fascinating rabbit hole to enter) so I will be covering solely the parts that affect a validator.
Status Quo
Let’s start with the existing fee design.
The fee for each transaction consists of two components:
Mandatory Base Fees, fixed at 5000 lamports (0.000005 SOL) per signature (a transaction can have multiple signatures; most have only one) and independent of the computational resources (CUs) used.
Optional Priority Fees, to improve the block inclusion probability of a transaction. This is priced per CU requested for a transaction.
On the successful processing of a transaction, 50% of each of these fees is burnt, and 50% goes to the block leader as a reward.
Some other points to note about the current design:
Each block can process a maximum of 48m CUs (limited to maintain block times of 400 ms).
Transactions declare the maximum CUs they intend to consume (with a limit of 1.4m) and the accounts that must be read- and write- blocked (a proxy for the state they hope to alter) upfront.
Within a block, a maximum of 12m CUs (25% block capacity) can be used for sequential writes to a single account. This prevents one event on the blockchain (say, a hyped NFT mint) from raising prices for all participants and enables pseudo-local fee markets.
Priority fees were added in July 2022 and have changed the economics of the network, consistently making up more than 50% of the total non-vote fees of a block and recently, in a period of high demand, more than 90%. This exposed the high latent demand for block space on Solana and revenue validators were previously missing out on.
With this context, let’s look at some of the problems with each of these two fees and potential solutions for them.
Fixed base fees and spam
This is perhaps the most glaring problem in the current fee design. Since each transaction costs the same base fees, irrespective of how many CUs they consume, it leads to some unwanted behavior among stakeholders:
Developers can be lax with how they design programs and don’t have an incentive to optimize their code.
Say a transaction is estimated to use 100k CU. They can set the max CU value to 500k or 1m, any number, without consequences. However, given the domination of priority fees off late and their dependence on max CU, we should see less of this happening (it’s still a problem!).
Spam is incentivized. Once a financial opportunity (arbitrage, liquidation, NFT mint) arises, bots (or users) spam the network with transactions because of the low base fees. Even if most of their transactions fail, the financial upside would more than cover their failed transaction costs.
Validators (and indirectly users and the network itself) pay the cost for this. Given the limit of 48m CUs per block, invalid or unoptimized transactions directly lead to lost block revenue.
This paper, co-authored by Tarun Chitra (who also speaks about it at Breakpoint), provides a framework to deal with this problem. They propose a multidimensional dynamic fee mechanism, where the fees capture the true cost of inclusion into the network. Let’s break it down.
The argument the authors make is that apart from CUs consumed, certain transactions also incur indirect costs on other dimensions of the network. For example, if an account is locked (state already being processed) and multiple other transactions want to access it, it leads to network congestion and increased latency. This should also be accounted for by, say, increasing the base fee for accessing such accounts.
Parallely, such a mechanism would also disincentivize the same transaction spamming, as the costs to transact on an already in-demand account would increase.
Thankfully, Anatoly also discusses this problem and has co-authored a Solana improvement document (SIMD), inspired by Ethereum’s EIP-1559, to implement an exponential fee for write lock accounts (but not CU used). This proposal is still being actively discussed but is looking to address the spam issue directly and the inefficient CU usage indirectly.
godmodegalactus, a Solana dev, makes the argument to dynamically change base fees based on CU consumed comprehensively in this blog post. He also co-authored a SIMD that proposes more control to an app developer affected by congestion on their account. The consensus in the community, however, seems to lie with Anatoly’s proposal.
Priority Fees
Recall that the introduction of priority fees changed the game in the Solana fee markets, making a bulk of the revenue validators generate from block rewards. While the mechanism in its current form, essentially a first-price auction, has made the economics of the chain more efficient, it still suffers from some fundamental issues.
The most important one is it incentivizes off-chain agreements between users and leaders. Since 50% of the priority fees are burnt, it is more profitable for a leader to collude with a transaction sender, who instead of specifying a fee to get priority inclusion in the block, directly compensates the leader out-of-network.
This creates centralizing effects as validators with more resources and connections will have better access to such opportunities. It also harms the token sustainability (50% of the fee that should have been burnt and will not now) and affects the whole ecosystem. Finally, it reduces overall transparency for delegators and other validators.
A recent solution to this has been the introduction of the Jito-Solana client and auction markets. I will cover this in more detail in the section on MEV.
Another solution, as proposed in SIMD 0096, is to award 100% of the priority fees to the leader (instead of 50%). The rationale is that if this is implemented, leaders would not take the overhead of accepting out-of-network transactions. A clear drawback is the reduction in protocol revenue (fees being burnt).
MEV
MEV, or Maximal Extractable Value, is the profits ecosystem participants can make by influencing the transactions included in a block. It has emerged as an important consideration on every high-activity blockchain. For first-timers, it can be hard to understand. And once you do understand it, you might conclude that it promotes the exact net negative behavior that blockchains promised to resolve. The question of whether MEV is a bug or a feature divides people. But very few can deny that it is an almost inescapable part of any financial system.
The amount of MEV on a chain depends on two factors - the latency and complexity of transactions. When you compare Solana to Ethereum, both of these are currently low. And while speeds will remain low (and maybe get lower), the complexity will keep increasing as Solana matures.
How does MEV on Solana work in practice? Once a financial opportunity on the chain emerges, searchers, in the form of bots operating on the chain, employ one or more of these tactics to profit from it:
Spam: sending multiple transactions in the hope that one of them lands (we discussed this earlier)
Priority fees: bidding with higher priority fees (not always effective because of how transactions are scheduled)
Optimistic transactions: anticipating an upcoming opportunity and sending transactions before or as soon as they appear
Historically, validators (and in turn, stakers) got the short end of the MEV stick, paying to process transactions but not accruing any value from the profits. At one point, arbitrage transactions consumed up to 60% of all CUs, and 98% of them failed.
Enter, the Jito-Solana client.
Jito-Solana Client
Jito is to Solana what Flashbots is to Ethereum, an external participant that aims to dampen the impact of MEV on the chain and share its spoils more evenly with all ecosystem players (stakers, validators, searchers).
The Jito-Solana Client is a fork of the default client and brings order to the MEV chaos. Instead of multiple searchers spamming the leader with transactions, it introduces a 200ms pseudo-mempool where searchers can create MEV-optimized transaction bundles and allow the leader to pick and process the most profitable one. These bundles can also contain tips, which go directly to the validator and allow for priority treatment.
For their efforts, validators get to keep 95% of these tips (with 5% going to Jito). They can then choose to share some of this additional revenue with their stakers.
This great dashboard from ilemi breaks down the impact of Jito so far. The total SOL staked with Jito clients has risen steadily and currently sits at over 60% of all SOL. This has also resulted in increasing tips (additional revenue) for validators. As Solana matures, MEV opportunities will increase. Parallely, the client itself will also improve and more searchers will start using it (flashbots adoption sits at 90% for Ethereum).
Are validators happy with Jito-Solana? You bet. Marty describes the solution as “excellent!”
Improvements
While Jito is a net positive to the Solana ecosystem, there is still room for improvement.
The primary criticism is that the pseudo-mempool and auctioning system runs out-of-protocol i.e. they are not part of the network fee design itself. Remember that the protocol is currently designed to burn 50% of the tips (priority fees) received. For clients that run Jito-Solana, this is not happening, circumventing the design of the protocol.
SIMD 0109 proposes to solve this by giving 100% of the priority fees to leaders, allowing for dynamic tipping, and allowing for validators to dynamically route where tips go. The intention is to bake MEV efficiency into the protocol itself rather than relying on a third party to solve it.
This excellent piece by Umbra Research covers some other long-term MEV considerations in more detail.
Scheduler
The leader of each block receives multiple transactions, sometimes more than a block can accommodate. The scheduler is a component of the client software that determines which transactions enter the processing queue. In Solana’s case, transactions are executed on four threads, each with its own processing queue (with a max limit of 128 transactions). Currently, the scheduler randomly allocates incoming transactions to any one of these threads.
There are two issues with this implementation:
In randomly assigning transactions to threads, during periods of high single account activity (say, an NFT mint), there are state conflicts between both inter- and intra-queue transactions. These transactions have to be dropped and waste the validator’s resources.
The scheduler currently considers CU price when assigning a transaction to a thread. There are many scenarios where this can lead to lost revenue for the validator (example).
Solana is working on a new transaction scheduler that fixes these issues. Andrew Fitzgerald explains it in this blog post (further explained here). The scheduler will maintain a view of which account locks are used by which threads and queues transactions accordingly. Also, transactions will be prioritized by total_fee/cost instead of just total_fee.
Both of these changes would increase validator rewards and network efficiency.
Sustainability
All of this discussion boils down to one question - is running a validator node, given the steadily decreasing inflation and general crypto market cycles, a sustainable business in the long term? Most probably, but it’s complicated.
Let’s start with the costs. The cheapest way to run a Solana node today is a bare metal server. At $350/month (the $250 mentioned earlier is a promotion), that adds up to $4200 a year. Add to this voting fees, around 1 SOL per day or a maximum of ~400 SOL a year, the dollar cost of which depends on the price of SOL but currently adds up to $40k a year.
Revenue in the form of rewards is highly variable. Commission depends on stake, quality, and commission %. Block and MEV rewards vary with Solana’s usage and crypto market cycles.
So the question is: with a declining emission rate, will being a validator always be profitable?
At the lowest point in 2023, block rewards made up only half of the hardware costs. Now, with the SOL price increasing and much more activity, the block rewards are 5x the hardware cost.
That is how much rewards can depend on the price of SOL, which can never be predicted.
The debate around inflation is not unique to Solana. Bitcoin inflation, for example, will completely stop in 2140 and miners will have to rely solely on transaction fees.
The expectation is that in the next few years, blockchains will become essential to society. This will lead to thousands of applications built on them, which will readily compensate the validators (or miners) responsible for their operation. This future would also likely feature much less volatility and stable income.
As long as Solana can remain relevant, keep improving, and attract builders, being a validator will be sustainable. That being said, like last year, there will be hiccups on the journey.
Other Important Things
We’ve covered the core responsibilities of a validator - maintain hardware, run clients, and take part in consensus. We’ve also looked at how validators earn rewards for their efforts.
At the end of the day, most validators are running a business. And the health of their business depends on two factors:
the overall growth of the Solana ecosystem
the amount of SOL delegated to them
This means validators want both their slice and the overall pie to grow. This is a positive sum game and the smartest validators recognize this. This leads to them contributing to the overall ecosystem in many indirect ways.
Tooling
Understanding the crypto zeitgeist and making informed decisions is often about reading and processing data. Solana validators contribute to a vast array of tools and dashboards that add value to the ecosystem and also help promote their staking brands. I made use of many of these in writing this piece but I’m going to list them in one place for the sake of convenience:
Solana Compass: charts that track Solana fees, performance, and staking numbers in one place
Cogent Crypto Validator Profit Calculator: a very handy tool for current and prospective validators to tinker with different scenarios and estimate profitability
Stakewiz by Laine: the de facto tool to compare and rank validators and spread stake across them
Stakeview by Shinobi: tracks validator performance based on some non-standard parameters
Ecosystem Health
Validators pick up various official or unofficial roles to help the ecosystem grow.
actively promoting Solana on Twitter (or fighting the trolls)
drafting official proposals that make the chain more robust
helping potential and new validators on Discord
Out of the box
I also came across some rather unique initiatives from validators:
Cogent has an NFT collection that shares stake revenue with holders
Cogent sells merch
Solana Hub runs a loyalty program that incentivizes additional staking
Laine airdropped block rewards to laineSOL holders, resulting in a higher APY
Newer validators shouldn’t be afraid to identify and plug similar holes in the ecosystem. It’s all about playing long term games.
Conclusion
Yep, so that was almost everything you need to know about being a validator on Solana.
As mentioned earlier, I had to immerse myself in the Solana validator world to write this piece. And by going through all the Discord chats, Twitter threads, meeting recordings, and forum posts, one thing becomes very clear - most validators don’t do this only for more than money. They do it because they believe in crypto, Solana’s tech, and the better internet it enables.
Exploring this topic has been fascinating. Funnily, I’m now passively considering the possibility of becoming a validator. If you made it this far, I’m sure you are too.
I am relatively new to the Solana ecosystem and am sure I’ve made some errors in this post. Feel free to reach out to me over Twitter for any corrections!
Resources
I’ve linked most of the resources I’ve used in the text. There are a few more that I didn’t directly reference but played a role in rounding my understanding.
The Solana Ecosystem by Decentralised.co
Every article in the excellent Helius blog
This thorough commentary on fee mechanics by Eclipse
All Umbra Research pieces on Solana
Official Solana documentation
The Solana Foundation YouTube Channel