SLV Completes Solana v4 Support With XDP and Alpenglow-Ready BLS

ELSOUL LABO B.V. (Headquarters: Amsterdam, Netherlands; CEO: Fumitake Kawasaki) and Validators DAO are pleased to announce that SLV, the open-source Solana operations tool, has completed support for Solana v4 (Agave 4.x).

With this update, the optimizations that the highest-performing Solana validators rely on — Anza's XDP Turbine retransmit acceleration and the Alpenglow-ready BLS public-key registration workflow defined in SIMD-0387 — can now be run by any operator through the same proven operational recipe, via conversations with an AI agent or direct CLI operation. The advanced tuning that once required deep Linux and Solana expertise is consolidated into SLV, so that even operators without that specialist background can reproduce it through conversation alone.

SLV Official Site: https://slv.dev/en SLV GitHub: https://github.com/validatorsDAO/slv

Democratizing Top-Tier Validator Operation — World-Class Optimization, Reproducible by Anyone

SLV is an open-source effort to operate Solana validators together with AI agents, delivering the highest quality of maintenance at low cost, anywhere in the world.

On Solana, the gap between a validator's raw performance and the operational know-how behind it has been widening. Low-latency networking, kernel and NIC tuning, careful preparation for protocol upgrades — the operations that lead to top-tier validator performance have demanded deep specialist knowledge of Linux and Solana, and continuous hands-on labor. As a result, the highest levels of operation tended to remain accessible only to a limited group of operators with that expertise.

SLV exists to close that gap. By consolidating the operational know-how built up by world-class validator operations into skills for an AI agent, anyone can reproduce the same operational recipe through conversation alone. This Solana v4 support brings that idea directly to the latest optimizations: XDP and BLS, the very technologies that the highest-performing validators are adopting, are now available to every operator who uses SLV — without giving up their own choice of client or environment.

What Solana v4 Support Brings — XDP, BLS, and Restart-Safety, All Handled for You

Solana v4 (Agave 4.x) is the latest generation of the validator client, recommended by Anza for mainnet, and it raises core performance while preparing the network for larger blocks and the upcoming Alpenglow consensus upgrade. SLV's v4 support covers the three areas that matter most to operators moving onto this baseline.

XDP Turbine retransmit acceleration — turn-key enablement of the high-performance networking path that accelerates block propagation.
Alpenglow-ready BLS public-key registration (SIMD-0387) — preparing the registration workflow ahead of time, so validators are ready to register once the Alpenglow feature gate activates.
Restart-safety for Agave 4.1+ — adjusting the port range and gating cluster-restart-only flags so that moving to the new client does not introduce avoidable startup failures.

Each of these is handled through the same SLV workflow — AI agent conversation or CLI — so the move to Solana v4 does not become a manual, error-prone project. The latest SLV release carries all of the above as part of the v2026.6.6 series — BLS, XDP, and the restart-safety fixes shipping first, with the Firedancer and RPC robustness following in the same series.

What XDP Is — A Linux Kernel Fast Path That Accelerates Turbine

XDP (eXpress Data Path) is a Linux kernel technology that lets high-performance networking code bypass much of the kernel's usual packet-handling path. By cutting data copies and context switches, it processes packets with far less overhead than the standard network stack.

In Agave, XDP is applied to Turbine, the protocol that propagates blocks across the validator network. Incoming shreds are handled by an eBPF program attached close to the network interface card (NIC) and mapped into user-space buffers via AF_XDP, while outbound shreds are sent directly using XDP_TX — eliminating syscalls and copies on the hot path. Anza introduced XDP for Turbine in the Agave 3.x series (from v3.0.9) and carries it into the Agave 4.0 baseline.

According to Anza's setup guide, large validators can approach 150,000 outbound packets per second with XDP. Anza positions XDP as part of the headroom that prepares validators for 100M-CU blocks and advances the IBRL (Increase Bandwidth, Reduce Latency) roadmap, and has published an official setup guide for operators adopting it.

Anza Agave XDP Setup Guide: https://www.anza.xyz/blog/agave-xdp-setup-guide

SLV Makes XDP Turn-Key — Enable It With Conversation and a Few Inventory Variables

Adopting XDP by hand is not trivial. It requires a recent kernel (6.14+ for the igb driver, 6.8+ for others), an XDP-capable NIC, the right systemd capabilities for the validator process, and the correct startup flags — and CPU-core pinning (including the PoH core) has to be chosen correctly for the path to perform. This is exactly the kind of specialist work that has kept advanced optimization out of reach for many operators.

SLV turns this into a turn-key step. XDP retransmit acceleration is opt-in through per-host inventory variables — xdp_enabled, xdp_interface, xdp_cpu_cores, xdp_zero_copy, and xdp_poh_pinned_cpu_core. When enabled, SLV applies the XDP startup flags appropriate to the target Agave/Jito version and grants the required systemd capabilities (CAP_NET_RAW, CAP_NET_ADMIN, CAP_BPF, CAP_PERFMON) automatically. These variables apply to Agave and Jito validators; Firedancer uses XDP natively and needs no separate enablement. (XDP has matured across the Agave releases — it is no longer experimental as of Agave 4.1, and the corresponding flag names changed along the way — so SLV tracks the correct flags for each version, and operators do not have to.)

From the operator's side, this can be driven entirely through conversation. Launch the AI Console and say something like "Enable XDP retransmit acceleration on this validator," and the AI agent selects and applies the necessary configuration. Corresponding commands are provided for CLI-oriented users as well, so workflows that do not involve AI agents are fully supported. The same networking optimization that the highest-performing validators use becomes something any SLV operator can switch on.

Alpenglow-Ready BLS Registration — Forward Support for SIMD-0387

Alpenglow is Solana's next-generation consensus protocol. To aggregate validator votes efficiently — for example, to succinctly prove that 60% of validators voted to skip a slot — Alpenglow replaces the current ed25519 signatures with the BLS (Boneh–Lynn–Shacham) aggregate signature scheme for votes. SIMD-0387 defines how validators register a BLS public key in their vote account so they are ready to vote once Alpenglow is enabled.

Under SIMD-0387, registering a BLS public key becomes possible once the proposal's feature gate is active, and each validator must have one in its vote account before Alpenglow goes live in order to keep voting. The BLS keypair is derived from the vote authority keypair (or the identity keypair if that is absent), and registration is performed on-chain together with a Proof of Possession (PoP) — a cryptographic proof binding the key to the vote account that prevents rogue-key attacks. At present, SIMD-0387 is at the review stage and its feature gate is not yet active on mainnet (it is tracked for devnet activation), so no BLS key can be registered on mainnet yet; what matters today is having the workflow ready for when the gate opens.

This is precisely where being ready early matters. Once Alpenglow is live, a vote account without a registered BLS key would behave as if it were unstaked. Having the registration workflow in place ahead of time, rather than scrambling when the gate opens, is what keeps an operation safe across the transition.

SLV's register:bls — Prepared Automatically at Deploy Time

SLV puts this preparation in place for you. The new slv v register:bls command is the workflow that registers the BLS public key — derived from the authorized-voter or identity keypair — on each vote account once the feature gate is active. It also runs automatically at the end of slv v deploy, so a validator built or updated through SLV moves through this step as part of the normal flow.

The operation is designed to be safe to run at any time. On a cluster where the feature gate is not yet enabled, it passes through safely as a no-op; once the gate activates, the same workflow registers the key. It is idempotent, so running it early carries no risk and there is no need to time it precisely against the upgrade. As with XDP, the same step can be driven through conversation with the AI agent or through the CLI. The groundwork that determines whether a validator can keep voting through the Alpenglow transition is in place ahead of time, without manual key management.

Strengthened Restart-Safety for Agave 4.1+

Moving to a new client generation can surface subtle startup failures, and SLV's v4 support addresses these directly. For Agave 4.1+ (and Jito validators on the same base), the dynamic port range is widened to at least 27 ports (8000–8030 / 8900–8930), resolving a case where Agave/Jito 4.1.0+ rejects a narrower range at startup with "Port range is too small" — a failure that crash-looped validators and RPC nodes. The fix covers all validator, RPC, and pythnet start scripts, along with the init and inventory defaults.

In addition, cluster-restart-only flags are now gated: --wait-for-supermajority and --expected-bank-hash are emitted only when explicitly set, so a stale slot or bank hash can no longer hang a node, or panic it with a bank-hash mismatch, on an ordinary restart. These are the kinds of details that, handled by hand, turn a routine upgrade into an incident — and that SLV now takes care of as part of the standard recipe.

This hardening continues across the recipe. A follow-up release extends the same operational robustness to the Firedancer and RPC paths — network-aware Firedancer version handling, a Jito build-conflict cleanup, and RPC start-script corrections — so that moving to the latest baseline stays smooth regardless of which client an operator runs.

Eliminating Reinvention of the Wheel — Consolidating Top-Tier Know-How Into the AI Agent

In the Solana ecosystem, many projects spend time on the shared work of operating validators and nodes, separate from developing their actual product. Building, deploying, monitoring, updating, and migrating clients — for every project, these are similar repetitions of the same tasks, a kind of reinvention of the wheel.

XDP enablement and Alpenglow-ready BLS registration are perfect examples. They are advanced, easy to get wrong, and each operator otherwise has to research and re-derive them independently. By consolidating this operational know-how into SLV skills for the AI agent, the same proven recipe can be reproduced by anyone, through conversation alone — and the human cost of operation comes down structurally. With this release, the SLV validator skill — the knowledge the AI agent draws on — has been updated for BLS (SIMD-0387) and XDP, so the agent applies the current, correct procedure rather than an outdated one. This is what "the highest quality of maintenance, at low cost" means in practice.

SLV will continue to resolve, one by one, the operational burdens common across Solana projects, together with SLV AI — so that each project can focus on the essential development of its own product.

Both CLI and AI Agent — Stability Underpins Both

SLV operates stably not only as an AI agent but also as a CLI. For users who prefer not to rely on AI agents, or who want to integrate SLV into scripted automation flows, SLV remains a practical operational foundation.

This CLI-level stability is precisely what underpins the reliability of AI agent operation. Every SLV feature is MCP (Model Context Protocol) compatible, and the AI agent invokes the same interfaces through MCP that the CLI does. When the CLI is stable, the AI agent is stable — this design principle underpins the reliability of SLV's AI agent operation. XDP enablement and register:bls, too, can be handled the same way from both the CLI and the AI agent, on the same MCP foundation.

An Operational Foundation That Backs a Commitment to Performance — Epics DAO Validator Reached World #3

The Epics DAO validator, operated as the source of ERPC's SWQoS endpoint and Epic Shreds, has reached world rank #3 (score 99.93) in the Shinobi Performance Pool among all Solana validators, with vote-related scores exceeding 99%.

This result is the cumulative outcome of multiple improvements: hardware selection, kernel parameter optimization, network stack tuning, IRQ affinity adjustment, the adoption of DoubleZero, and networking optimizations of exactly the kind XDP represents. SLV consolidates that operational know-how into the AI agent and delivers it in a form anyone can reproduce as the same operational recipe. The optimizations described here are not theoretical — they come from operation that has reached the top of the network.

In Combination With the ERPC Platform

SLV's Solana v4 support works in any environment, and it pairs especially well with the ERPC platform. ELSOUL LABO operates a Solana-dedicated data center under its own ASN (AS200261), granted by RIPE NCC, as part of the ERPC platform — and there you can use the v4 optimizations, SLV's operation automation, and the ERPC platform together.

ERPC suppresses distance-induced latency at the design stage by placing source validators, receiving endpoints, and processing nodes inside premium data centers where Solana validators are densely concentrated. Solana RPC, WebSocket, Solana Geyser gRPC, Solana Shredstream, Direct UDP Stream (Raw Shreds), VPS, bare metal servers, SWQoS, the Pyth-compatible Price API, and Jet Analytics & Indexed RPC can all be combined on the same platform. Running a v4 validator built with SLV on the ERPC platform lets you combine SLV's optimizations with ERPC's design-level speed, in the same environment.

ERPC Official Site: https://erpc.global/en

Get Started Now With SLV AI Tokens

SLV's AI agent runs on SLV AI tokens. You can start for free — a €5 authorization provides 100,000 tokens, enough volume to experience enabling XDP, preparing BLS registration, and operating a Solana v4 validator through conversations with the AI agent.

ERPC SLV AI Plans: https://erpc.global/en/price/

Connections via ChatGPT and Claude API tokens are also supported, so you can run SLV AI with your own API keys.

Your Feedback Shapes SLV

SLV evolves every day through your feedback. This Solana v4 support, too, took shape through the voices shared in the Validators DAO official Discord and through running validators at the top of the network. Please try it out and share your thoughts and requests with us in the Validators DAO official Discord.

Thank you, as always. We appreciate your continued support of SLV and ERPC.

Contact

For inquiries about SLV and ERPC, please open a support ticket in the Validators DAO official Discord.

Validators DAO Official Discord: https://discord.gg/C7ZQSrCkYR

SLV Completes Solana v4 Support — XDP Turbine Acceleration and Alpenglow-Ready BLS Registration, Reproducible by Any Validator Through AI Agent Conversations