# ☀️ Approved list criteria (/validators/approved-list-criteria) The Vault delegates to validators on its approved list. This page covers the criteria the [Validator Board](/stakepool-application/validator-board) reviews before it approves a validator, and the requirements a validator must keep meeting to stay on the approved list. Banner: A careful reviewer inspects a cream validator server and arranges blank orange checklist cards beside a magnifying glass. ## How approval works [#how-approval-works] The Validator Board is made up of validators from inside The Vault's stake pool who currently serve as board members. The board reviews each application and votes on the validator's ecosystem contributions. When a validator passes the board's review, the validator is approved and joins the approved list. There is no waitlist. [Approved validators](/approved/approved-validators) can begin participating in The Vault's delegation programs: the [Direct Stake Leaders bucket](/delegation/direct-stake-leaders-bucket) and the [Elite Performance bucket](/delegation/elite-performance-bucket) (Figure 15.3). To apply, see [Validator application process](/stakepool-application/validator-application-process). The Validator Board reviews each application and votes on ecosystem contributions; a validator that passes the review joins the approved list with no waitlist and can participate in the Direct Stake Leaders and Elite Performance buckets. Figure 15.3: How approval works ## Validator performance evaluation [#validator-performance-evaluation] Validator performance is evaluated on uptime and downtime (Figure 15.4). ### Measuring uptime and downtime [#measuring-uptime-and-downtime] Validator uptime and downtime are measured using existing tools: * Stakewiz provides uptime tracking. * The Dune Validator Dashboard shows uptime for the last 30 days using Stakewiz data. ### Uptime evaluation factors [#uptime-evaluation-factors] The Stakewiz API calculates validator delinquency based on the number of minutes a validator has been delinquent. ### Minimum epochs required for evaluation [#minimum-epochs-required-for-evaluation] The number of epochs needed for an evaluation is: * Preferred: 20 epochs * Minimum: 10 epochs Stakewiz tracks uptime, its API calculates delinquency by minutes, the Dune Validator Dashboard shows the last 30 days of uptime using Stakewiz data, and an evaluation requires at least 10 epochs with 20 epochs preferred. Figure 15.4: How performance is evaluated ## Approval standards [#approval-standards] The standards for approval are: * Validators must meet uptime requirements. * Validators must adhere to commission limits. The Validator Board weighs these factors when it approves or removes a validator (Figure 15.5): * Ecosystem contribution * APY (vote credits) Approval requires validators to meet uptime requirements and commission limits, while the Validator Board weighs ecosystem contribution and APY from vote credits when approving or removing a validator. Figure 15.5: Approval standards ## Delinquency management [#delinquency-management] Delinquency is graded by level and tracked with Stakewiz. ### Defining delinquency levels [#defining-delinquency-levels] The delinquency levels are (Figure 15.6): * Excessive delinquency: More than 8 hours of delinquency over the past 30 days. * Problematic delinquency: More than 4 hours of delinquency over the past 30 days. * Concerning delinquency: More than 1 hour of delinquency over the past 30 days. Delinquency over the past 30 days is concerning at more than 1 hour, problematic at more than 4 hours, and excessive at more than 8 hours, with tracking by Stakewiz. Figure 15.6: Delinquency levels ### Tracking delinquency [#tracking-delinquency] The Stakewiz uptime score (via their API) is used for tracking. ## Vote credit requirements [#vote-credit-requirements] Vote credits are handled as follows: * Minimum vote credit requirements: No strict minimum, as vote credits are already captured in the uptime metric. * Impact of vote credits: Vote credits impact APY, which the Validator Board considers when it approves a validator. ## Client compliance standards [#client-compliance-standards] To meet the required client compliance, validators must run one of the following: * Jito-enabled client * Paladin-enabled client ## Stake amount requirements [#stake-amount-requirements] The maximum stake threshold is 500K SOL (not applicable to [direct stake](/stake/direct-staking)). ## Commission limits [#commission-limits] The commission limits are 5% commission and 10% MEV (exceptions can be made by The Vault contributors). Raising your commission above 5% or your MEV commission above 10% (the Solana Foundation Delegation Program criteria), even for one epoch, can block your stake for 10 epochs. ## Validator contributions to the Solana ecosystem [#validator-contributions-to-the-solana-ecosystem] The Validator Board assesses each validator's contributions to the Solana ecosystem (Figure 15.7). ### Metrics for evaluating contributions [#metrics-for-evaluating-contributions] Validator contributions to the Solana ecosystem are difficult to quantify but can generally be assessed based on, but not limited to: * Development of apps in the Solana ecosystem * Solana community participation (e.g., notable individuals, investors with strong communications impact, etc.) * Development of infrastructure-related tools for the ecosystem (e.g., dashboards and validator utilities) * Open source development within the Solana ecosystem * Membership in Solana projects with meaningful contributions ### Quantifying contributions [#quantifying-contributions] Contributions are assessed as follows: * Validators must clearly describe how their contributions help the ecosystem when they apply. * Evaluations are subjective and rely on board members making qualitative judgments. * A voting system among board members is used to assess ecosystem contributions. Contribution evidence can include app development, community participation, infrastructure tool development, open source development and membership in Solana projects with meaningful contributions; validators describe how their contributions help the ecosystem, and board members make qualitative judgments and vote. Figure 15.7: How contributions are assessed ## Staying on the approved list [#staying-on-the-approved-list] Approved validators are expected to maintain compliance with The Vault's governance and participation requirements: * Participation in governance: Validators must vote on all SIMD proposals on the Solana chain; failure to do so may result in removal from the approved list. * Uptime and performance: Validators must continue meeting the performance, delinquency, client and commission criteria on this page. * Community contributions: Validators lacking ecosystem contributions may be removed from the approved list until their contributions are deemed sufficient for reapproval. * Fees: Validators are expected to settle [Stake-as-a-Service (SaaS)](/delegation/stake-as-a-service-saas) fees in a timely manner. The Vault reserves the right to pause new approvals at any time. ## Non-compliance and corrective actions [#non-compliance-and-corrective-actions] The corrective actions for non-compliance are: * Failure to vote on proposals: Risk of removal from the approved list. * Performance issues: Validators not meeting base uptime criteria or becoming delinquent may be removed from the approved list. * Lack of contributions: Validators who fail to make meaningful contributions to the ecosystem may be removed from the approved list. ### Misconduct and exploits [#misconduct-and-exploits] Any validator caught attempting to bribe, use misleading statements in their application, or exploit loopholes to gain approval may be banned from the stake pool entirely. This includes: * Fraudulent applications, bribery, or deceptive practices. * Participating in malicious activities that harm the network or the users of the network, for example, but not limited to, sandwich attacks.