Solana Validator Requirements: The Ultimate Guide Updated for May 2026

Solana validator requirements changed significantly on May 1, 2026. The Solana Foundation updated its delegation program criteria, introducing new ASN concentration limits, stricter data center concentration thresholds, mandatory transaction ordering fairness rules, and explicit anti-censorship requirements. Validators already in the Solana Foundation Delegation Program (SFDP) who do not meet the new criteria will have their Foundation delegation removed.

This guide covers every dimension of solana validator requirements as of May 2026: hardware specifications for both Agave and Firedancer clients, the SFDP delegation criteria that determine whether you receive Foundation stake, vote costs and economics, network and port configuration, and the operational standards that determine whether your validator stays competitive.

What Changed in May 2026: The SFDP Update

The Solana Foundation Delegation Program update that took effect May 1, 2026 is the most consequential change to solana validator requirements since the introduction of SFDP itself. Four criteria changed or were formalized:

1. ASN concentration limit now enforced at 25%

Starting May 1, 2026, SFDP participants must operate on an Autonomous System Number (ASN) holding less than 25% of overall network stake. An ASN identifies a network operated by an internet service provider or hosting company. Multiple validators sharing infrastructure from the same provider, even across different physical data centers, may share an ASN. Validators can track current ASN concentration at validators.app.

This rule directly targets the concentration of validators on dominant hosting providers like Hetzner and OVH, which at various points held well above 25% of network stake. Validators currently on over-concentrated ASNs need to migrate providers or lose Foundation delegation.

2. Data center concentration limit tightened to 15%

Starting May 1, 2026, the Data Center Concentration must not exceed 15% for all staked validators at a data center provider. Previously this threshold was higher. Validators receiving a Foundation delegation before the maximum concentration is reached are assigned a seniority score. If a data center later becomes over-concentrated due to new validators arriving, the Foundation removes delegation from validators with the lowest seniority score first.

3. Transaction ordering fairness and anti-censorship requirements

The May 2026 update formally prohibits validators from manipulating transaction ordering for personal gain and from censoring transactions. These requirements were already community norms but are now enforceable conditions for SFDP participation. The monitoring platform Ghost assists in tracking network health metrics relevant to these requirements.

4. Metric reporting requirements

SFDP participants must report metrics in 8 of the last 10 epochs on both mainnet and testnet. This is a consistency requirement, not just a performance threshold validators who fail to report metrics regularly lose delegation even if their performance when reporting is acceptable.

The validator count context matters here: the number of daily Solana validators has dropped from 2,560 in 2023 to around 770 in March 2026 MEXC, a decline attributed primarily to the high cost of operating a node. The May 2026 update represents the Foundation’s response tightening quality requirements while maintaining the SFDP as a support mechanism for validators who meet the bar.

Solana Validator Requirements: Hardware

Solana is the most hardware-intensive proof-of-stake chain to validate. The solana validator requirements for hardware are not aspirational running on underspecced hardware means missed votes, lost rewards, and inability to attract delegators.

Three developments have raised the hardware bar entering 2026: Firedancer’s tile-based architecture is now live on mainnet, SIMD-0256 raised compute-unit limits to 60 million+ per block (with SIMD-0286 potentially raising this to 100 million), and NVMe Gen5 drives are now price-competitive with Gen4.

CPU

Solana validators are unusual in the PoS landscape because they require both high single-core clock speed and high core count simultaneously. High single-thread performance reduces vote latency. Firedancer’s tile-based parallelism rewards total core count.

The critical rule: always use a single-socket configuration. Dual-socket systems often introduce latency and NUMA-related issues that degrade Solana’s performance. Frequency boost must be enabled in BIOS.

Minimum viable (testnet):

• 12-core / 24-thread at 2.8GHz+
• x86_64 architecture with AVX2 support.

Production mainnet (Agave):

• AMD EPYC 9354 or equivalent, 24+ cores.
• Single socket, 3.5GHz+ base clock, 4GHz+ boost.
• AVX-512 support for Firedancer.

Production mainnet (Firedancer):

• AMD EPYC 9354P or 9355 (32 cores), single socket.
• 3.75GHz+ boost clock.
• AVX-512 mandatory.
• NUMA-optimized configuration.
• XDP-capable NIC (required for Firedancer’s kernel-bypass networking).

AMD EPYC dominates the Solana hardware compatibility list (solanahcl.org). Intel Xeon is viable, but AMD’s memory bandwidth and core density at comparable price points have made it the operator’s default.

RAM

Memory is the second critical bottleneck in solana validator requirements. Solana validators load large account states into memory, and RAM becomes a bottleneck when block height increases, the accounts database grows, or transaction volume surges.

Minimum viable (testnet): 128GB ECC DDR4.

Production mainnet (Agave): 256GB ECC DDR4 minimum, 512GB recommended.

Production mainnet (Firedancer): 384-512GB ECC DDR4/DDR5.

Firedancer has additional memory configuration requirements beyond capacity. It requires specific HugeTLBfs configuration: /mnt/.fd/.huge (2MB pages, min_size=241MB) and /mnt/.fd/.gigantic (1GB pages, min_size=27.9GB). These must be configured at system boot and after each restart. Firedancer also requires root privileges during initialization for kernel-bypass networking setup, then downgrades to a specified user for runtime security.

ECC (Error Correcting Code) RAM is mandatory, not optional. RAM errors on Solana translate directly to missed votes and lost rewards.

Storage

Storage is the most complex dimension of solana validator requirements and the dimension where misconfiguration causes the most operational problems.

Solana requires a split storage configuration, ledger and accounts on separate physical disks, because their I/O patterns are incompatible. The ledger is append-only with heavy sequential writes. Accounts require heavy random I/O. Putting both on one disk destroys performance for both.

Ledger disk:

• 1TB+ NVMe (Gen4 minimum, Gen5 recommended for new builds).
• Enterprise-grade, high TBW (Total Bytes Written) rating.
• Sequential write performance is the primary spec.

Accounts disk:

• 500GB+ NVMe (Gen4 minimum, Gen5 recommended).
• Enterprise-grade, high IOPS for random access.
• Random read/write performance is the primary spec.

OS disk:

• 500GB+ separate NVMe or SSD.
• Standard enterprise grade.

SATA SSDs are not viable for solana validator requirements. Consumer-grade NVMe will degrade rapidly under Solana’s sustained I/O load. Only enterprise NVMe with sufficient endurance ratings should be used for production validators.

Network

Minimum: 1Gbps symmetric.

Production mainnet: 10Gbps symmetric strongly recommended, especially for mainnet.

A dedicated public IP address is preferred. It is not recommended to run a validator behind a NAT.

Solana does not use a sentry node architecture like Cosmos. The validator IP is public-facing by design. Firewall configuration matters more than network topology for security.

Required ports:

8000-10000/udp - Solana gossip, turbine, repair (dynamic range)
8000-10000/tcp - Solana RPC and streaming
8899/tcp        - JSON-RPC (restrict to trusted IPs only)
8900/tcp        - JSON-RPC pubsub WebSocket (restrict to trusted IPs)

The solana validator requirements for port exposure differ from Cosmos. Do not open RPC ports (8899, 8900) to the public internet on staked mainnet validators. The --dynamic-port-range flag limits the UDP range to a configurable 13-port window.

Solana Validator Requirements: Client Software

As of May 2026, the solana validator requirements include three active client options, each with different performance characteristics and SFDP implications.

Agave (v3.1.11+ required for mainnet as of epoch 955)

Agave is the Rust-based client developed by Anza Labs, forked from the original Solana Labs validator. It is the stable default and the most widely deployed. SFDP requires Agave validators to run at minimum version 3.1.11 for epoch 955, updating to 3.1.13 from epoch 956 onward.

Firedancer / Frankendancer (v0.819.30111+ required for mainnet as of epoch 955)

Firedancer is the high-performance C/C++ client developed by Jump Crypto. It is NUMA-optimized, uses tile-based parallelism, and implements kernel-bypass networking via XDP. Firedancer validators achieved +18-28 basis points improvement in skip rate reduction, 15% fewer missed voting credits, and fuller blocks averaging 47M versus 44.8M compute units under Agave. Everstake

Frankendancer is a hybrid client combining Firedancer’s networking and block production components with Agave’s runtime. It is the recommended path for operators migrating to Firedancer from Agave. Full Firedancer (without Agave components) is the higher-performance target but requires more operational adjustment.

Validators running Jito-Solana on mainnet must also run Jito on testnet as of the May 2026 SFDP update a new requirement that catches validators running MEV-optimized clients selectively.

Software version compliance:

# Mainnet required versions (as of epoch 955, May 2026)
Agave minimum:       3.1.11
Frankendancer min:   0.819.30111

# Mainnet required versions (epochs 956-958)
Agave minimum:       3.1.13
Frankendancer min:   0.820.30113

# Testnet required versions (epochs 942-945)
Agave minimum:       4.0.0-beta.4
Frankendancer min:   0.902.0-beta.40002

The minimum software version is updated 48 hours after each new release. Validators must update promptly, being on an outdated version is one of the most common reasons SFDP participants lose delegation.

Solana Validator Requirements: SFDP Delegation Criteria

The SFDP is not mandatory for running a validator, Solana remains permissionless. But for most validators who do not have substantial self-stake or community delegation, SFDP participation is the economic mechanism that makes validator operation viable.

The full solana validator requirements for SFDP participation as of May 2026:

Stake matching:

Beyond the residual delegation (a base amount all qualifying SFDP participants receive), validators earn matching stake. The Foundation matches external stake at a ratio currently being reduced from 1:1 (100,000 SOL cap) toward 0.5:1 (50,000 SOL cap) according to a published schedule. This creates a direct incentive to attract community delegation: every SOL of external stake increases your Foundation delegation.

Stake matching example at current parameters:

A validator with 10,000 SOL in external stake receives approximately 5,000 SOL in Foundation matching at a 0.5 ratio. A validator with 100,000 SOL in external stake receives the full 50,000 SOL matching cap.

Skip rate requirement for stake matching:

The 5-epoch average skip rate must not exceed the cluster average skip rate plus 5%. This is the solana validator requirement that most directly reflects hardware and network quality: high skip rates signal that the validator is missing its leader slots, which correlates with insufficient CPU performance, high network latency, or inadequate storage I/O.

Solana Validator Requirements: Economics and Vote Costs

The economics of running a Solana validator are materially different from other PoS chains and represent the most significant operational barrier in the solana validator requirements.

Vote transaction costs:

Every block Solana produces, validators must submit a vote transaction to signal consensus. Voting requires sending a vote transaction for each block the validator agrees with, which can cost up to 1.1 SOL per day. Solanalabs Across a full year, this totals approximately 300-350 SOL in vote fees. At SOL prices above $100, this represents $30,000-$35,000 per year in pure vote transaction costs before hardware, hosting, or labor.

This is the structural reason the validator count has declined from 2,560 in 2023 to around 770 in early 2026. Small validators without sufficient stake to generate more rewards than their vote costs incur a net loss every epoch.

SFDP vote cost coverage:

For new SFDP participants, the Foundation covers vote costs on a tapering schedule:

• Months 1-3: 100% covered.
• Months 4-6: 75% covered.
• Months 7-9: 50% covered.
• Months 10-12: 25% covered.
• After 12 months: no coverage.

This gives new validators a 12-month runway to attract sufficient stake to self-fund vote costs before Foundation support ends.

Break-even stake estimate:

At current inflation rates and SOL staking yields of approximately 7-8% APY, a validator needs roughly 5,000-8,000 SOL in total stake to generate enough epoch rewards to cover vote costs. At SOL prices above $100, this represents $500,000-$800,000 in bonded stake at minimum to break even on vote costs alone before hardware and hosting.

This economics calculation explains why the SFDP’s stake matching mechanism is essential for new validators: it provides the foundation stake needed to approach break-even while the validator builds community delegation.

Hardware and hosting costs:

Bare metal is the standard choice for mainnet validators. Monthly costs run $800-$1,200 for a well-specified server. Annual hosting cost for a production Solana validator is approximately $10,000-$15,000. For Firedancer operators who need higher-spec hardware, total hardware plus hosting can reach $18,000-$24,000 annually.

Solana Validator Requirements: Testnet Participation

Testnet participation is a mandatory element of the solana validator requirements for SFDP participation, not an optional additional step.

A validator’s testnet node must meet all baseline criteria for at least 5 of the latest 10 testnet epochs for the validator’s mainnet node to receive Foundation delegation. The baseline testnet criteria are less strict than mainnet residual criteria (85% of cluster average vote credits vs. 97%, 100% maximum commission vs. 5%), but they must be met consistently.

The requirement to run and maintain a testnet node is operationally significant. It means every SFDP participant runs a minimum of two nodes: one mainnet validator and one testnet validator, both requiring monitoring, software updates, and operational attention. This doubles the infrastructure overhead relative to the hardware cost alone.

Testnet node configuration requirements:

# Testnet software versions (epochs 942-945, April 2026)
Agave minimum: 4.0.0-beta.4
Frankendancer minimum: 0.902.0-beta.40002

# Testnet metric reporting
Required in 8 of last 10 testnet epochs

# ASN concentration
< 25% of testnet network stake

# Infrastructure concentration
<= 100% (more permissive than mainnet)

Importantly, if a validator does not receive stake on testnet for 10 epochs, they also do not receive stake on mainnet. Testnet performance is a qualifying condition for mainnet delegation, not an independent track.

Operational Requirements Beyond Hardware

The technical solana validator requirements are necessary but not sufficient. The operational requirements that determine whether a validator remains competitive include:

Automated upgrade workflow:

Solana releases happen frequently, and the window between a new release and the SFDP minimum version update is typically 48 hours. Validators must have an automated or near-automated process for detecting new releases, testing, and deploying. Missing a software version update is a direct SFDP disqualification trigger.

Monitoring stack:

A production Solana validator requires real-time monitoring of vote credits per epoch, skip rate (rolling 5-epoch average), peer connectivity, vote account balance (must maintain sufficient SOL for vote fees), and slot leader performance during assigned leader slots. See our blockchain node monitoring guide for the complete Prometheus and Grafana stack configuration applicable to Solana.

Vote account management:

The vote account must maintain a sufficient balance to pay for vote transactions. If the vote account balance drops to zero, the validator stops voting and immediately starts losing credits. Standard practice is to maintain a minimum buffer of 0.5-1 SOL in the vote account and automate top-ups from the validator identity account.

# Check vote account balance
solana balance VOTE_ACCOUNT_ADDRESS

# Transfer from identity to vote account
solana transfer VOTE_ACCOUNT_ADDRESS 0.5 \
  --from IDENTITY_KEYPAIR \
  --fee-payer IDENTITY_KEYPAIR

Key management:

Solana validators use two key pairs: the identity keypair (the validator’s public identity on the network) and the vote account keypair (used for consensus voting). The identity keypair should be stored on hardware security keys where possible. Unlike Cosmos, Solana does not have a widely adopted TMKMS equivalent for distributed signing; key security relies on operational discipline rather than protocol-level tooling.

The Complete Solana Validator Requirements Checklist

Hardware (Agave mainnet):

• Single-socket AMD EPYC 9354+ or equivalent, 24+ cores, 3.5GHz+
• 256GB ECC DDR4 minimum, 512GB recommended.
• 1TB+ enterprise NVMe for ledger (Gen4/Gen5).
• 500GB+ enterprise NVMe for accounts (separate disk).
• 500GB+ NVMe or SSD for OS (separate disk).
• 10Gbps symmetric network with dedicated public IP.

Hardware (Firedancer mainnet additions):

• AVX-512 CPU support mandatory.
• 384-512GB ECC RAM.
• XDP-capable NIC (Intel X550 or equivalent).
• HugeTLBfs configured at boot.
• NUMA-optimized single-socket layout.

SFDP compliance (May 2026):

• Agave >= 3.1.11 (epoch 955) / >= 3.1.13 (epoch 956+).
• Frankendancer >= 0.819.30111 (epoch 955) / >= 0.820.30113 (epoch 956+).
• Vote credits >= 97% of cluster average.
• Commission <= 5%
• ASN concentration < 25%
• Data center concentration <= 15%
• Total stake < 1,000,000 SOL
• Testnet participation: 5 of last 10 epochs.
• Metric reporting: 8 of last 10 epochs (mainnet and testnet).
• 24-hour responsiveness.
• Jito testnet required if running Jito on mainnet.

Operations:

• Testnet node running and meeting baseline criteria.
• Automated software update process.
• Vote account balance monitoring and top-up automation.
• Skip rate monitoring with alert at cluster average + 3%
• On-call coverage for cluster incidents and upgrades.
• Identity and vote keypair security procedures.

Conclusion

Solana validator requirements in 2026 are more demanding than at any previous point in the network’s history. The May 2026 SFDP update has formalized ASN and data center concentration limits that force validators to actively manage their infrastructure placement, not just their performance. The economics of vote costs make stake threshold a real barrier to sustainable operation without SFDP support. And the introduction of Firedancer as a mainnet-viable client has raised the hardware bar for operators who want to remain at the performance frontier.

The validators who survive and grow in this environment are the ones who treat infrastructure placement, software currency, testnet participation, and operational monitoring as first-class requirements, not afterthoughts.

At The Good Shell we design and operate Solana validator infrastructure for Web3 protocols and institutional operators who need to meet the May 2026 solana validator requirements without building the full operational stack themselves. See our Web3 infrastructure services or our case studies to see what production-grade Solana operations look like.

For the authoritative and always-current solana validator requirements, the Solana Foundation Delegation Criteria page is the primary reference, the numbers update epoch by epoch.