SLV Publishes Official Guide Highlighting Critical Considerations for Solana Testnet Validator Operations Directly Affecting Evaluation and Participation Criteria

ELSOUL LABO B.V. (Headquarters: Amsterdam, Netherlands; CEO: Fumitake Kawasaki) and Validators DAO have published an official guide within SLV, their open-source Solana node operations platform, outlining critical considerations for operating Solana testnet validators.

This guide consolidates operational constraints and points of attention that should be understood in advance in situations where testnet operations are treated as prerequisites for evaluation and participation, including participation in the Solana Foundation Delegation Program (SFDP) and the use of BAM Testnet.

Testnet Is an Environment Where Evaluation and Participation Prerequisites Are Applied

Solana’s testnet is not merely a verification network. In various programs, including SFDP, validator operations on testnet are treated as prerequisites for participation and evaluation.

What is evaluated is not whether a node can simply start, but whether configurations and behavior close to real-world operations are maintained, and whether inconsistencies arise during upgrades or transitions. Because only observed results are evaluated—independent of operator intent or effort—continuing operations with incorrect configurations or operational decisions can lead to unfavorable outcomes.

Fundamental Requirements for Testnet Validator Operations Under SFDP

Validators participating in SFDP are required to maintain the same class of client configuration on testnet as on mainnet. This is because evaluation targets not just functional availability, but behavior and stability that closely resemble real-world operations.

SLV supports testnet configurations including Agave, Firedancer, and BAM. However, simplifying configurations simply because the environment is testnet, or mixing different client families, may impact evaluation and participation criteria. This guide organizes such operational considerations explicitly.

Failing to Understand Testnet-Specific Constraints Is Itself a Risk

Testnet environments impose constraints that do not exist on mainnet. Many of these constraints are not clearly documented, and beginning operations without understanding them can unintentionally result in exclusion from evaluation or failure to meet participation requirements.

The key point is that these outcomes cannot be avoided through goodwill or effort alone. Operating without understanding testnet-specific constraints and decision points is itself a risk that is reflected in evaluation results.

The Reality of Geographic Constraints in BAM Testnet

When using BAM Testnet, strict network latency constraints apply. At present, maintaining a stable ping latency below 35 ms to BAM nodes is effectively a prerequisite.

Connections from regions that do not satisfy this requirement frequently fail to establish or cannot be sustained. Before using BAM Testnet, operators must verify latency from their target region in advance and should not assume usability if the conditions are not met.

BAM Testnet Node Deployment Status (as of January 2026)

As of January 2026, publicly available BAM Testnet nodes are deployed in three regions: Dallas, New York, and Salt Lake City. Consequently, realistic deployment options for BAM Testnet include these regions or nearby US regions such as Chicago or Los Angeles.

While expansion into EMEA and Asia is planned, these regions should not be treated as operational assumptions at present. This guide organizes these constraints as temporary, rather than permanent, limitations.

Why We Organized Testnet Operational Considerations as an Official Guide Now

With Solana transitioning toward the v3 series and introducing BAM, the surrounding conditions for testnet operations have changed. Configurations and region selections that previously posed no issues now directly affect evaluation and participation outcomes.

Rather than relying on individual inquiries or fragmented information sharing, we determined it necessary to organize these considerations as publicly accessible information so operators can understand risks in advance and avoid unnecessary failures.

The Scope of What SLV Covers and What Operators Must Decide

SLV provides a foundation for reproducing OS-level configurations and operational procedures. At the same time, region selection on testnet and configuration decisions based on external constraints must be made by the operator.

This guide clearly delineates the scope handled by SLV and the areas where operators must make their own judgments regarding testnet-specific constraints. This separation clarifies responsibility and facilitates sound operational decision-making.

The Value of Being Open Source

The operational quality of the Solana network is not sustained solely by a handful of high-performance nodes or highly experienced operators. In practice, the execution quality of the chain emerges from the cumulative operational standards of a large number of validators and RPC nodes on a daily basis.

When operational knowledge and implementations are shared in closed forms, high-quality operations tend to become concentrated among a limited group. This leads to differences in node configurations and behavior, which are observed as voting instability or processing inconsistencies. These issues arise structurally, regardless of individual operator intent.

SLV is published as open source to ensure that anyone can access the same implementations and operational methods. By making operational details and implementations publicly available and verifiable, black-box behavior is avoided, and operators can make decisions grounded in observed behavior and implementation details when issues occur. This transparency serves as a foundation for separating operations from intuition or individual dependence and enables practical, continuous improvement.

At the same time, open implementations ensure that high-quality operations are not confined to internal know-how of specific organizations, but become selectable by anyone. As a result, variations in node behavior and configuration are reduced, enabling large numbers of validators and RPC nodes to operate at stable quality levels.

Choosing open source for SLV is a means of making transparency, verifiability, and reproducibility function in real operational environments. By enabling anyone to select first-class operational standards, Solana can continuously elevate its overall chain-level operational quality.

Positioning of This Guide

This guide serves as a checklist to help avoid failures in Solana testnet validator operations that could affect evaluation and participation. By understanding constraints and decision points in advance, operators can more easily avoid unnecessary evaluation degradation, stake loss, or participation disqualification.

This guide is published as part of the latest SLV documentation. For participation in the SLV user community and related information, please refer to the Validators DAO official Discord.

Solana Testnet Validator Operational Notes Guide: https://slv.dev/en/doc/testnet-validator/operational-notes/
Validators DAO Official Discord: https://discord.gg/C7ZQSrCkYR
SLV Official Website: https://slv.dev/en