BotTx

Solana Validator Guide for Developers — What It Is, How It Works, and Why You Should Know

What Solana validators do, how they decide which transactions land, and why understanding the validator side helps developers build better applications.

BoltTx Team··8 min read
solanavalidatorconsensusswqosdeveloperrpc

If you're a developer building on Solana, "validator" is one of those terms that comes up a lot but rarely with a clear definition. You read that "validators include transactions" and "stake-weighted QoS prioritises transactions to validators" without ever quite understanding what a validator does or how it makes decisions. The gap doesn't matter for development; it matters when production transactions don't land and you're trying to understand why.

This piece walks through what Solana validators actually do, how they decide what to include in a block, and what you as a developer should care about — even if you're not running one.

What a Validator Actually Does

A Solana validator is a node that participates in consensus. Specifically:

Validators are economically motivated: they earn block rewards (newly issued SOL) and a share of transaction fees plus priority fees plus optional Jito tips. To validate, they put up stake (SOL locked up as collateral); validators with more stake get proportionally more chances to produce blocks.

The validator network is what runs Solana. Your transactions go through it. Understanding that this is the layer you're interacting with — not just an abstract "the network" — clarifies a lot about why some things work and others don't.

How Validators Decide What to Include

When a validator is producing a block, it has more incoming transactions than will fit. It has to choose. The factors:

Priority fee. Transactions with higher priority fees (per CU) are preferred. This is how Solana's congestion is priced.

Compute unit budget. A block has a CU limit. The validator picks transactions that fit within the remaining budget.

SWQoS (stake-weighted QoS). The network gives priority to RPCs that route through SWQoS paths. Invisible from outside but decisive in practice.

Order of arrival, in some implementations. First-come-first-served within tie-breaks.

Validator-specific configuration. Some validators run custom logic (rejecting certain programs, prioritising others, working with MEV bundlers like Jito).

What this means for developers: getting your transaction included reliably under load isn't just "pay enough fee." It's also "submit through an RPC that supports SWQoS."

What SWQoS Actually Is

Stake-Weighted Quality of Service is a mechanism in Solana's networking stack: the network prioritises peers (including RPCs) based on the stake they represent. An RPC with SWQoS capability gets faster, more reliable transaction acceptance.

The key implication: not all RPCs are equal even on the same hardware. An RPC without SWQoS capability gets deprioritised when the network is busy. An RPC with SWQoS support gets priority.

You can't see this from the outside as a developer. Two RPC providers might both publish "we send to validators" without explaining that one of them is in the priority queue and the other isn't. The difference shows up in tail latency — specifically during congestion when it matters.

For production workloads, you want an RPC that's transparent about SWQoS support. It's one of the questions worth asking explicitly when evaluating providers.

Validators and Block Production Schedules

Validators don't all produce blocks at the same time. Solana rotates block production across validators roughly in proportion to stake, with the rotation order known in advance.

For developers, this matters because:

Most production RPCs handle this routing internally — you don't pick which validator your transaction goes to; the RPC does. This is part of what "smart routing" means in marketing pages.

Validator-Side MEV

Validators have transaction-ordering power within the block they produce. They can reorder transactions in ways that capture MEV (Maximal Extractable Value). This is one of the reasons MEV exists on Solana despite no public mempool.

The economic chain:

What this means for developers: your transaction's profitability is partially at the mercy of the validator that includes it. Anti-MEV protection at the RPC layer mitigates this by ensuring your transaction reaches the validator without being observable to MEV operators in advance.

Should You Run a Validator?

For most developers: no.

Running a Solana validator requires:

The economics work for serious operators earning staking income at scale, but for application developers, validator operation is a distraction from product. Use a managed RPC instead — they handle the SWQoS infrastructure you need without you doing the operational work.

The exception: if your team has specific reasons (compliance, validator-side income at scale), running validators makes sense. For 95% of developers, it doesn't.

What Developers Should Care About (Even Without Running Validators)

Things to know about validators that affect your code:

Sub-second slot times. Solana's slots are short. Your transaction landing "soon" means landing in the next slot or two. "Eventually" isn't a useful target.

SWQoS matters. When picking RPCs, ask whether they have SWQoS support. Most production providers do.

Priority fee strategy aligns with validator economics. A higher priority fee means more validator income from your transaction, which makes it more likely to be prioritised. But maxing out the priority fee on every transaction is wasteful (see our priority fees guide).

Validator-side MEV is the threat model. Sandwich attacks, transaction reordering. Mitigated by Anti-MEV routing.

Network upgrades happen. Solana protocol updates regularly. Validators upgrade in coordinated waves. Your code might need to handle protocol changes (new instructions, deprecated behaviour).

Some validators are more reliable than others. Uptime, operational quality, and network placement vary. RPC providers that route traffic to high-quality nodes give you better transaction landing.

What to Do This Week

If you're building on Solana and want to deepen your understanding:

  1. Read Solana's documentation on consensus. It clarifies what validators actually do.
  2. Check whether your RPC supports SWQoS. Ask the provider directly if it's not in the docs.
  3. Look at validator stake distribution. Solana's stake is fairly distributed; understanding the top operators is useful context.
  4. Audit your tip strategy. It's the main lever you have to influence validator behaviour.
  5. Plan for protocol upgrades. They happen; have a plan to test and adopt.
  6. Don't run a validator unless you have a specific reason. Use a managed RPC instead.

What BoltTx Does at the Validator Layer

BoltTx has dedicated submission infrastructure providing:

import { Connection } from "@solana/web3.js";

const connection = new Connection(
  "https://bolttx.io/?api-key=YOUR_API_KEY",
  "processed"
);

Free tier signup. The validator-layer optimisation is what BoltTx provides; you don't have to think about it.

FAQ

How many Solana validators are there? Roughly 1,500-2,000 in 2026. Number changes as validators come online and offline. Stake distribution is the more meaningful number.

Do all validators run the same software? Most run the mainstream validator implementation; some run alternatives. Network behaviour is similar but performance characteristics differ.

How is block production order decided? Solana rotates block-production duty across validators roughly in proportion to stake, and the order is known in advance.

Can I influence which validator includes my transaction? Indirectly — through priority fee, through which RPC you use, through transaction ordering hints in some advanced setups. You don't pick a specific validator; the network decides.

Is validator-side MEV a real threat? Yes. It's the dominant form of MEV on Solana. Mitigated by Anti-MEV RPC routing.

Further Reading

← Back to all posts