Solana's target slot time reached 200ms on mainnet on October 9, 2026. That does not give a searcher a guaranteed 200ms trading window. It does mean more slots—and more block data—per unit of time. The Solana Foundation notes that indexers need no format change, but should plan ingestion and storage capacity for roughly twice as many blocks per day as at 400ms.
For a searcher, the useful question is not simply How fast is my feed? It is: Can I turn an observation into a valid candidate, submit it through an appropriate execution path, and verify what actually happened? That is a pipeline problem.
1. Observe the signal without confusing it with execution
A low-latency searcher may start with raw Solana shreds and reconstruct the data it needs itself. That offers control over parsing and downstream logic, but also makes packet loss, deduplication, reconstruction, and receiver capacity the searcher's responsibility. UDP delivery is not ordered or retransmitted, and receiving part of a slot does not prove the slot is complete.
Another starting point is Decoded Transactions: authenticated gRPC events with signed transaction bytes, instructions, account keys, and observation metadata. These are useful for program- and account-focused strategies without building the entire reconstruction layer. An event represents observed signed intent, not proof that the transaction landed, succeeded, or became final. Treat reported gaps and stream resets as first-class events, not as empty market activity.
Neither feed is a private mempool, a preconfirmation service, or a transaction-execution guarantee. Choose the lowest layer that gives your strategy enough control without making your team maintain infrastructure it does not need.
2. Know which pools and accounts matter
A transaction only becomes interesting after the searcher maps its accounts and instructions to a strategy. Maintain a local inventory of supported pool identities, token pairs, programs, and dependency accounts. Shredo Pool Catalogue supplies signed full snapshots, pool search, and resumable inventory changes for this purpose.
That catalogue is a map, not a live price oracle. Pool membership does not establish current reserves, executable liquidity, or profitability. Read the relevant on-chain accounts and strategy-specific state separately, and record which state version you used to evaluate a candidate. If the inventory is stale or a dependency is missing, skip the opportunity rather than silently guessing.
3. Filter early; queue only work that can still matter
A practical first pass can discard transactions outside your watched programs, tokens, or pool dependencies. Deduplicate observations by an appropriate transaction identity, while preserving the slot and local receive timestamp for analysis. Then classify the remaining candidates: which accounts might change, which pools could be affected, and which strategy is eligible to react?
Keep the receiving loop small. Expensive decoding, account fetches, and strategy evaluation belong behind bounded queues. If a queue cannot drain at the incoming rate, a growing backlog turns a low-latency feed into a delayed one. Backpressure, drops, and gap events should be visible in metrics; they should never masquerade as a clean interval.
The 200ms upgrade makes this discipline more important, but it does not prescribe a universal millisecond budget. Measure the path on your own machines: received → classified → state loaded → simulated → submitted → landed or expired.
4. Simulate the candidate, not the assumption
Once a candidate passes your filters, assemble the transaction or bundle you would actually submit. Solana's simulateTransaction RPC simulates against chain data available at the requested commitment without broadcasting. Its result can reveal program errors, logs, and compute usage. It cannot promise that the same state will still be available when a leader processes your submission.
Your decision rule therefore needs a margin for fees, tips, state changes, and failed attempts. Reject candidates when required accounts cannot be resolved, relevant state is stale, or the expected edge disappears under conservative assumptions. Simulation is a risk filter, not a forecast of realized P&L.
5. Separate data ingestion from transaction submission
Shredo's feeds help you observe and organize data; they do not submit your trades. Your searcher must select and operate its own execution route. That might be standard Solana RPC or, for eligible strategies, a block-engine path such as Jito bundles. Those paths have different mechanics and economics, including fees or tips.
Most importantly, a successful sendTransaction response means the RPC accepted a signed transaction for forwarding. It does not mean the cluster processed or confirmed it. Track each attempt by signature and the route used. Avoid counting an accepted submission as a win.
The shorter slot schedule also makes fixed assumptions about time hazardous. Solana says a recent-blockhash lifetime of 150 blocks corresponds to roughly 30 seconds at 200ms, rather than about 60 seconds at 400ms. Refresh blockhashes and handle expiration using chain state, not a hardcoded timer. Source: Solana Foundation.
6. Reconcile outcomes and learn from misses
Use getSignatureStatuses or another suitable canonical execution source to determine whether your own transaction processed, failed, or reached the commitment level your accounting requires. Compare the actual result with the candidate's recorded inputs. At minimum, track:
- observation-to-decision latency and queue age;
- feed gaps, UDP loss indicators, and reconnection epochs;
- simulation failure and stale-state rejection rates;
- submission acceptance, landing, failure, and expiry by route;
- realized P&L after network fees, tips, and failed-attempt costs.
Those measurements tell you whether the bottleneck is data arrival, filtering, state access, simulation, or execution. “Our feed is fast” is not a substitute for knowing where your opportunities are lost.
A modular starting point
You do not need to buy or build every layer on day one. Start with Decoded Transactions if your strategy needs filtered signed-transaction events; choose Raw Shreds when you want to own the reconstruction path. Add Pool Catalogue if maintaining a verified pool/dependency inventory solves a real operational problem. The products are independent subscriptions, currently priced at 199, 99, and 49 USDC per calendar month, respectively.
The point is not to replace a searcher's strategy or execution stack. It is to make the data side explicit: what was observed, what was missing, which pools were known, and what was actually confirmed. In a 200ms slot era, clarity is as valuable as speed.
FAQ
Does a 200ms slot give my bot 200ms to trade?
No. It is a network target slot duration, not a guaranteed opportunity window or execution deadline.
Are observed shreds or decoded transactions proof of a successful trade?
No. They are early data observations. Confirm execution independently.
Can a pool catalogue replace live account state?
No. It identifies supported pools and dependencies; it does not provide current executable state or prices.