Validators DAO Updates the TypeScript Yellowstone Geyser gRPC Client in Solana Stream SDK. NAPI-RS Integration Improves Performance and Stability for High-Frequency Streaming
Validators DAO Updates the TypeScript Yellowstone Geyser gRPC Client in Solana Stream SDK. NAPI-RS Integration Improves Performance and Stability for High-Frequency Streaming

ELSOUL LABO B.V. (Headquarters: Amsterdam, Netherlands; CEO: Fumitake Kawasaki) and Validators DAO announce a major version update to the TypeScript client of the open-source Solana streaming framework “Solana Stream SDK,” enabling the TypeScript Yellowstone Geyser gRPC client to leverage NAPI-RS (Rust native implementation).
With this update, Solana Stream SDK improves processing headroom and stability for high-frequency streaming workloads while preserving the TypeScript development experience. Even under peak traffic and continuous event bursts, the system is designed to remain stable and resistant to breakdown. In addition, the starter code has been restructured beyond simple connectivity samples and is now organized as a Production-Ready foundation, designed for real-world operation and extensibility.
Practical Conditions for Handling Real-Time Streams in TypeScript
Solana streams are used in domains where real-time responsiveness directly translates into value, such as trading, monitoring, analytics, and operational decision-making. At the same time, many real-world development environments are fundamentally web-based, making TypeScript a strong choice due to development speed, maintainability, team flexibility, and ease of handover.
What matters, therefore, is not merely that streams can be handled in TypeScript, but that high-frequency streams can be processed realistically and sustainably in TypeScript without collapsing under long-term operational conditions.
Why Node.js Single-Threaded Execution Becomes a Bottleneck Under Peak Load
High-frequency streaming involves continuous reception, processing, filtering, decoding, and downstream logic execution, all running simultaneously. Under these conditions, a single-threaded Node.js execution path is prone to backpressure during bursts or short-term load spikes.
In practice, this often manifests as increased latency, processing backlog, dropped events, and frequent reconnections. While TypeScript excels in development speed and maintainability, the key operational challenge is whether sufficient processing headroom can be maintained during peak streaming conditions. This update directly addresses that challenge.
Previous and Expanded Scope of NAPI-RS Integration
Previously, within Solana Stream SDK, NAPI-RS was primarily utilized in the Shreds gRPC TypeScript client. With this update, NAPI-RS (Rust native) support has been extended to the widely used Yellowstone Geyser gRPC TypeScript client.
This expansion significantly increases the portions of the streaming pipeline that can benefit from low-overhead native execution while retaining a TypeScript-based interface. Internal benchmarks show a substantial improvement in backpressure tolerance under peak load, with processing headroom increasing by up to approximately four times. The key outcome is not the numeric multiplier itself, but the shift toward behavior that avoids collapse under peak conditions and can be treated as a reliable operational baseline.
Compared to alternatives such as WebAssembly (WASM), NAPI executes native code directly, enabling lower latency and higher throughput. Within Solana Stream SDK, NAPI-RS plays a central role in elevating real-time stream performance without sacrificing the TypeScript developer experience.
The Significance of Using Yellowstone Geyser gRPC in TypeScript
Geyser gRPC is a core interface for receiving low-latency streams of transactions, account updates, and slot events. Delays or data loss directly translate into missed trading opportunities, delayed monitoring and operational decisions, and increased development and operational costs.
Enabling realistic, peak-resilient operation of this core interface in TypeScript is not merely a matter of speed. It reduces friction across both development and operations, allowing teams to continuously improve their systems without switching stacks or rewriting core logic.
Redefining Starter Code as Production-Ready
Previously, starter code primarily served as an entry point for quick connectivity testing. In real-world operations, however, issues such as disconnections, reconnections, stream continuity, duplication or loss, subscription filtering, and peak-load control are unavoidable.
If the initial structure is too lightweight, these real-world requirements are often added later in an ad hoc manner, introducing structural distortion and increasing long-term maintenance costs. This update reorganizes the starter code as a foundation that can withstand real operational demands from the outset.
Clarifying Extension Points Through Structural Refactoring
On the TypeScript side, responsibilities have been clearly separated to make extension points explicit. The entry point is kept minimal and focused on wiring and startup, while processing logic is isolated into handlers. Hooks such as onTransaction and onAccount define clear insertion points for custom logic.
This structure allows trading logic, detection logic, filtering policies, and output destinations to be modified locally and predictably. Subscription definitions have also been unified into TypeScript code rather than JSON-based configurations, improving readability and type safety. Readable constructs such as CommitmentLevel.PROCESSED reduce configuration drift between code and runtime behavior.
Making Operational Stability a First-Class Assumption
In high-frequency streaming, speed alone is insufficient; resilience is equally critical. This update continues to provide built-in mechanisms such as backpressure controls (bounded queues, drop logging), metrics for received, processed, and dropped events, connection keepalive (ping/pong), exponential backoff, and from_slot-based gap recovery.
These are not optional enhancements but baseline requirements for production streaming systems. Treating starter code as Production-Ready means embedding these assumptions from the beginning rather than layering them on later.
Intended Users and Use Cases
This update targets developers who want to operate real-time Solana streams in production using TypeScript, teams building low-latency detection, trading, and monitoring systems with Yellowstone Geyser gRPC, and developers who face challenges related to peak-load handling and reconnection behavior. The goal is to raise the operational viability of TypeScript-based streaming without sacrificing its inherent advantages.
References
Updates to Solana Stream SDK are available on GitHub. Feedback is welcome either on GitHub or via the Validators DAO official Discord.
ERPC provides Solana streaming infrastructure across multiple regions. Using the Solana Stream SDK starter code, developers can validate behavior directly against real Geyser gRPC environments. Through ERPC’s free trial, it is also possible to evaluate the SDK and streaming infrastructure together in conditions close to real-world production. Further details are available on the ERPC official website.
Validators DAO Official Discord: https://discord.gg/C7ZQSrCkYR
Solana Stream SDK (GitHub): https://github.com/ValidatorsDAO/solana-stream
ERPC Official Website: https://erpc.global/
Solana Stream SDK (GitHub): https://github.com/ValidatorsDAO/solana-stream
ERPC Official Website: https://erpc.global/


