Speed in an on-chain trading system is rarely determined by a single component. The network connection matters, but so do serialisation, decoding, filtering, strategy evaluation, signing and transaction submission.
This is why developers optimising Solana bots eventually encounter a less glamorous question: how much irrelevant data is the application processing?
A real-time stream that delivers everything can look impressive in a benchmark while forcing the application to spend CPU time throwing most of it away. Server-side filtering changes that equation by reducing the amount of data that reaches the bot in the first place.
The Hidden Cost of the Firehose
Imagine that a strategy only reacts to activity from a handful of programs. If the data provider sends a much broader transaction stream, the client must repeatedly receive the message, deserialise it, inspect accounts and program IDs, determine whether it is relevant and discard it if it is not.
Each operation may be cheap individually. At Solana scale, cheap operations multiplied by a large event rate become real infrastructure work.
The impact appears in several places, including higher network bandwidth, more CPU usage, increased memory pressure, more garbage collection in managed runtimes, larger internal queues during bursts and additional parsing work on the latency-sensitive path.
Filtering closer to the data source can eliminate a large portion of this work.
Yellowstone Subscriptions Already Support Filtering
One reason Yellowstone-style gRPC became popular is that subscriptions can be expressed around the data a client needs. Developers can subscribe to accounts, transactions, slots, blocks and related updates while specifying filters.
The exact subscription design depends on the application, but the principle is simple: ask the stream for the smallest useful data set.
A Pump.fun monitor should not need to behave like a general-purpose Solana indexer. A Raydium pool watcher should not need every vote transaction. A copy-trading system watching a finite wallet set should not process unrelated account activity.
The closer the stream matches the strategy, the less work remains in the client’s hot path.
Filtering and Parsing Are Different Optimisations
Filtering answers a simple question: should this event reach the application at all?
Parsing answers another: once the event arrives, how much work is needed before the application can use it?
Raw protobuf is efficient, but many trading strategies still need application-specific decoding after receiving the message. Depending on the protocol, that can include Borsh decoding, account-index resolution, instruction interpretation and conversion into a domain model.
Some infrastructure services expose higher-level or pre-parsed data for common programs. Subglow’s filtered Solana gRPC streams, for example, are positioned around server-side filtering and pre-parsed output for selected trading-oriented programs.
That approach is not automatically right for every team. Raw data provides maximum control and can be preferable when a strategy depends on custom decoding or unsupported programs. The relevant engineering question is where parsing belongs.
Build Versus Buy
A team can implement its own parsing pipeline on top of a raw Yellowstone stream.
That may make sense when the protocol is proprietary, the team needs custom data representations, deterministic control over decoding is critical, the application already has a mature parser or infrastructure cost matters more than engineering time.
A managed parsed stream can make more sense when the strategy uses common programs, development speed matters, client CPU is part of the latency budget, the team wants fewer dependencies in the execution loop or maintenance of changing program layouts is undesirable.
Neither answer is universally correct. The mistake is ignoring parsing work because it happens after the network packet arrives.
Think in Terms of a Latency Budget
A useful way to optimise a trading system is to break the path into stages:
event observed
↓
provider receives event
↓
network transport
↓
client receives message
↓
decode / parse
↓
filter / strategy evaluation
↓
build transaction
↓
sign
↓
submit
If a team only measures provider-to-client network latency, it can miss bottlenecks in parsing and application logic.
Suppose two providers differ by 10 milliseconds in delivery time, but one reduces 25 milliseconds of client-side parsing for the target workload. The “slower” network product may still produce the faster decision loop.
The only useful benchmark is therefore an end-to-end benchmark that reflects the actual application.
Filtering Also Improves Reliability
Lower data volume is not just a performance advantage.
During a traffic spike, applications can fall behind. Queues grow, memory pressure increases, and reconnecting can become more difficult if a client has a large amount of data to catch up on.
A well-targeted subscription reduces the number of messages that must be processed during those periods. That improves the headroom available for unexpected bursts.
This is especially relevant for bots written in JavaScript, Python or other environments where allocation pressure and garbage collection can be visible during high-volume periods.
Avoid Overly Broad Subscriptions
Where possible, subscriptions should be filtered by program IDs, with irrelevant vote or failed transactions excluded when the strategy does not need them. Applications should subscribe only to the required commitment levels and avoid duplicate subscriptions that deliver the same underlying events.
It can also be beneficial to separate latency-sensitive streams from analytics workloads and monitor queue depth, processing lag and reconnect frequency. Parsing performance should be profiled rather than assuming where time is being spent.
The biggest improvement may not come from a new server. It may come from receiving less data.
The Broader Lesson
Solana infrastructure is often marketed around “fast RPC” or “low-latency gRPC.” But trading performance is a systems problem.
A high-performance bot needs a data path that is fast, selective, predictable and resilient. Server-side filtering can contribute to all four by shrinking the workload before it reaches the application.
For teams building real-time strategies, that makes filtering more than an API feature. It becomes part of the execution architecture.
