Running a Solana Validator: a full breakdown
“Based on what I have been learning, a new validator can become profitable in about 10 to 20 epochs if everything is done correctly, without needing stake from the Foundation.” — SolDev
Solana’s decentralization is a hotly debated topic.
The hardware and bandwidth requirements to run a node are often weaponized to portray Solana as permissioned or centralized.
There’s also some vagueness around what it would take to run a validator and how profitable it would be.
This article intends to provide some clarity by shedding light on the intricacies of running a Solana validator.
By the end of it, you’ll understand:
- what a validator is and what it does
- the economics of, benefits and challenges associated with running your own validator
- the short-, mid-and long-term realities of running a validator
While I won’t detail the process of getting a validator online, I will link resources for those interested.
This article assumes an intermediate level of understanding of blockchain concepts, especially consensus and Proof-of-Stake. If you’d like to start from there, you can find that here
Outline
What is a Validator and What does it do?
Running a Profitable Validator
Terminology
Before we get started, a few terms will come up periodically, so let’s get them out of the way:
- Node: A computer running the blockchain program.
- Fork: A version of a blockchain that isn’t the main chain yet..
- Slot: the period of time where one block is produced. It can also be called block time.
- Epoch: A block of 432,000 consecutive slots. Not any 432,000 slots, rather distinct blocks of 432,000 slots.
- Epoch-year: The number of epochs in 365 days (calculated with a 400 ms slot time). Exactly 182.5
- Leader: The validator that’s producing the block for that slot
- Client: A client is a version of the blockchain’s program. The base client is the original program. Other clients could be implementing the same functionality in a different language or altering some features to achieve the same result.
With that out of the way, let’s dive in.
What is a validator, and what does it do?
A validator is PoS terminology for a node that participates in blockchain consensus.
In PoS, voting nodes put up tokens as collateral that can be seized or destroyed should they behave maliciously.
Voting nodes are tasked with:
- Creating blocks when they are the leader.
- Verifying and voting for or against blocks when they are not the leader.
Validators are crucial to the network because they effectively decide what is true. The greater the number of validators, the more secure and decentralized the network is. Stake spread is also very important. But all of this is likely not news to you.
Let’s move on to why we’re here.
Running a Validator
Before we move forward, it’s important we make a distinction between validators and RPC nodes on Solana.
In an ideal world, everyone who uses the blockchain would run their own node. These nodes would connect to other nodes to propagate the user’s transactions and verify that the blockchain is true.
In practice, this doesn’t happen because of how technically and financially demanding it is to run a node. For most people, RPC nodes are how we interact with the blockchain.
An RPC node does two things:
- It checks that the forks being voted for are true
- Because an RPC node is connected to other blockchain nodes (including validators), it can submit transactions for processing and provide data about the state of the blockchain. Every time you’ve used a blockchain, you’ve likely used an RPC node.
This article will focus mainly on validators because the economics of operating an RPC node are obscure.
dApps (like wallets) either run their own RPC nodes or pay entities like Helius to use RPC nodes. But these arrangements are done off-chain.
We can see Helius’ pricing here, but we have almost no idea about the operational costs or demand. So it’s hard to say how much profit (or loss) RPC providers make.
Because of this, we’ll focus exclusively on Validators going forward.
For those interested in running RPC nodes, the Solana Tech discord linked at the end of this hosts ann RPC node operator channel. You can ask more questions there.
So, what do you need to run a validator?
A validator operator’s main job (after completing the setup) is to monitor their node and work on improving its performance.
There are two primary things a validator needs:
- Technical expertise and,
- Money.
Everything else is secondary.
Technical expertise is crucial because, as you’ll soon see, running a validator is technically demanding. You need to understand hardware, DevOps, blockchain architecture and backend development if you’re going to be successful.
You can run a node without understanding these things, but you’ll struggle with even the most “basic” things.
Here’s someone who paid more than double what he should have for hardware but ended up struggling to get his node running because the setup just wasn’t right.
You’ll see more examples like this as we move on, have it in the back of your mind that running a node is technically demanding.
Aside technical expertise, running a validator can be expensive.
Let’s break down the requirements.
Node Requirements
To run a validator, you need four things: hardware, bandwidth, stake and voting SOL
Hardware and Bandwidth
These are the official recommendations from the Solana Labs documentation:
Bandwidth: 1 GBit/s symmetric, commercial. 10 GBit/s preferred.
In practice, most validators run slightly more powerful machines but there are no benefits to going overboard.
Stake
There’s no minimum stake on Solana and the network supports native delegation so validators don’t need to (and usually don’t) own all the SOL they stake.
But the more you stake, the more likely you’re selected as leader. The exact amounts you should aim for will be discussed in the economics section.
Voting SOL
On Solana, votes count as transactions, and a validator is expected to vote on every block. It comes out to around 1 SOL per day but we’ll discuss all the nuance in the economics section.
With these four things, anyone can run their own validator.
And now to the big question: How profitable is it?
As a primer to validator economics, we’ll quickly look at a simple overview of Solana’s tokenomics.
Solana’s Tokenomics
Solana’s tokenomics are similar to Ethereum’s; there’s inflation to create new tokens and burning to destroy them. The specifics are a little different.
Solana’s Inflation
When a block is produced, a certain amount of SOL is created as a block reward.
The exact amount depends on the current inflation rate.
Inflation started out at 8% and is designed to go down by 15% every epoch-year. It’s adjusted every epoch and will continue to fall until it hits 1.5%, which is the “terminal inflation rate.”
The inflation for this epoch is 5.466% (February 20, 2024).
If you run the solana inflation command on the Solana CLI, you’ll obtain the current number:
This inflation is currently the only mechanism for creating new SOL tokens.
Sidebar: Inflation can be confusing because it seems like token holders are getting diluted, but that’s not true. You can think of inflation as the price that non-stakers pay to stakers for securing the network. Stakers don’t get diluted; only non-stakers do. It’s simply the cost of decentralization. And even Ethereum runs a similar system.
Solana’s Burning
The current burn mechanism for Solana is very simple: 50% of all fees are burned. SIMD-0096 will stop burning priority fees, but for now, 50% of all fees are burned.
The other 50% is sent to the leader for that slot.
And that’s it.
Now that we’ve broken down Solana’s economics, let’s move on to why we’re here: Validator economics.
Validator Economics
This will also be divided into two parts: the Costs and the Income
Costs
Hardware Costs
If you’re familiar with computer hardware, you probably already have a rough idea of how expensive the recommended hardware is.
It’s more expensive in practice because validator nodes have to be active 100% of the time.
That means a dedicated power and cooling system, backup and replacement components, and full-time staff monitoring the computer.
All of this makes it impractical to run your validator from home.
To work around this, most validator operators use bare-metal servers from Tier 3 data centers for their nodes. Prices can vary widely depending on the location, but Latitude currently charges between $373 and $608 per month for a machine that fits the bill.
Bandwidth Costs
Bandwidth consumption is hard to estimate because it depends on your stake size.
If you’re the leader more often, you’ll send out more data than validators who are leader less often. But the average validator usually processes about 60–100 TB of data per month.
This is another reason to use a data center. If you wanted this sort of bandwidth at home, you’d likely need a dedicated line from your ISP.
Here’s someone who tried to do it from home and is understandably running into issues:
In regards to the costs for a data center, it varies by provider and location.
Latitude charges between $0.64 and $3.60 USD/TB for egress, depending on the region. Ingress is free.
Total costs with a projection of 60–100 TB per month amount to anywhere between $38.4 and $360 per month.
Voting Costs
On Solana, votes count as transactions.
Every validator is expected to vote once per slot.
Each vote costs 0.000005 SOL. Per epoch, that’s 2.16 SOL.
In a year, that amounts to 394.2 SOL and that’s about 1.08 SOL per day.
In practice, this number is slightly lower because slots are not exactly 400 ms but on average, it currently costs about 1 SOL per day to vote.
Voting costs are easily the most significant expense of running a validator and there’s no way to get around them.
Each correct vote earns the validator a credit. At the end of each epoch, the inflation rewards for the epoch are split among participating nodes based on:
- the total number of credits they have,
- and the weight of their stake relative to total stake.
So if your node doesn’t vote, it’ll lose out on rewards at the end of the epoch.
Incentivizing nodes to vote is important because consensus would grind to a halt otherwise.
As to why voting transactions cost actual SOL, Toly says it’s a sort of minimum stake requirement.
There’s community consensus that this cost creates a centralization vector and there are proposed changes that will reduce its effect but we’ll discuss those later.
Opportunity Costs
Staking tokens takes away a lot of their functionality, and like I mentioned already, maintaining a validator is a full-time job.
LSTs, stake pools and protocols like Sanctum are actively working to reduce the impact of the financial opportunity cost. But as an aspiring validator, you should be aware of what you’ll be giving up, especially time.
Those are the costs associated with running a Solana validator.
Now onto the good stuff:
Income
Every validator has two major sources of income and a two (optional) ones depending on what client the validator is running.
Commission
Solana runs native Delegated-POS so validators usually don’t own all their stake. However, inflation rewards belong to stake owners, which means validators usually don’t own most of the inflation rewards.
Commission is the amount a validator charges delegators for its work.
It can be any whole number from 0 to 100%.
This commission is currently the primary source of income for small validators.
Transaction Fees
Like I mentioned earlier, half of all transaction fees from blocks are burned; the other half belongs to the leader for the slot.
MEV Bribes (Jito-Client)
Solana’s native block builder (called the scheduler) is partially random. It isn’t First-In, First-Out (FIFO), or even based on priority fees.
Priority fees improve the chances of transaction inclusion but they don’t control ordering. In essence, paying the highest priority fee doesn’t mean your transaction will be processed first.
Coupled with the naïve and extremely cheap fees, spamming proves more effective at landing transactions on Solana, especially time sensitive transactions like MEV capture.
To put into perspective how bad this is, Jito estimates that 58% of blockspace was filled with failed arbitrage transactions
JitoLabs came up with a solution for this. I won’t discuss how it works (you can find that here.)
The important thing is running the JITO client will get you bribes for processing certain transactions.
Since the JITO bribing arrangement is done off-chain, the bribes don’t count as normal fees, so all the fees from MEV bribes belong to the validator.
Those are the sources of income for a validator.
A validator could choose to capture MEV for themselves but they’d likely be blacklisted when discovered.
So what does all that mean for profitability?
It depends
The biggest problem with understanding validator economics is the number of variables.
If I had to write an equation for profit, it would look like this:
In said equation, the only constants are hardware and bandwidth costs and even those vary between providers and locations.
The other components are harder to estimate:
- Inflation rewards depend on how much stake you have relative to total stake and node performance during the epoch.
- Transaction fees depend on network usage and your node’s performance.
- Voting currently costs about $110 per day today, but only cost $26 per day exactly one year ago.
The point I’m making is that it’s hard to make any definitive projections on profitability so take these numbers with a heap of salt.
At current market conditions, a private validator (100% commission) with average performance would need about 5100 SOL staked to break even.
If you run the Jito client, you’d need about 5,000 SOL.
This, of course, does not account for intangibles like an entire year of your time, the opportunity cost of locking up your tokens, or any change in the variables.
For validators with delegated stake, it’s estimated that it would take about 80k SOL delegated at 5% commission for an average validator to break even today.
You can use Cogent’s Profit Calculator to play around with different variations to get an idea of how much stake it would take to break even under different conditions. It’s an amazing tool.
The key takeaway is if you can raise enough stake, you’ll be profitable.
But what does it take to raise stake and by extension run a profitable validator.
Running a profitable Validator
As you can probably tell by now, running a profitable validator is a difficult and complex task. I think Italo’s words describe it best.
Putting setup aside, the big question is: how do you go about raising stake?
Raising Stake
Aside self-stake, there are four sources of stake on Solana: organic, stake pools, the Solana Foundation delegation program, and the Jito delegation program.
- Organic
Organic stake is getting Solana users to delegate to you directly. It’s very difficult starting out since larger validators have more APY and are more trustworthy, but it’s absolutely necessary for validators at all levels.
2. Stake Pools
Protocols like Marinade and Blaze run stake pools. A stake pool collects tokens and uses an algorithm to delegate the tokens in a way that maximizes network decentralization and APY for users. This is how most validators get their start.
3. Solana Foundation Delegation Program: The Solana Foundation also helps new validators by delegating some of its tokens to them. You could get over 100,000 SOL delegated to you if your validator meets the requirements. The Solana Foundation also temporarily covers voting costs for qualified validators. The only downside is the amount of time it takes to get into the program and KYC.
4. Jito Delegation Program: Jito also runs a similar delegation program. You have to run the JITO client and share your MEV bribes with delegators. Aside that, it’s essentially the same as the Solana Foundation’s program (without the KYC.)
These are the four sources of stake on Solana but knowing where to get stake is not enough; you need to know how to maximize your delegation.
And it boils down to two things: uptime and decentralization.
Uptime
Uptime is the single most important consideration for a validator. Apart from directly affecting how much you earn (through credits), it also affects how likely you are to attract stake.
Uptime affects earnings, and so it affects APY. Poor APY means you’ll struggle to get organic stake. The other sources of stakealso have strict uptime criteria that can disqualify you from getting any delegation.
Nothing else matters if your validator’s uptime is below average.
Decentralization
The second-most important factor is decentralization.
Organic stake isn’t affected by decentralization, but it’s a major metric used by all other sources of stake.
You’re not going to get much delegation if you use a data center that already hosts 4 other validators somewhere in the EU. So you need to factor in what data center you’ll be using and its location when you decide to set up your validator.
There are subtle nuances for different delegation programs, but if you can optimize these two metrics, you could break even in two or three months without needing any stake from the foundation.
So by now, you should have a good idea of how profitable running a validator is (in the short term) and what you can do to maximize it.
An important follow-up question is: does it make sense long-term?
The answer to that question is once again, hard to say.
Long-term sustainability is an even more complex topic because the variables can vary wildly over a long time frame.
So instead of trying (and failing) to predict how the price of SOL and blockspace demand will vary, I’ll highlight a few developments that will significantly affect Solana’s economic structure.
This information in conjuction with what we’ve already discussed should form the basis of your long-term outlook for running a validator.
SIMD-0096
SIMD-0096 proposes that all of the priority fees be sent to the leader. It’s been approved, and when it’s implemented, validator economics will change significantly.
Priority fees made up 92% of all non-vote fees in January.
If the entirety of the priority fees are sent to the slot leader, it will increase income and reduce reliance on inflation for validators.
In other words, validators will be able to do more with less stake.
Better Transaction Fee Model
At the moment, Solana’s transaction structure is naïve.
Transactions are charged based on how many signatures they require, as opposed to how much computation they require.
This structure causes a lot of problems that are better discussed here. All you need to know is that when the ongoing developments towards improving these are completed, votes will cost significantly less than most other transactions.
There is also a push to reserve blockspace for votes.
If votes have dedicated blockspace, there is less risk of votes being cannibalized by user transactions, so lesser fees are required and, by extension, lower voting costs.
Scheduler Improvements
The scheduler is being worked on to increase the efficacy of priority fees.
When these changes are effected, MEV capture will become easier, there will be a significant reduction in on-chain spam and priority fees should jump.
Liquid Staking
According to Dune, 26% of ETH is staked. About 39% of this is done through liquid staking.
On Solana, 67.3% is staked and only 5.1% (of the 67) is done through liquid staking.
There are many possible reasons for this, with DeFi maturity being the most cited.
The reason it’s relevant is that as DeFi begins to mature on Solana, there will be a shift from native staking to liquid staking.
This is good because two of the three biggest liquid staking protocols (Marinade and SolBlaze) actively prioritize decentralization.
In other words, as the ecosystem matures, stake spread should improve and it should reduce the initial friction for beginner validators (provided they have good uptime and decentralization).
SIMD-0033
SIMD-0033 is an approved proposal that will penalize late voting. It was proposed because some validators delayed their votes until after consensus was reached. This allowed them to maximize vote credits because they never voted wrong, but it slowed down consensus.
With SIMD-0033, timeliness will affect the number of credits earned.
I’m mentioning this for two reasons:
- It’s a reminder that node performance is more important than ever.
- It’s also a warning that being a validator isn’t a joke; to paraphrase Toly, it’s cutthroat.
Firedancer
The effect of the launch of the Firedancer client is moot.
It isn’t going to directly increase the value of blockspace and could even theoretically reduce it. But if it really does 10x Solana’s throughput, it’s worth keeping in mind.
Slashing
Solana currently doesn’t have programmatic slashing.
In the event that a node is found to be acting maliciously, validators can decide to slash it, but there’s currently no enshrined mechanism. Once implemented, validator behavior will change to adapt to it. It’s hard to say how it’ll affect validator economics, but it’s important to keep in mind.
So what does all this mean for sustainability?
Overall, the incentives for validators are getting better and more equitable. Competition is definitely getting stiffer, but there’s no reason why a good validator (high-uptime and decentralized) shouldn’t be able to make profit in the near or far future.
Conclusion
Running a Solana validator is expensive and time-consuming. But the network rewards validators that perform well and help improve network decentralization.
If you fall into that category, you can quickly gather stake and break even.
Even if you don’t, running a Solana validator isn’t a blackhole for money. Done right, you can break even quickly without needing any stake from the foundation. Long-term prospects are also bright and the initial friction can only get lower from here.
In a nutshell, running a validator can be a profitable endeavor and isn’t as inaccessible as it may initially seem.
I hope this has answered all your questions.
Links to the validator Discord, Solana Documentation and other helpful resources for those interested are in the next section.
Resources
For those interested in running their own nodes:
Getting Started as a Validator workshop
Further Reading
Proposals to improve Solana’s FTM
SIMD-033 is briefly discussed here
SVM Execution Economics by Toly
References and Acknowledgements
- https://solana.com/docs/economics/inflation/inflation_schedule
- https://www.umbraresearch.xyz/writings/mev-on-solana
- https://www.helius.dev/blog/solana-validator-economics-a-primer
- https://x.com/smyyguy/status/1753415253726015922?s=20
- https://dune.com/cz_5052/etherum-eth
- https://dune.com/ilemi/solana-staking
Many thanks to Cogent, Ferric, Trent.sol, Montchik, Dan Smith, Ryan Chern, Zantetsu (Shinobi Systems) and especially Italo Casas for all their help in creating this.
Is it pretentious to acknowledge Toly?
Italo runs the SolDev Validator; profits from the validator are used to fund onboarding new devs to Solana. Feel free to support him directly. He’s doing great stuff for the ecosystem.
Cogent also run an amazing validator and fund research; you can find them here.
