Solana validator: hardware requirements and real earnings

Running a professional-level Solana validator requires a server with a processor frequency of at least 2.8GHz (12+ cores), 256GB of RAM, and a pair of 2TB NVMe drives — the rental cost for such hardware starts at $400-600 per month. To reach break-even with current voting costs (~1.1 SOL per day), one needs to attract a stake of at least 40,000 SOL.

Solana hardware requirements for Mainnet-Beta

The Solana network is one of the most hardware-demanding among all Proof-of-Stake blockchains. Unlike other networks where the load is distributed evenly, a solana node constantly processes thousands of transactions per second, which imposes strict limits on the disk subsystem and single-threaded CPU performance.

Minimum and recommended CPU specifications

To ensure stable validator operation, simply having many cores is not enough. Clock speed is critical. Solana utilizes parallel transaction processing (Sealevel), but consensus and voting processes are heavily dependent on single-core speed. It is recommended to use processors such as AMD EPYC 7003/9004 or 3rd and 4th generation Intel Xeon Scalable. The CPU must support AVX2, and the Turbo Boost frequency should exceed 3.5GHz.

RAM and disk subsystem

256GB of RAM is not a "future-proofing" recommendation, but a harsh necessity for operating in Mainnet-Beta. Solana stores account states in memory to ensure high access speeds. If memory runs low, the system will go into Swap, which immediately leads to missed slots (delinquent status). Regarding disks, solana hardware requirements mandate the use of NVMe drives only. Standard SATA SSDs cannot handle the required Input/Output Operations Per Second (IOPS). You will need at least two 2TB drives: one for the operating system and binary files, and the second for the Ledger (transaction history), which is constantly being overwritten.

Component	Minimum Requirements	Recommended (Production)
CPU	12 Cores / 24 Threads @ 2.8GHz	16-32 Cores @ 3.5GHz+ (AMD Genoa/Milan)
RAM	128 GB (Testnet only)	256 GB - 512 GB DDR4/DDR5
Disk	1x 1TB NVMe	2x 2TB NVMe (Gen4) RAID 0/1
Network	1 Gbps Symmetric	10 Gbps (Unmetered traffic)

Validator economics: commissions, SOL staking, and real profit

Launching a solana validator vps or a dedicated server is a high-risk business with a high entry barrier. The main expense item is not the server rental, but the cost of voting transactions. Every validator must send a vote transaction in every block. On average, this costs 1.0–1.1 SOL per day. At current rates, these are significant operating expenses that must be covered either by your own stake or by commissions from delegated funds.

Profitability calculation with a 40,000 SOL stake

Validator income consists of inflation rewards (Staking Rewards) and a portion of transaction fees (including Priority Fees and MEV via Jito). If you have 40,000 SOL in stake (own or delegated), the calculation looks approximately like this:

• Total network Annual Percentage Rate (APR): ~7%.
• Validator income from 40k SOL: 2800 SOL per year.
• Validator commission (e.g., 10%): 280 SOL per year (~23 SOL per month).
• Voting expenses: ~33 SOL per month.
• MEV rewards (Jito): an additional 5-15% to income depending on efficiency.

As seen in the example, with a 10% commission and a 40,000 SOL stake, the validator barely covers voting costs and server rental. To achieve net profit, you either need to increase the sol staking volume to 100,000+ SOL or participate in the Solana Foundation Delegation Program, which doubles your stake if certain conditions are met.

The role of Slot Leader and MEV income

When your validator is appointed as a slot leader, it gains the right to produce blocks. At this point, income increases due to fees paid by users for priority transaction inclusion. Using a modified Jito-Solana client allows you to receive additional tips from traders engaged in arbitrage. In today's reality, operating without MEV optimization makes validation unprofitable for smaller players.

Choosing a strategy: validator hosting and server location

When choosing validator hosting, network topology is critical. Solana is a global network, and latency between validators directly affects profitability. If your server is too far from the majority of other nodes, your votes will arrive later, and you will receive fewer rewards.

Why a standard VPS is not suitable for Solana?

A standard solana validator vps with shared resources (vCPU) will not be able to provide stable block generation times. Virtualization introduces overhead that is unacceptable given Solana's timings (400ms per block). For serious work, only Bare Metal servers are used. However, for learning and participating in Testnet, a powerful VPS with dedicated cores can be an entry point. If you plan to run less demanding nodes, we recommend checking out the material on Ethereum full node on VPS, where disk and CPU requirements are significantly lower.

When choosing a host, consider the following factors:

1. Traffic: A validator consumes between 10 and 30 TB of traffic per month. Look for providers with an unmetered 1 Gbps channel.
2. DDoS Protection: Solana is often a target for attacks, so basic data-center level protection is mandatory.
3. Geographic Decentralization: The Solana Foundation encourages launching nodes in underrepresented regions, providing additional stake bonuses for doing so.

Technical setup of a solana node and system optimization

After selecting the solana hardware and installing Ubuntu 22.04 LTS, it is necessary to perform deep Linux kernel tuning. Standard system limits are not designed for 50,000+ open UDP connections.

System limits configuration

Create a configuration file for system settings:

# /etc/sysctl.d/20-solana-validator.conf
net.core.rmem_default = 134217728
net.core.rmem_max = 134217728
net.core.wmem_default = 134217728
net.core.wmem_max = 134217728
vm.max_map_count = 1000000
fs.nr_open = 1000000

These parameters increase packet receive and transmit buffers, preventing data loss during intensive network exchange. You also need to configure limits.conf for the user running the validator to avoid "Too many open files" errors.

Creating the solana-validator service

Systemd is used for automatic startup and process management. Example of a basic service:

[Unit]
Description=Solana Validator
After=network.target
StartLimitIntervalSec=0

[Service]
Type=simple
Restart=always
RestartSec=1
User=solana
LimitNOFILE=1000000
LogRateLimitIntervalSec=0
ExecStart=/home/solana/bin/solana-validator \
    --identity /home/solana/validator-keypair.json \
    --vote-account /home/solana/vote-account-keypair.json \
    --known-validator 7Np41zEbeRSRoXws3zsJQycScy76Y1Y6mUvAnZfSTX9t \
    --known-validator G949m7vRY896vS96mXA8AL78YvY6mUvAnZfSTX9t \
    --only-known-rpc \
    --ledger /mnt/ledger \
    --rpc-port 8899 \
    --dynamic-port-range 8000-8020 \
    --entrypoint entrypoint.mainnet-beta.solana.com:8001 \
    --expected-genesis-hash 5eykt4UsFvMoq291L39Q2SFS3yNMM9Y6mUvAnZfSTX9t \
    --wal-recovery-mode skip_any_corrupted_record \
    --limit-ledger-size 50000000

[Install]
WantedBy=multi-user.target

Using the --limit-ledger-size flag is critical for saving NVMe space. If not limited, the Ledger will quickly grow and fill all 2TB of disk space. If you are also interested in running other nodes, see the guide on Bitcoin full node on VPS; the principles of disk space management are quite similar.

Infrastructure monitoring and security

Validation is a 24/7 process. Missing even a few hours of operation can lead to significant financial losses and a drop in rating among delegators. Monitoring should cover both hardware metrics (CPU temperature, NVMe wear) and blockchain metrics (skip rate, vote latency).

Using Prometheus and Grafana

Most validators use solana-exporter, which collects data from the RPC interface and passes it to Prometheus. Key metrics to track:

• Skip Rate: The percentage of slots in which your validator failed to produce a block. The norm is less than 5-10%.
• Root Distance: How far your node lags behind the current state of the network.
• Disk IOPS: If disks reach their limit, the validator will start to "lag."

To track errors in automation scripts or custom add-ons, it is useful to implement Self-hosted Sentry, allowing you to receive prompt notifications about process failures.

Key Security

A validator has three main keys:

1. Identity Key: The server's own key. Must be on the disk as it is used to sign messages.
2. Vote Key: The voting account key.
3. Withdrawer Key: The most important key. It is used to withdraw earned SOL. Never store it on the server! Use a cold wallet (Ledger/Trezor).

Migration and Scaling

Many begin their validator journey in cloud services like AWS or Google Cloud but quickly face massive bills for traffic and performance. Switching to dedicated servers (Bare Metal) allows for cost reductions of 3-5 times. We discussed how to effectively migrate infrastructure in our article on moving from AWS to dedicated.

When scaling to multiple nodes (for example, for RPC services), it is recommended to use load balancers and distribute nodes across different data centers to minimize single-point-of-failure risks.

Conclusions

Successfully launching a Solana validator requires a powerful dedicated server with 256GB RAM and fast NVMe disks, as well as a significant stake (from 40,000 SOL) to cover operational voting costs. The optimal strategy is to use Bare Metal servers with high-frequency processors and participate in support programs from the Solana Foundation.