Validator research

Published 2026-07-22Updated 2026-10-26Latest source check: 2026-10-26 · Jito identity balance

Solana clients and validator infrastructure

Understand which software runs consensus, which systems build and deliver transactions, and what each choice changes for a validator.

Source checks range from July to October 2026; dates stay with their topics.Review dates and methodology.

The short version

Client diversity

Agave and full Firedancer are distinct implementations. Frankendancer combines Firedancer components with Agave; a fork is not another independent consensus client.

Block building

Jito-Solana, BAM / FireBAM, Raiku, Rakurai and Harmonic change the building or orderflow path. Their dependencies and fallback behavior matter as much as throughput.

Transaction delivery

Preconfirmations report early signals. Landing services deliver transactions. Neither is consensus finality, and coverage depends on participating leaders and routes.

Operator decisions

Compare compatibility, failure recovery and net costs. Release labels, dashboard cohorts and modeled revenue answer different questions.

What counts as a validator client

A validator client handles consensus, voting, replay, execution and block production. Forks share a codebase; schedulers and builders change how transactions reach that client. These distinctions determine which dependencies and failure modes an operator takes on.

Full validator client

A complete implementation intended to run the validator stack.

Hybrid validator

A validator stack combining parts from different implementations.

Fork/distribution

A modified validator branch derived from a base client.

Scheduler/block-building system

Infrastructure that changes orderflow or block assembly around a validator.

MEV/orderflow infrastructure

External or integrated orderflow, bundle, auction, or tip systems.

Dashboard/index/light client

Measurement, visualization, decentralization scoring, or non-validator verification tools.

Clients and building systems at a glance

The tables below separate independent implementations from hybrids, forks, building systems, historical lineage and non-validator software. Release and access notes describe the dated checks, not recommended software versions.

Independent implementations

Separate codebases that implement Solana consensus and block production.

Project / lineage	Classification	Status and distinctions
AgaveSolana Labs lineage	Production baseline validator client	Active production baseline maintained by Anza. Baseline for many Solana forks and distributions.
Full FiredancerFrom-scratch C implementation	Independent full validator implementation	Official source surfaces conflict: the README still says not ready/no releases, while upstream published a mainnet-ready full Firedancer v1.1.4 artifact on 2026-08-10. A published release establishes availability, not deployed market share.
SigZig implementation	Independent implementation in development	Active development signals; production adoption is unverified. Independent development effort; production readiness was not established.
MithrilGo implementation by Overclock Validator	Independent implementation in development	The public repository describes a validator and full node client for Solana written in Go, with commits as recent as 2026-10-21 (checked 2026-10-22). Production adoption and release status are not verified here. Treat as an in-development independent implementation. Verify current release status, feature coverage, and mainnet readiness in the repository before any operational use.

Hybrid validator

Combines components from two implementations in one validator process.

Project / lineage	Classification	Status and distinctions
FrankendancerFiredancer networking/block production plus Agave execution/consensus	Hybrid validator	Available on testnet and mainnet-beta; upstream v0.1105.40200 was published as mainnet-ready on 2026-08-11. Agave remains in the execution and consensus stack.

Modified distributions and forks

Agave or Firedancer lineage with added MEV, scheduling, or engine integrations. A fork is not an additional independent consensus client.

Project / lineage	Classification	Status and distinctions
Jito-SolanaAgave / Solana validator lineage	Fork/distribution	Active MEV-oriented validator fork/distribution. Shares Agave lineage rather than providing an independent implementation.
FireBAMJito Foundation fork of the Firedancer codebase	Firedancer/Frankendancer fork with BAM integration	The FireBAM fork published mainnet-ready Firedancer v1.1.4 on 2026-08-11 and Frankendancer v0.1105.40200 on 2026-08-14. BAM-enabled fork with its own release line, separate from upstream.
RaikuJito-Agave / Agave lineage	Pilot Jito-Agave fork plus external engine	An August 10 vendor post says mainnet rollout is active, while the roadmap and quickstart retain future/pilot wording; the linked validator form and raiku-agave repository returned 404 when checked. Raiku and Rakurai are unrelated stacks. Raiku client access and rkuSOL selection are separate.
RakuraiJito-Solana / Agave lineage	Jito/Agave-derived fork plus scheduler/reward infrastructure	Validator onboarding and docs are public; independent adoption methodology is not fully verified. Product and economics claims are Rakurai's; onboarding is not a measured adoption count.
HarmonicSalsa from Agave; Samba from Firedancer/Frankendancer lineage	Agave/Firedancer-derived forks plus block-building infrastructure	Docs, validator page, and onboarding form are public; whitelist/application flow applies. Block-building system and client forks, not an independent consensus implementation.

Block building, scheduling, and orderflow infrastructure

Systems that select or order transactions for a validator. They run alongside a client rather than replacing it.

Project / lineage	Classification	Status and distinctions
BAMIntegrated with Jito-Solana / Agave validator infrastructure	Block assembly/scheduler marketplace infrastructure	Mainnet and testnet AgaveBAM and FireBAM paths are documented; a validator needs upcoming leader slots to connect. An external scheduling layer; the validator still executes and votes.
FlowraJito-Solana fork plus sidecar/gateway/auctioneer/builder architecture	Developing Jito-derived orderflow-auction infrastructure	GitBook describes roadmap and architecture; launch/adoption is not independently confirmed here. Roadmap architecture; production deployment was not confirmed at review.

Historical lineage

Archived or uncertain projects kept for context.

Project / lineage	Classification	Status and distinctions
Legacy Solana Labs clientOriginal Solana validator client	Historical archived lineage	Archived historical repository. Archived; relevant to code lineage, not a production choice.
PaladinJito validator fork	Historical/uncertain Jito-derived fork	Repository and secondary profile exist; Blockworks marks Paladin deprecated, but first-party closure was not confirmed. Historical context; closure was not confirmed by a first-party statement.

Not a validator client

Related software that does not produce blocks.

Project / lineage	Classification	Status and distinctions
TinyDancerLight-client architecture	Light client	Not a validator block-production client. A verification light client, outside validator market-share counts.

Agave and Solana Labs lineage

Agave is the active baseline production validator implementation in this taxonomy. The archived Solana Labs repository remains important for lineage: many current forks and distributions are best understood as descendants of the original Solana validator codebase rather than independent rewrites.

Firedancer versus Frankendancer

Release wording and adoption are different questions

The upstream release record now labels full Firedancerv1.1.4 and Frankendancerv0.1105.40200 as mainnet-ready, while the repository README still says full Firedancer is not ready and has no releases. This page cites the exact artifacts and dates, keeps that source conflict visible, and treats Firedancer Reports labels as dashboard-labeled, not independently confirmed network-wide adoption.

Frankendancer

Frankendancer is the hybrid path: Firedancer networking and block production combined with Agave execution and consensus. The upstream project published mainnet-readyv0.1105.40200 on 2026-08-11; the FireBAM fork published a separate BAM-enabled artifact with the same tag on 2026-08-14.

Full Firedancer

Full Firedancer is the independent from-scratch validator implementation path. The upstream project published a mainnet-ready v1.1.4 artifact on 2026-08-10; FireBAM published its separate BAM-enabled artifact on 2026-08-11. That supersedes an absolute “no release” claim but does not establish the share of validators actually running either artifact.

Jito-Solana

Jito-Solana is a fork/distribution of the Solana validator lineage with MEV and block-engine integration. It is operationally important, but it should not be described as a from-scratch consensus implementation. That distinction matters because client-diversity risk is different from distribution, scheduler, or orderflow diversity.

Checked 2026-10-26

Identity balance is an operational dependency

On Jito-Solana the validator identity account pays for the tip programs. Once per epoch it creates that epoch's tip distribution account; the 0.0015037 SOL rent matches the current rent-exempt minimum for a 168-byte account, plus a 0.000005 SOL fee. When another validator's leader slot has changed the tip receiver, the identity pays another 0.000005 SOL fee to set it back. Per Jito's validator announcement on Discord, that rent goes to the vote account when the tip distribution account expires, not back to the identity, so the identity balance only goes down.

The same announcement describes the failure modes. With BAM, no transactions are scheduled for the leader slots, so the validator produces empty blocks and logs only a repeated INFO line, solana_core::tip_manager] should_init_tip_distribution_account=true, with no error. With the non-BAM block engine, bundles are skipped and MEV tips for those slots are lost; the log shows tip programs error, not processing bundles.

Keep at least 1 SOL in the identity account and top it up regularly.
Scripts that sweep the identity should leave at least 1 SOL, never only the rent-exempt minimum.
If either log line appears, check the identity balance first.

This is separate from Alpenglow's validator admission ticket, which is held in the vote account, not the identity. Jito says it is updating the BAM validator docs and adding a warning and metric to the BAM client; neither was published in the BAM or Jito-Solana docs checked on 2026-10-26. The announcement covers Jito-Solana; FireBAM behavior was not checked.

BAM and FireBAM

BAM documentation describes the Blockspace Assembly Marketplace as external scheduling infrastructure: a BAM node receives transactions and Block Engine bundles, validates and sequences them, and sends ordered work to a leader validator. BAM itself is not a validator client. BAM says scheduling runs in a trusted execution environment and that the validator retains consensus, voting, execution, and block production; those security properties still create TEE, attestation, scheduler, and availability trust boundaries that operators must review.

FireBAM is different from BAM alone: it is the Jito Foundation fork of the Firedancer codebase that adds BAM support and can be built in full Firedancer or hybrid Frankendancer mode. The fork published mainnet-ready Firedancer v1.1.4 on 2026-08-11 and Frankendancer v0.1105.40200 on 2026-08-14. Those are FireBAM fork artifacts. Upstream published the corresponding versions on 2026-08-10 and 2026-08-11, respectively, so matching tags are not interchangeable evidence of source, patch content, compatibility, or adoption.

Jito’s May 13, 2026 announcement said FireBAM was available on testnet and mainnet, named early operator activity, and said the BAM adoption incentive would extend to FireBAM. It also said an Asymmetric Research audit was in progress and that fixes and open sourcing would follow. Those are point-in-time vendor statements: this review did not find a linked final FireBAM-specific audit report or sufficiently public current incentive terms, so neither participation, payment, safety, nor adoption is implied.

Checked 2026-09-30

BAM attestations: live components versus roadmap

The September 28 BAM update reports TLS available on all mainnet BAM Nodes through Certio, but Registry testing remains internal on testnet. Mainnet Registry, mandatory TLS, public attestations and open scheduling code are remaining work, not a completed transparency rollout. Earlier release and preconfirmation checks retain their own dates.

Connection verification and operator implications

Discover a healthy node through the Registry.
Establish TLS and validate its IP-bound certificate.
Request a TEE report with a fresh nonce.
Bind the nonce and TLS session key material into the report.
Verify that binding and published measurements before streaming.

This planned flow addresses relay attacks: a genuine report from another node must not authenticate the current connection. TLS identity alone does not verify scheduler code. Attestations concern node code/configuration; preconfirmations concern early transaction signals. The update describes BAM Verifier comparing leader ordering with on-chain results and Autobahn banning flagged validators; those are distinct from TEE verification.

Review supported clients, measurements, certificate renewal and failure behavior before adopting new settings. This source check did not validate attestations independently; it establishes neither finality nor universal inclusion, fairness or absence of harmful MEV.

Operator flow and fallback

A healthy BAM connection sends ordered work over gRPC and pauses normal TPU and Block Engine bundle ingress. If BAM is disabled or unhealthy, FireBAM returns to normal ingress, including Block Engine. Bundle and BAM tiles must exist at startup; only the endpoint and enabled state can then change at runtime.

Tested host baseline

Jito’s guide retains standard Firedancer requirements and reports testing on Ubuntu 24.04, an AVX-512-capable CPU, at least 386 GiB RAM, 10 Gbit/s or faster networking, and outbound DNS plus TCP access to the selected BAM endpoint on ports 50055–50056. Treat these as a tested baseline, not a universal sizing guarantee.

Verify behavior, not process uptime

Confirm bam_enabled, bam_healthy, and bam_stream_live; alert on BAM failures and inspect transaction, atomic-batch, and pack lifecycle counters during leader slots. A healthy flag does not itself prove that fresh work arrived for the current slot.

Release and recovery discipline

Checked 2026-08-15: pin and review the intended FireBAM tag, its submodules, cluster config, and upstream delta. Keep a tested disable and rollback path. The documented last-resort recovery commands can change host-wide hugepage, CPU, kernel, and network configuration and should be used only with the validator stopped and the exact reviewed config. Neither a mainnet-ready label nor audit language is a revenue, safety, or adoption guarantee.

Raiku

Raiku is not Rakurai. Raiku documents raiku-agave as a fork built directly on jito-agave. Auction logic lives in an external Marketplace/Engine rather than in validator runtime logic: the client connects over gRPC, receives AOT and JIT bundles, executes them atomically, and uses a configured merkle-root authority for on-chain tip distribution. These are first-party architecture and economics claims, not independent performance measurements.

Source availability, rechecked 2026-10-22: every docs.raiku.com address cited in this section redirected to the raiku.com homepage, and the raiku-agave repository still returned 404. The statements below are preserved as dated records from the 2026-08-15 check, not as currently verifiable documentation.

Compatibility and fallback

Raiku says Jito Classic and Raiku can coexist because the inherited Jito flags remain in place, but Raiku is explicitly incompatible with Jito BAM. If the Engine URL is absent, or connection retries fail, the client enters stub mode: ordinary Agave-based validation continues, while Raiku bundles, tip metrics, and Raiku rewards stop.

Operator boundary

The docs use the existing validator identity to authenticate to the Engine and require the vote account, merkle-root uploader, and a separate Raiku tip commission. Review the external Engine, identity-signing path, on-chain tip program, authority, release provenance, logs, and failure behavior; never transfer validator key material to a third party.

Raiku’s public status sources conflict. Its August 10, 2026 engineering post says the client is live on Solana mainnet, Raiku’s own validator is active, and integrations are rolling out across Kiln, Figment, Everstake, Chorus One, and Blockdaemon. The roadmap checked in August describes mainnet launch as a future stage, while the quickstart retains pilot-partner access. The post does not independently prove that every named operator is deployed in production or establish broad adoption. The same vendor post limits practical AOT/JIT coverage to slots whose assigned leader runs Raiku, rather than every Solana slot.

Pilot access and a hostname conflict

Checked 2026-08-15: Raiku calls the client pilot-only and says the repository will open after the pilot, but both the linked raiku-agave repository and validator application returned 404. The public contact page and official-site-linked Discord are inquiry-only ways to ask about current pilot access; neither is a validator application, admission path, or participation guarantee. The quickstart’s mainnet example usesengine.mainnet.raiku.ssh, while a separate first-party endpoints table usesengine.mainnet.raiku.sh. Treat .ssh as a likely documentation typo and confirm the endpoint out of band before any production change.

At the August check, Raiku’s staking API attributed one configured mainnet validator to Raiku. That is useful vendor-side evidence, not an independently measured adoption count. The docs also publish OtterSec report links for the validator client and on-chain program; audits do not guarantee safety, availability, or correct operator configuration. The client is described as free during the pilot, and the operator’s share of Raiku bundle tips is configured in basis points, but public volume, payout, fee, or minimum-revenue commitments were not found.

Keep client participation separate from rkuSOL. rkuSOL is a Sanctum-powered liquid-staking pool whose validator selection, pool fees, and stake allocation are a different workflow. The public sources checked here do not say that joining the Raiku pilot, running the client, or submitting a validator form grants rkuSOL inclusion, delegated stake, tips, or revenue.

Rakurai

Rakurai describes a high-performance validator stack built from the Jito/Agave lineage plus a scheduler, activation program, reward distribution program, and tip-manager architecture. Rakurai says its stack can improve block rewards and MEV tips; those are vendor claims and should remain attributed. Public onboarding is not the same as independently verified adoption.

In the 2026-09-21 review, Rakurai had announced TIN (Transaction Inclusion Network), with multi-block-engine orderflow, additive tip-based priority and post-pack confirmations. P2C is an early scheduler signal, not an already-confirmed on-chain transaction. The preconfirmation section below separates tip, subscription and backrun accounting and the progressively deployed landing-service integrations. Performance and safety claims remain attributed to Rakurai.

Harmonic

Harmonic describes an open block-building system with Remote TPU, builders, a block engine, and validator integrations. Its docs describe Salsa as an Agave-derived fork and Samba as a Firedancer/Frankendancer-derived fork. The Typeform is an application/onboarding path; it does not imply acceptance, stake, delegation, or revenue.

Checked 2026-09-21: Harmonic Preconfirmations exposes builder selections through Triton, before validator execution. The profit calculator models measured cohort economics with editable costs and commissions; its outputs do not establish a causal gain from changing clients or a separate preconfirmation payout rate.

Flowra

Flowra’s GitBook describes an Open Orderflow Auction using a Jito-Solana fork, transaction observation, sidecars, gateways, auctioneer logic, and builder/leader injection. Its roadmap describes testnet and mainnet milestones, but this research did not independently confirm production launch or adoption.

Paladin historical note

Paladin is best treated as a historical or uncertain Jito-derived fork focused on anti-sandwiching and priority transaction handling. The repository and Solana Compass profile were available when checked, and Blockworks labels Paladin as deprecated, but a first-party closure statement was not verified at the review date.

Sig and TinyDancer

Sig is Syndica’s independent Solana validator implementation in Zig, still in development at this review. Production adoption was not verified. Mithril, a Go validator and full node client from Overclock Validator, is a second in-development independent implementation; its public repository was active on 2026-10-21 (checked 2026-10-22), and no adoption claim is made here. TinyDancer is different: it is a light client, not a validator client, so it should be excluded from validator-client adoption counts.

Checked 2026-09-21

Slot time, block timing, and finality

Four clocks matter: the protocol's target slot duration, observed block arrival gaps, send-to-inclusion latency, and consensus finality. A faster feed or a same-slot landing does not shorten the protocol clock or prove finality. The title of the 200ms monitor is a rollout target, not activation evidence.

Stage	Mainnet evidence on September 21	Interpretation
350ms / 300ms	Feature accounts active at slots 440,208,000 / 441,936,000.	Earlier stages; not the latest effective target.
250ms	Active at slot 447,552,000 (epoch 1036).	SIMD-0525 applies a one-epoch delay: effective from epoch 1037. Both RPC checks were in epoch 1039.
200ms	Feature account absent on both checked mainnet RPCs.	Not active in this snapshot; 200ms was not live on mainnet as of the September 21 check.

Evidence, source discrepancy, and operational consequences

Read-only getMultipleAccounts and getEpochInfo queries at finalized commitment agreed across api.mainnet-beta.solana.com (slot 449,074,872) and solana-rpc.publicnode.com (slot 449,074,866). Active accounts were owned by the Feature program. The Foundation rollout page still said 300ms and unscheduled 250ms; this dated on-chain check takes precedence for activation, while SIMD-0525 specifies the effectiveness delay.

The four-slot leader span and 432,000-slot epoch are unchanged: nominally 1 second per leader window and 30 hours per epoch at 250ms. These are derived target durations, not measured guarantees. Per-slot work limits scale down and annualization scales up; more blocks do not mechanically double transaction capacity, inflation, APY or revenue. Under Tower BFT, more votes per wall-clock day increased vote-fee expense; Alpenglow, live on mainnet since epoch 1064 (2026-10-21), replaces that vote path, and this September 21 slot-time check was not re-run after activation.

Check skip rate, replay headroom, networking, snapshot compatibility and costs per day rather than comparing SOL per epoch alone. Blockhash expiry arrives sooner in wall-clock time: use the returned lastValidBlockHeight and current block height, not a hardcoded seconds-per-slot timer.

Checked 2026-09-21

Preconfirmations: signals and validator participation

Preconfirmations expose an early decision or local result before shreds. The emission point and trust boundary depend on the provider. Coverage follows participating leader slots; a silent stream does not imply an empty block. Recover gaps with other feeds, deduplicate notifications, and reconcile with processed, confirmed and finalized state as appropriate. None of these streams guarantees a canonical block.

System	What is observed	Consumer access	Validator participation / economics
BAM	Leader commits to executing a BAM-scheduled batch, before execution. BAM Verifier checks ordered commitments; a skipped slot or fork is still possible.	Distributed through Helius and Triton. The launch's >34% stake and 5–10ms p50 advantage are dated vendor observations, not current network coverage or a universal latency lead.	AgaveBAM / FireBAM automatically opted in at launch; manual opt-out via Jito support. Subscription revenue: 30% distributor, 35% validators, 35% Jito DAO.
Helius native + BAM	Native stream: immediately after local execution, with status. BAM source: before execution, without that status. Older generic scheduled-transaction marketing wording does not describe both sources.	preconfSubscribe WebSocket; sources combined by default, includeBam: false excludes BAM. Duplicate signatures and gaps are possible. Pro-or-higher and credit pricing are provider terms.	Native forwarding uses contact-based setup. Helius offers revenue sharing but publishes no fixed validator rate here; BAM distribution is a separate path.
Harmonic	Builder selects transactions before validator execution and shred generation. This is a builder-selection signal, not the same assurance as BAM's leader commitment.	Filtered gRPC stream through Triton, covering Harmonic-built slots.	Requires the Harmonic building path. Public preconfirmation access does not establish a validator payout formula; do not add an assumed rate to calculator results.
Rakurai TIN / P2C	Post-pack signal at the scheduler's described point of no return, not ledger confirmation. Rakurai describes protection against front-running the original transaction; this is a mechanism claim, not chain finality or an independent safety audit.	Registered gRPC consumers; stream subscriptions, reply bundles and backrun settlement have distinct requirements.	TIN is integrated in the Rakurai client, without a separate daemon. Operators can inspect and blocklist block-engine/P2C endpoints; service registration is coordinated with Rakurai.

Checked October 20: Manka lists preconfirmations as upcoming. Everstake Blockspace documents pending TPU orderflow and post-sequencing shreds, not an equivalent leader-commitment signal.

Revenue accounting and onboarding: BAM versus TIN

BAM's September 9 announcement says validator payments start in October 2026, distributing the preceding month's share via market-tick priority fees on connected leader slots. Skipped/disconnected slots earn none. Revenue is slot-weighted, hence stake-proportional in expectation, not a fixed payment per validator. Preconfirmation revenue and an adoption-incentive program are different mechanisms. No October payout had been observed as of the September 21 check, and payouts were not rechecked for the October 20 update.

Rakurai's September 16 announcement enables TIN across its validators, while the partner rollout is progressive: Astralane, Circular, Everstake, FlashBlock, Helius, Node1 and SpeedLanding were named. This is not proof every partner was already connected everywhere. Landing-service onboarding registers discovery endpoints and settlement authorities; it is distinct from validator onboarding.

TIN accounting separates TCA (inclusion tips), PSA (prepaid P2C access) and MCA (backrun/MEV share). Tips add to, rather than replace, priority fees. MCA reporting is self-reported by the service; on-chain accounting alone does not verify complete profit attribution. Do not count a tip again when its value is converted into a block reward. Confirm current commissions, settlement, endpoint policies and client requirements before estimating net revenue.

Circular's preconfirmations page was access-blocked during review. It is retained as a discovery link only: no signal stage, coverage, API or payout terms are inferred from its URL or Circular's presence in the TIN partner announcement.

Checked 2026-09-21

Transaction landing services

Landing services transport signed transactions toward leaders and builders; they are not independent consensus clients. SWQoS helps network admission, priority fees bid for scheduling, and provider/builder tips are separate payments. An accepted request or returned signature proves neither inclusion nor successful execution. A preconfirmation feed is the observation side; a sender is the delivery side.

Service	Documented path / access	What to verify
Temporal Nozomi	Multi-region relay, transaction/batch/bundle methods and optional protected submission. Docs and dashboard.	Pay-on-land tip model is vendor-described. Landed does not necessarily mean execution succeeded. Regional telemetry and marketing latency samples have different windows/cohorts; inspect v1 method limits below.
Circular Fast	Provider describes concurrent routing through SWQoS, UDP, Jito, Harmonic, Rakurai and private validator channels, plus post-transaction backrun/cashback monetization.	Landing, cashback and MEV analytics are separate products. Confirm current routing/privacy policy and revenue attribution; 0-slot is an objective, not a promise.
FlashBlock	Docs describe SWQoS, leader-aware routing, transaction submission, QUIC and shred streaming. The root documentation page works; the supplied /index and several linked deep routes failed direct checks.	Documentation access is partial. Treat latency figures as vendor claims; obtain working current method/authentication docs before integration. No test transaction was sent.
SpeedLanding	Public docs describe HTTP JSON-RPC, binary submission, QUIC and tip requirements. Listed as a progressive TIN partner.	Security review required: examples pass a base58 keypair secret over HTTP, including a URL query, and the QUIC sample skips server verification. Never use validator identity, vote/withdraw authority, or funded-wallet keys. Do not copy these examples as a safe production recipe.
Astralane	Iris gateway, builder/validator routing, shred-stream and protected-submission products; docs and portal onboarding.	Verify protection and fallback policies per method. Website counters and example metrics are not a comparable benchmark. TIN partner naming is not proof of an active route for every leader.

Compare providers on matched traffic, region, tip and fee budget, slot stage and load: report p50/p95/p99, inclusion and execution-success rates, expiry, total paid costs and sample size. Sending identical signed bytes over several routes does not create a new transaction; re-signing with a fresh blockhash can create a second independently executable transaction. Track expiry and application-level idempotency before retrying. Do not infer v1 support from an HTTP path named /v1/.

Additional services checked 2026-10-20; earlier provider comparisons retain their September 21 snapshot.

Manka: transaction delivery and shred data

Manka is an adjacent transaction service, not an independent consensus client. Tx Landing is available; atomic bundles of up to four transactions and batches of up to 25 independent transactions require access on request. ShredStream is beta. Preconfirmations are listed as upcoming, not a live signal to include in coverage estimates.

Access, transport safety, and validator participation

The quickstart directs users to Discord support for an API key, with key-specific TPS and minimum tips. The dashboard offers Discord sign-in. Public access documentation is for service consumers: no validator onboarding or operator revenue formula was found in the reviewed sources. Request those terms separately before treating Manka as a revenue opportunity.

HTTP submission sends already-signed transactions with a recent blockhash and required tip, without preflight simulation. A returned signature is not proof of landing or successful execution. Examples use plaintext HTTP with an API key in the query: review transport and logging before integration. An API key is not a validator private key.

QUIC documentation describes TLS 1.3 with a self-signed certificate and custom shared-key HMAC authentication bound to the certificate transcript, rather than conventional certificate validation. This is a protocol description, not an independent security audit. Its documented 65–1232-byte transaction limit does not establish larger transaction-v1 support.

ShredStream exposes decoded transactions, entries and raw shreds after shred generation; it is not a pre-execution feed or consensus finality. MEV marker protection is provider-described and should be checked per route, not treated as a network-wide guarantee.

Everstake Blockspace: delivery, optimization, and orderflow

Blockspace combines services around existing clients. ShredStream and Direct Shreds expose post-sequencing data; SWQoS improves delivery admission, not consensus ordering guarantees. Relayer/TPU distributes pending, pre-sequencing traffic to approved searchers. This orderflow feed is not a leader preconfirmation or a new consensus client.

Two operator paths, costs, and orderflow risks

Client Optimization offers paid one-off or monthly auditing and tuning for existing Agave, Firedancer and Jito setups. The docs require at least one full mainnet epoch of history, vote-account verification and read-only metrics for the audit. Apply recommendations yourself, or review any separate privileged implementation access before granting it. Obtain the dashboard quote and compare matched before/after epochs; marketing uplift is not a forecast for an individual validator.

Searcher Connection describes self-service operator onboarding with more than one epoch of mainnet history, a major client and identity verification. A connector mirrors inbound TPU traffic; this publisher role differs from application-gated searcher access. Review the binary, permissions, resource overhead and recipient/filter policies before enabling it. Vendor claims of no performance impact were not independently tested.

Revenue settlement depends on consumption and orderflow value; the connection docs describe unique-transaction weighting. The provider percentage is disclosed in the dashboard before opt-in. SOL payouts are scheduled within the first ten days of the following calendar month. This is variable service revenue, not delegated SOL or a guaranteed monthly income; use a separate payout address.

Publishing pending transactions changes who can see users' orderflow. Optional filtering and acceptable-use prohibitions on harmful MEV do not independently prove technical prevention. Check consent, routing and retention policies, pool obligations and SFDP criteria before opting in; no conclusion that a particular provider is approved or prohibited is implied.

Validator overview · Service dashboard. No account connection, installation, traffic forwarding or payout verification was performed.

Checked 2026-09-21

Transaction v1: format and compatibility

Transaction v1 is live on mainnet: the finalized txv1 feature account was active at slot 447,120,000, epoch 1035, on both checked RPCs. The Foundation dates activation to September 15, 2026. Legacy and v0 remain supported; their size limit is still 1232 bytes. v1 allows up to 4096 bytes, with inline addresses rather than ALTs. More bytes do not raise every other resource limit or guarantee lower latency.

Surface	Required distinction
Builders and signers	v1 starts with 0x81; signatures are at the end. Use a v1-aware SDK/serializer. Explicitly set computeUnitLimit and loadedAccountsDataSizeLimit: unset limits default to zero. Check wallet support before choosing v1.
Fees and account loading	Read message configuration, not ComputeBudget instructions. v1 priorityFee is total lamports; legacy/v0 compute-unit price is micro-lamports per CU. Inline addresses replace ALT lookup indices; v1 does not remove account or compute limits.
RPC readers / indexers	Set maxSupportedTransactionVersion: 1 for supported transaction/block reads. Decode transactionConfig. For Geyser/protobuf, detect Message.config before the older versioned flag; stale decoders can silently misclassify v1 as v0.
Validator / RPC software	The Foundation's scoped September guidance calls out Jito-Solana and Agave RPC v4.2.2 fixes for v1 production/storage. This is a compatibility floor, not a blanket latest-version recommendation or proof of support in every fork.
Sponsors and relayers	Budget checks that only scan ComputeBudget instructions no longer bind v1. Inspect the signed configuration and normalize fee units before approving sponsorship or comparing payments.

Nozomi limits, integration pitfalls, and primary references

Nozomi's v1 documentation allows 4096 bytes per transaction through JSON-RPC, API v2 and Batch Send, but keeps Send Bundle members at 1232 bytes, including v1. Use base64 or the documented raw-binary method. Feature gating, an endpoint kill switch and temporary lack of a large-transaction delivery path can still cause rejection. Batch submission is not itself an atomicity guarantee, and protocol support does not ensure every provider route can carry a large v1.

The checked Nozomi Rust example sets a compute limit but omits the loaded-account-data limit; the current Solana pipeline documentation explains why an unset v1 data limit fails. We do not reproduce that example as a tested recipe. Incorrectly loaded transactions can still incur fees; simulate with explicit limits and inspect the result before sending.

SIMD-0296: larger transactions and SIMD-0385: v1 format define separate changes. Their checked GitHub headers still said Review; that document metadata is not a reliable proxy for current feature activation. Use the feature account and rollout record for deployment status.

The ALT trade-off analysis and RPC JSON definitions explain the practical limits. Ben / Circular's September 14 thread is retained as explanatory context, not activation authority. Less instruction scanning and fewer state lookups can reduce ingestion work; a larger packet does not inherently transmit faster, shorten slots or halve finality.

SWQoS and adjacent infrastructure

Stake-weighted QoS is a Solana network/client feature for transaction forwarding and peering strategy. It can matter for operators, RPC providers, and validator economics, but it is not a validator client. The same separation applies to DoubleZero, Geyser/Yellowstone, RPC, indexing, and analytics systems.

Staking-rewards tooling · checked 2026-10-01

Pye Finance SpeedStake

SpeedStake is a staking-rewards widget, not a validator client, transaction accelerator, or stake-pool delegation program. Pye documents selling future staking rewards for upfront SOL while the underlying stake stays delegated to the selected validator until maturity. Principal Tokens represent the locked principal; an early sale depends on market price and liquidity, rather than an unrestricted withdrawal of the underlying SOL.

Validator participation. Pye requires registration and approval before listing or widget integration. The docs link applicants to Pye's main site, not a verified dedicated intake form. Pye describes trading-fee sharing and a free widget for whitelisted validators; confirm eligibility, fee splits and current onboarding directly. Listing does not guarantee stake or revenue.
Integration. Documentation covers React, Next.js and HTML/CDN, with a vote account filter for one validator or universal mode for supported validators. The CDN example still contains a placeholder URL. Verify package versions, production endpoints and live behavior separately from the mocked demo. No widget, wallet connection or external runtime script is embedded here.
Costs and risks. The product page quotes a 0.50% fee on SOL sale proceeds, not a verified validator revenue share. Review lockup/maturity terms, liquidity, smart-contract risk and withdrawal rules. Pye describes the product as non-custodial, but its docs say the Programmable Stake Account wrapper has mint and withdraw authority; that label is not a substitute for reviewing permissions. At maturity, withdrawals follow Solana's cooldown. Production execution and any specific validator's listing were not independently tested in this review.

Pye validator docs SpeedStake product page SpeedStake validator docs SpeedStake demo

Alpenglow and Quantumglow: protocol research adjacent to clients

Quantumglow is Anza researchers’ proposed post-quantum adaptation of Alpenglow. It is consensus-protocol research that validator clients might eventually need to implement, not a validator client, an Agave fork, a client release, or a deployed network upgrade. It therefore does not belong in the client classification or adoption rows above.

Alpenglow itself is no longer research: per the official Solana upgrade page checked 2026-10-22, it activated on mainnet at the start of epoch 1064 on 2026-10-21, and the migration required Agave-based v4.3.2 clients (Agave, Jito-Solana, or Harmonic Salsa); Firedancer and Frankendancer were not supported for the migration. That is a dated statement about the switch, not a claim about current client support, which the client teams publish separately.

Research status, not a rollout announcement

Checked 2026-08-05: no public SIMD, validator-client release, activation decision, or deployment schedule for Quantumglow was confirmed in the primary sources reviewed for this article.

Ax signatures and local certificates

Ax is a custom XMSS-style hash-based signature construction. Because it does not provide BLS-style aggregation, the design moves approval broadcast off the common fast path and lets nodes produce local weak- and strong-certificate events as approvals arrive.

Block-data authentication

Instead of signing every shred, the proposed design uses a signed block commitment plus authenticated channels for block data. This is a protocol construction, not evidence that current production clients already operate this way.

What the performance evidence means

The evidence consists of formal analysis, simulations, and cryptographic microbenchmarks. It supports a comparable common-case round structure, not production or mainnet measurements and not identical wall-clock performance; the fallback path can add a communication step.

A post-quantum consensus design would not by itself make the whole Solana stack post-quantum. Accounts, transactions, validator identities, networking, and programs require broader migration work. Read the Anza Quantumglow overview, the Alpenglow whitepaper v1.2, the research paper, and Anza’s broader quantum-adversary analysis.

Validator economics: the basics

Delegated stake is capital, not revenue. Separate commissions, protocol fees, orderflow tips and service income, then subtract voting, hardware and operating costs. Do not count priority fees again as an additional block reward.

Revenue or stake source	How it works	Costs and risks
Staking / inflation commission	Validators can charge commission on staking rewards generated by delegated stake.	Validator operations, monitoring, maintenance, and competitive commission strategy. Downtime, delinquency, commission pressure, stake churn, and reputational risk.
Block / protocol rewards	Leader validators earn rewards associated with successful block production and protocol fee mechanics.	High-availability validator hardware, networking, alerting, and operations. Missed slots, poor performance, software bugs, and infrastructure outages.
Priority fees	Transaction senders can pay priority fees for execution priority under normal fee markets.	Operational performance and scheduler configuration choices. Demand variability and policy/reputation considerations around ordering.
Jito / MEV tips	Jito-compatible validators may receive tips from bundle/orderflow activity.	Client integration, monitoring, and MEV policy review. MEV policy, centralization concerns, searcher demand, and dependency on Jito infrastructure.
Direct stake	Delegators or institutions can delegate directly based on reputation, performance, or policy fit.	Public reporting, operations, communication, and monitoring. Stake can move quickly; no guaranteed stake or delegation.
Stake-pool / program delegation	Programs and stake pools may delegate based on their own criteria, dashboards, or governance.	Compliance with public criteria, monitoring, possible bonds or reporting requirements. Criteria changes, paused applications, data drift, and no guaranteed delegation.
RPC / infrastructure services	Validators or operators can sell RPC, indexing, monitoring, or data infrastructure services.	Hardware, bandwidth, support, abuse handling, and SLA management. Customer concentration, outages, data correctness, and support burden.

Participation and operating costs

Open a system for its access requirements, revenue model and operating risks. Application/onboarding does not imply acceptance or a stake allocation. Undisclosed fees and payouts remain unknown.

Client-diversity programs

Mechanism: Delegation or reputation could favor operators running non-dominant clients or credible diversity paths.
Revenue / payer: Not publicly specified; depends on program design.
Status at review: Program-dependent / unknown.
Requirements: Client choice plus program-specific performance and risk criteria.
Costs: Migration, testing, monitoring, and immature-client operational burden.
Risks: Software maturity, rollback planning, and overclaiming diversity status.
Evidence: No specific open diversity program established by this review.

Firedancer / Frankendancer

Mechanism: Frankendancer provides the hybrid Firedancer-plus-Agave path, while full Firedancer is the separate from-scratch implementation.
Revenue / payer: Not publicly specified.
Status at review: Upstream published mainnet-ready full Firedancer v1.1.4 on 2026-08-10 and Frankendancer v0.1105.40200 on 2026-08-11, while the repository README still carries older no-release wording for full Firedancer.
Requirements: Technical readiness and current official instructions.
Costs: Migration testing, monitoring, and performance engineering.
Risks: Release-channel confusion, immature-software risk, rollback planning, and dashboard-label overinterpretation.
Evidence: Firedancer repository, release pages, and Jump page; scoped release check 2026-08-15.

Jito-Solana

Mechanism: Jito-Solana integrates validator operation with Jito MEV/block-engine flows.
Revenue / payer: Searchers/orderflow participants via Jito ecosystem mechanics.
Status at review: Active fork/distribution.
Requirements: Run compatible Jito-Solana versions and meet current ecosystem requirements.
Costs: Client operations, upgrades, monitoring, MEV policy review, and a funded identity account: the identity pays for tip-program transactions every epoch, and Jito advises keeping at least 1 SOL there.
Risks: Jito dependency, MEV centralization concerns, version drift, and silently skipped bundles if the identity cannot pay tip-program transactions.
Evidence: Jito-Solana repository and BAM documentation.

BAM

Mechanism: BAM documentation states that validators can connect a BAM client to external schedulers via BAM URLs.
Revenue / payer: Preconfirmation subscribers via distributors: the September 9 launch allocates 30% to distributors, 35% to BAM validators and 35% to Jito DAO. Adoption incentives are separate.
Status at review: AgaveBAM / FireBAM paths are documented. Preconfirmation launch terms were checked 2026-09-21; BAM announced the first incremental payments for October, and this page has not rechecked payouts since that date.
Requirements: Compatible client, current BAM configuration, and upcoming leader slots; public access does not guarantee incremental revenue.
Costs: Compatible-client configuration, startup verification, upgrade review, and operational monitoring; hardware requirements depend on the selected Jito-Solana or FireBAM path. On Jito-Solana the identity must also keep enough SOL for tip-program transactions; Jito advises at least 1 SOL.
Risks: TEE/scheduler trust, external block assembly, infrastructure dependency, and empty leader blocks on Jito-Solana BAM if the identity cannot pay tip-program transactions.
Evidence: BAM overview, validator documentation and September 9 preconfirmation launch; see the dedicated preconfirmation section.

FireBAM

Mechanism: A BAM node schedules transactions and Block Engine bundles, sends ordered work to FireBAM over gRPC, and receives leader-state and execution feedback. When BAM is healthy, normal TPU and Block Engine bundle ingress pause; when BAM is disabled or unhealthy, the validator returns to normal ingress.
Revenue / payer: Jito's May 13 announcement said the BAM adoption incentive would extend to FireBAM, but sufficiently public current payer, terms, and amounts were not found; ordinary Jito tip mechanics remain separate and no return is guaranteed.
Status at review: The Jito Foundation fork published mainnet-ready Firedancer v1.1.4 on 2026-08-11 and Frankendancer v0.1105.40200 on 2026-08-14. Matching version numbers must not be confused with the earlier upstream releases.
Requirements: Firedancer or Frankendancer operator, upcoming leader slots, reviewed release/config, and bundle plus BAM tiles enabled at startup.
Costs: Standard Firedancer operations plus the tested baseline of Ubuntu 24.04, AVX-512, at least 386 GiB RAM, 10 Gbit/s networking, outbound DNS/TCP 50055-50056, service supervision, and BAM metrics/alerts.
Risks: TEE and external-scheduler dependency, gRPC availability, fork/upstream drift, paused normal ingress while healthy, configuration and host-wide recovery hazards, and no guaranteed revenue. Monitor bam_enabled, bam_healthy, bam_stream_live, failures, and pack progress rather than assuming connectivity from process uptime.
Evidence: Jito FireBAM setup guide, FireBAM repository/release, BAM validator guide, and upstream Firedancer releases; checked 2026-08-15.

Raiku

Mechanism: Raiku says its Jito-Agave-derived client connects to an external gRPC engine for Ahead-of-Time and Just-in-Time bundles, with on-chain merkle-root-based tip distribution and an operator cut set by --raiku-commission-bps.
Revenue / payer: Bundle submitters through Raiku tip mechanics; no public volume, minimum payout, or revenue guarantee was found.
Status at review: Raiku's August 10 post says its client is live on mainnet and partner integration is rolling out, while its roadmap and quickstart still describe future/pilot access. The linked validator form and raiku-agave repository returned 404 on 2026-08-15; a vendor API identifies a Raiku mainnet validator, but none of this independently confirms broad adoption.
Requirements: Pilot access, Agave-class hardware, an existing validator identity and vote account, and Raiku Engine configuration. Jito Classic can coexist, but Raiku is incompatible with Jito BAM. With the application offline, Raiku's contact page and official-site-linked Discord are inquiry-only, not admission paths.
Costs: Fork and engine review, upgrades, external connectivity, log monitoring, and separate Raiku/Jito commission configuration. Confirm the mainnet endpoint with Raiku: the quickstart says .ssh while another first-party endpoint table says .sh.
Risks: External-engine and merkle-authority trust, identity-key authentication exposure, vendor-stated performance/economics, private-code access, documentation drift, and no guaranteed tips. Raiku says AOT/JIT coverage applies only to slots whose assigned leader runs its client, not every Solana slot. Stub mode preserves ordinary Agave-based operation but processes no Raiku bundles or rewards. Published OtterSec reports do not eliminate software or operator risk.
Evidence: Raiku validator quickstart, roadmap, August 10 engineering post, features, SDK endpoints, configuration, troubleshooting, FAQ, audit, staking, contact, official Discord, and validator API sources; checked 2026-08-15.

Rakurai

Mechanism: TIN integrates multi-service orderflow, additive tip-based scheduling priority and post-pack confirmations. TCA inclusion tips, PSA stream subscriptions and MCA backrun share are distinct revenue streams, not finality signals.
Revenue / payer: Traders / landing services fund tips; P2C consumers fund access and report backrun share. Confirm current operator splits and actual settlement rather than assuming gross service revenue belongs to the validator.
Status at review: September 16 TIN announcement says enabled across Rakurai validators, with partner connections progressively rolling out; scoped check 2026-09-21, not independent proof of every integration.
Requirements: Activation account, scheduler binary, Rakurai client build, and current Rakurai requirements.
Costs: Integration, monitoring, and possible future commission.
Risks: Scheduler trust, reward-distribution assumptions, vendor-claim uncertainty, and reliance on partner-operated block engines and gRPC endpoints registered through on-chain PDAs.
Evidence: Rakurai docs, TIN / settlement guides and September 16 launch threads; see the dedicated preconfirmation section.

Harmonic

Mechanism: Harmonic describes an open block-building system and says validators can keep 100% of tips. Its builder-selection preconfirmation stream is distributed through Triton; the calculator is a cohort-based scenario model, not a forecast.
Revenue / payer: Not publicly specified in enough detail for a revenue model.
Status at review: Application/onboarding and whitelist model.
Requirements: Validator identity must be whitelisted; Typeform is application/onboarding only.
Costs: Salsa/Samba integration and block-engine connectivity.
Risks: Builder/block-engine trust boundary, scheduler policy, and onboarding uncertainty.
Evidence: Harmonic docs, validators page, Typeform, Samba/Salsa repositories; preconfirmations and calculator checked separately 2026-09-21.

Flowra

Mechanism: Flowra's roadmap describes open orderflow auctions intended to increase validator revenue.
Revenue / payer: Not publicly specified.
Status at review: Developing/roadmap; launch/adoption not independently confirmed.
Requirements: Initial validator partnerships/onboarding were not fully verified in public sources.
Costs: Jito-derived client plus sidecar/gateway/auctioneer integration if launched.
Risks: Roadmap execution, adoption uncertainty, and orderflow trust assumptions.
Evidence: Flowra GitBook architecture and roadmap.

SWQoS

Mechanism: Stake-weighted QoS can affect transaction forwarding and peering strategy.
Revenue / payer: Indirect network-performance value, not a direct client revenue program.
Status at review: Documented Solana network/client feature.
Requirements: Stake, peering, and infrastructure configuration.
Costs: Networking and operational coordination.
Risks: Misconfiguration and overclaiming it as a validator client.
Evidence: Official Solana SWQoS guide.

DoubleZero / private networking

Mechanism: Private or specialized networking can improve infrastructure performance or reliability.
Revenue / payer: Provider/customer model depends on the specific network or program.
Status at review: Adjacent infrastructure; not validated as a client program here.
Requirements: Provider-specific.
Costs: Network integration and operational complexity.
Risks: Vendor dependency and network concentration.
Evidence: General networking category; no specific program terms evaluated.

Geyser / Yellowstone

Mechanism: Streaming/indexing plugins can support analytics, monitoring, and data products.
Revenue / payer: Customers or internal infrastructure users.
Status at review: Adjacent infrastructure category.
Requirements: Operational and data engineering capacity.
Costs: Storage, networking, and support.
Risks: Data correctness, uptime, and customer expectations.
Evidence: Classified as infrastructure, not a validator client.

RPC / indexing

Mechanism: Operators can build public or private RPC and indexing products around validator/data operations.
Revenue / payer: Customers.
Status at review: General infrastructure business pattern.
Requirements: Reliability, support, and capacity.
Costs: High bandwidth, compute, storage, abuse controls, and support.
Risks: SLA failure, customer concentration, and operational load.
Evidence: Adjacent infrastructure classification.

Grants, testing, security, and research

Mechanism: Client teams or ecosystem programs may fund testing, audits, research, or bug/security work.
Revenue / payer: Project teams, foundations, or grant programs.
Status at review: Program-specific; no active grant offer established in this review.
Requirements: Proposal quality, security skills, or testnet participation requirements.
Costs: Engineering time and reporting.
Risks: No acceptance guarantee, changing program terms, and unpaid work.
Evidence: Current grant and testnet terms must come from the sponsoring project.

Before changing your stack

Implementation risk

Is this a full client, hybrid, fork, plugin, scheduler, dashboard, or light client?

Methodology risk

Does adoption evidence disclose denominator, filters, delinquent handling, and identity method?

Operational risk

Can the operator test rollback, monitoring, failover, and upgrade paths before production?

Economic risk

Who pays, what is public, what is capped, and what is only vendor-stated?

Counterparty risk

Does the stack depend on a block engine, scheduler, TEE, whitelist, gateway, or vendor program?

Evidence

Are the release, audit and performance results relevant to the exact version and configuration you plan to run?

Tools for validator research

Choose a task to see the relevant tools. Each card dates its description and access check; dashboard values remain live. These are third-party services, not endorsements.

Clients and stake1 toolMarinade Explore

Marinade Explore

Explore validators, providers, clients and delegators, with stake and yield views.

Checked 2026-09-21

Limits and methodology

Check the selected window: headline and table APY periods differ. Client-plus-builder labels are not independent client implementations or proof of pool admission.

Performance and delivery4 toolsSolana 200ms Monitor · Solana Slowpokes · Nozomi Dashboard · Manka Dashboard

Solana 200ms Monitor

Live slot-time, block-gap and rollout discovery dashboard.

Checked 2026-09-21

Limits and methodology

The page name is a rollout target, not proof that 200ms is active. Measurement windows and client attribution differ from feature-gate state.

Solana Slowpokes

Per-validator median and worst block timing, epoch trends, produced/skipped slots and client metadata.

Checked 2026-09-21

Limits and methodology

Default timing comes from a completed-epoch Trillium snapshot; ?realtime adds live observations. Current gossip versions can differ from the measured epoch. Timing is not a causal client ranking.

Nozomi Dashboard

Public regional landing statistics and an account portal for Nozomi.

Checked 2026-09-21

Limits and methodology

Regional recent samples are not interchangeable with marketing benchmarks. Compare units, windows, failures and traffic composition before comparing providers.

Manka Dashboard

Discord-authenticated access portal for Manka transaction delivery and data services.

Checked 2026-10-20

Limits and methodology

Quickstart requests an API key through support. Preconfirmations are upcoming; public validator onboarding and revenue terms were not found. Review transport authentication before integration.

Documentation ↗

Economics and monitoring6 toolsHarmonic Validator Profit Calculator · Circular Validators · Circular MEV · Watchtower RugAlert · The Vault Validator Monitor · Everstake Blockspace

Harmonic Validator Profit Calculator

Model block rewards, tips, commission, voting and server costs using editable assumptions and a measured Harmonic cohort.

Checked 2026-09-21

Limits and methodology

A vendor scenario, not a personalized forecast or causal proof that switching clients increases profit. Recheck epochs per year and vote costs as slot times change.

Circular Validators

Validator economics and transaction-flow exploration, with a published metric-definition guide.

Checked 2026-09-21

Limits and methodology

The dashboard was access-blocked during this check; scope is documented separately. MEV revenue generated by searchers is not automatically validator income.

Documentation ↗

Circular MEV

MEV exploration surface with a separately documented analytics API.

Checked 2026-09-21

Limits and methodology

The dashboard was access-blocked. Gross revenue, profit, fees, provider tips and validator receipts must be distinguished; no current values were independently reproduced.

Documentation ↗

Watchtower RugAlert

Track inflation and MEV commission changes and inspect timestamped events.

Checked 2026-09-21

Limits and methodology

The service labels commission at least 90% as Rug and increases of at least 10 percentage points as Caution. These are detection rules, not proof of fraud; verify the account, timing and operator context.

The Vault Validator Monitor

Official iOS/Android app for any mainnet validator: performance, stake sources, rewards and commission scenarios, plus Vault targets and invoices.

Checked 2026-09-21

Limits and methodology

The official page says free and no wallet required. Start with a public vote account; monitoring and modeled APY are not guaranteed outcomes.

Everstake Blockspace

Portal for client optimization, orderflow publishing and transaction/data services.

Checked 2026-10-20

Limits and methodology

Documentation review, not an authenticated dashboard audit. Optimization is paid; orderflow revenue is variable. Audit connector permissions and pool policies before sharing pending TPU traffic.

Documentation ↗

Reading dashboard results

Check the sample before comparing numbers. An instance, a filtered validator cohort and a whole-network estimate are different denominators. Timing and revenue tools are in the tool directory.

Dashboard methodology · 9 references

Blockworks validator client dashboards

Dashboard labels for validator-client style categories by stake/count.

Dashboard methodology and derivation are not fully visible in the checked pages.

Do not treat labels as independent from-scratch clients or compute network truth from hidden methodology.

Firedancer Reports

Filtered validator sample labels; checked API filter was period=twentyday and minStake=400000.

Filtered sample, not whole-network denominator; label derivation remains unresolved.

Do not claim full Firedancer production adoption from labels.

Firedancer GUI

Validator-instance telemetry and runtime view.

Instance-specific, not network-wide.

Do not use any instance stake as Firedancer client adoption.

IBRL

Block-building behavior and execution quality metrics.

Observable slot/block behavior; not a validator-client denominator.

Do not treat IBRL as client market share.

Encapsulate network graph

Interactive network visualization of validators, delegators, clients, and stake distribution.

Visible methodology/API was not found in the checked shell.

Do not publish exact adoption numbers from it without methodology.

ValidBlocks stake-pool heatmaps

Per-validator pool stake movement over recent epochs.

Pool-specific heatmap, not validator-client adoption.

Do not infer full Firedancer or network-wide client adoption from a pool heatmap.

GD Index

Geographic decentralization across country, city, and network operator/ASN.

Validator/location index with its own methodology, not client implementation share.

Do not claim specific stake-pool use unless first-party pool evidence exists.

Sandwiched.me client distribution

Per-client stake share, validator count, top validator, and version fragmentation, alongside Sandwiched.me's own Weighted Ghost Score and sandwich-rate labels.

Stated at check time: 704 validators and 428.4M SOL tracked by Sandwiched.me, not the full network validator count.

Do not treat the Ghost Score or sandwich percentage as an independently verified, network-wide MEV-safety fact; it is Sandwiched.me's own scoring methodology.

Trillium Small Block Analysis

Third-party per-completed-epoch lower-tail block-output view. A block is labeled small when total_cu < p10 OR user_tx < p10 for that completed epoch.

The dashboard's dynamic completed-epoch sample and relative p10 threshold. Results can also reflect version, BAM/scheduler mode, validator region/latency, hosting/provider, traffic/load, and cohort composition.

Do not treat it as client market share or ranking, proof of causation, safety, expected revenue, or a validator-quality verdict.

Trillium and Firedancer sample notes

Trillium checked 2026-09-07: its completed-epoch lower-tail test is total_cu < p10 OR user_tx < p10. It is not a client ranking, causal finding, safety claim, revenue estimate, or validator-quality verdict. No dynamic Trillium values, dashboard embed, API collector, or raw dataset is used on this site.

Firedancer Reports was checked with period=twentyday and minStake=400000. That filtered sample cannot establish whole-network adoption.

GD Index

GD Index is a geographic decentralization metric, not a client adoption metric. It tracks country, city, and network operator context for validators and stake pools. GD Index itself was inspected; use by specific pools was not verified.

Sources and methodology

Sources are grouped by evidence type. Official repositories and project documentation carry more weight than dashboards and secondary profiles. Dynamic dashboards were checked for access, scope, and methodology caveats; no charts were copied and no raw datasets were stored in this repository.

For dashboard definitions and live observations:Firedancer Reports, Blockworks, IBRL, GD Index, and Trillium.

Trillium source attribution: Fueled By Trillium | Solana.

Review dates and methodology

This is a dated reference, not a live status monitor. Official code and documentation take priority over marketing and dashboard labels. A newer check covers only its named topic.

Client taxonomy: 2026-07-29
Quantumglow: 2026-08-05
FireBAM and Raiku: 2026-08-15
Trillium methodology: 2026-09-07
Transaction infrastructure and tools: 2026-09-21
BAM attestations: 2026-09-30
Pye SpeedStake: 2026-10-01
Manka and Everstake Blockspace: 2026-10-20
Jito identity balance and tip accounts: 2026-10-26

Manka and Everstake Blockspace — October 20 (5)

Manka quickstart

Service-consumer access and signed transaction submission; not a validator enrollment program.

Manka QUIC

Custom authentication and transaction-size boundaries.

Blockspace validator services

Paid client optimization and the separate orderflow-publisher path.

Blockspace Searcher Connection

Connector behavior, operator eligibility and consumption-weighted revenue.

Blockspace settlement

Dashboard-disclosed provider share and monthly payout terms.

Solana Qubits contribution sources (2)

Article Markdown

Contribution-friendly Markdown copy of this research article in the public Solana Qubits research repository.

Source index

Grouped primary repositories, official documentation, dashboards, methodology pages, and secondary context used by this article.

Client repositories and official docs (9)

Agave repository

Active Anza-maintained Solana validator client repository for code lineage and releases.

Archived Solana Labs repository

Historical Solana Labs validator repository for historical lineage.

Jito-Solana repository

Jito's Solana validator fork/distribution source for MEV-oriented client context.

Firedancer repository

Official Firedancer/Frankendancer repository used for the full-versus-hybrid distinction; its README readiness wording is checked against newer release artifacts.

Firedancer releases

Upstream release record for the mainnet-ready full Firedancer v1.1.4 and Frankendancer v0.1105.40200 artifacts; a release is not network-wide adoption evidence.

Firedancer docs

Official Firedancer documentation entry point.

Jump Crypto Firedancer page

Jump Crypto page describing Firedancer and linking official Firedancer ecosystem resources.

Sig repository

Syndica's Zig Solana validator implementation effort.

TinyDancer repository

TinyDancer light-client repository; included to exclude it from validator-client adoption counts.

Alpenglow and post-quantum protocol research (4)

Anza: Quantumglow — will Solana’s performance survive quantum computing?

Anza research overview of the proposed post-quantum adaptation of Alpenglow and its performance evidence.

Alpenglow whitepaper v1.2

Primary protocol design source for Alpenglow and the Quantumglow post-quantum construction.

Distributed Quorum Signatures preprint

Companion preprint introducing ordinary signatures plus approval broadcast and local weak and strong certificate events.

Anza: Securing Solana against a powerful quantum adversary

Broader threat-model overview showing that a post-quantum Solana migration extends beyond consensus.

BAM and FireBAM (8)

BAM Attestations: Road To Transparency

September 28 roadmap, checked September 30: mainnet-node TLS, internal testnet Registry testing, session-bound TEE reports, and remaining public-attestation rollout. Vendor status, not an independent deployment audit.

BAM overview

Blockspace Assembly Marketplace overview for BAM architecture, scheduler, node, and validator integration model.

BAM for validators

Validator-facing BAM page with AgaveBAM and FireBAM setup paths, TEE and leader-schedule context, endpoints, and operational modes.

FireBAM setup guide

Jito's operator guide for FireBAM requirements, Firedancer/Frankendancer builds, configuration, fallback behavior, runtime control, metrics, and recovery.

FireBAM announcement

Jito's May 13, 2026 announcement covering testnet/mainnet availability, early operator claims, a vendor-stated incentive extension, and an Asymmetric Research audit then described as in progress; these are dated claims, not guarantees.

FireBAM repository

Jito Foundation fork of the Firedancer codebase adding BAM support; keep this fork distinct from the upstream repository.

FireBAM Firedancer v1.1.4 release

FireBAM fork artifact published 2026-08-11 and labeled mainnet-ready; it corresponds to, but remains separate from, the upstream release line with the same version.

FireBAM Frankendancer v0.1105.40200 release

FireBAM fork's mainnet-ready Frankendancer release published 2026-08-14, separately from the upstream 2026-08-11 release.

Raiku (16)

Raiku validators page

Current vendor overview for Raiku's validator-side AOT/JIT blockspace-marketplace positioning.

Raiku validator quickstart

Pilot-access setup page identifying raiku-agave as Jito-Agave-derived, Jito Classic-compatible, and BAM-incompatible; verify its conflicting mainnet hostname before use. On 2026-10-22 every docs.raiku.com address redirected to the raiku.com homepage, so the cited text was no longer reachable at this link.

Raiku milestones and roadmap

First-party roadmap that still describes a mainnet launch as a future stage; keep this visible beside Raiku's later mainnet-rollout claim.

Raiku August 10 engineering update

Vendor post saying the client is live on mainnet and integrations are rolling out across named operators; it is not independent confirmation of each operator's production deployment.

Raiku SDK endpoints

First-party endpoint table using engine.mainnet.raiku.sh, which conflicts with the quickstart's engine.mainnet.raiku.ssh example.

Raiku validator features

First-party AOT/JIT bundle, external Engine, tip-distribution, and client-lineage description.

Raiku validator configuration

Raiku-specific flags, identity-based engine authentication, independent Raiku/Jito commission settings, and BAM incompatibility.

Raiku troubleshooting and stub mode

Connection signals and fallback behavior: ordinary Agave-based operation continues in stub mode, but Raiku bundles and rewards stop.

Raiku audit reports

Vendor-published OtterSec audit links for the on-chain program and Raiku Agave client; audits do not eliminate software or operator risk.

Raiku validator application instructions

Official application instructions, kept as a dated record; the public form it links to was unavailable when checked 2026-08-15.

Raiku validator application form

Linked from Raiku's docs but returned 404 when checked 2026-08-15, so it is not a confirmed live application path.

Raiku Agave repository

Repository linked from Raiku's pilot documentation; it returned 404 when checked 2026-08-15 and again on 2026-10-22, so the client source is not publicly accessible at this address.

Raiku contact page

General first-party inquiry route; it is not a live validator application, admission, or participation guarantee.

Raiku Discord

Community channel linked by Raiku's official site; use only to ask about current access, not as evidence of application or acceptance.

Raiku validator API

Vendor-operated mainnet attribution endpoint; useful as first-party evidence for Raiku's configured validator, not independent adoption measurement.

Raiku rkuSOL documentation

Separate Sanctum-powered LST context; client participation or application does not itself establish rkuSOL inclusion or delegation.

Rakurai and Harmonic (9)

Rakurai validator page

Rakurai validator onboarding and product claims; vendor claims should stay attributed.

Rakurai docs

Rakurai-Solana architecture and incentives context.

Rakurai repository

Rakurai validator fork repository checked for source lineage and license context.

Rakurai transaction inclusion guide

First-party guide for searchers/block engines/partners describing bundle support, virtual priority boost, and post-pack confirmations; vendor-stated mechanism, not independently verified.

Harmonic docs

Harmonic documentation entry point for block-building system architecture.

Harmonic validator page

Validator-facing Harmonic page describing Salsa, Samba, and validator claims.

Harmonic application form

Read-only checked application/onboarding form; not evidence of acceptance, delegation, or revenue.

Harmonic Salsa repository

Agave-derived Harmonic validator fork repository.

Harmonic Samba repository

Firedancer/Frankendancer-derived Harmonic validator fork repository.

Flowra and Paladin (3)

Flowra GitBook

Flowra Open Orderflow Auction documentation used for architecture and roadmap context.

Paladin on Solana Compass

Secondary project profile sourced from The Grid; not first-party endorsement evidence.

Paladin repository

Paladin's Jito-derived validator fork repository used for historical/client-fork context.

Dashboards, metrics, and adjacent infrastructure (19)

Pye validator docs

Registration, approval, stake lockups and validator fee-sharing context.

SpeedStake product page

Future-reward sales, principal tokens and dated published fee terms.

SpeedStake validator docs

Widget integration paths and single-validator versus universal mode.

SpeedStake demo

Widget preview with separate mocked and live data modes; not proof of execution.

Firedancer Reports

Dashboard with filtered validator labels; labels are not treated as independent client implementations.

Firedancer GUI

Validator-instance telemetry UI; instance stake is not used as network adoption.

Blockworks validator clients dashboard

Blockworks dashboard checked as secondary client-label context. On 2026-10-22 this address redirected to Blockworks' generic Solana analytics page, where no client-share chart was visible without an account; the labels cited here are from the 2026-07-29 check.

Blockworks validator clients dashboard v2

Second supplied Blockworks dashboard checked for labels including deprecated/hybrid categories. On 2026-10-22 it redirected to the same generic analytics page as the first dashboard link.

IBRL methodology

IBRL scoring methodology for block-building behavior; not client market-share methodology.

Trillium Small Block Analysis

Third-party per-completed-epoch lower-tail block-output dashboard; verify the live epoch and methodology before reuse.

Trillium API and methodology

Per-completed-epoch API/methodology and attribution terms; no Trillium data is collected or embedded here.

IBRL API docs

IBRL public API documentation for observable block/validator behavior endpoints.

Encapsulate Solana mainnet graph

Interactive network visualization checked as exploratory dashboard only.

ValidBlocks stake-pool heatmap

Stake-pool heatmap source; pool movement is not validator-client adoption.

ValidBlocks Firedancer pool heatmap

Firedancer pool-specific heatmap; not evidence of full Firedancer client adoption.

GD Index validator page

Geographic decentralization index page; inspected as decentralization metric, not client adoption.

Sandwiched.me client distribution

Per-client stake share, validator counts, top validator, and version fragmentation, checked with a stated 704-validator/428.4M SOL denominator.

GD Index repository

Open-source GD Index repository and methodology context.

Solana SWQoS guide

Official Solana guide for stake-weighted QoS, classified as network/QoS infrastructure.

Continue reading

Research2026-08-15Solana Stake Pool DAO & Governance TrackerSource-linked monitoring of governance across 15 stake-pool registry projects, supplemental rkuSOL, associated Sanctum infrastructure, and historical Lido on Solana, with token-role boundaries, participation paths, current activity, treasury caveats, official sources, and a static JSON dataset.Research2026-07-29Jito Restaking and NCNs: How Operator Access Actually WorksSource-linked research on Jito Restaking: the restaking and vault programs, the NCN, vault, and operator opt-in handshake, named NCNs and operators, on-chain account measurements, operator economics, slashing status, and a reproducible verification method.

Disclaimer

This guide is informational, not an endorsement or a production runbook. Check current releases and program terms, test changes and plan a rollback. Participation does not guarantee stake or earnings.