◆ FOR TRADING BOTS

Solana infrastructure for trading bots.

A trading bot is only as fast as the infrastructure under it. Here is the read-and-send path that decides whether your bot is early or late.

Get Started →See the numbers →

◆ THE WORKLOAD

What decides the outcome.

A trading bot watches network state, decides, and submits - in a loop, continuously, against everyone else doing the same. Every millisecond between an on-chain event and your reaction is edge you either keep or give away. The bottleneck is almost never your code; it is the distance and hops between you and the cluster, and how your transactions reach the leader.

  • Polling a shared RPC adds request latency and serialization overhead on every loop, and rate-limits you exactly when the network is busiest - which is when opportunities appear.
  • Reacting at confirmed commitment means acting on state everyone already sees. First-seen data from the propagation layer moves your decision point earlier in the slot.
  • A competitive priority fee still misses if the transaction takes a slow, forwarded path to the leader. Landing is a path problem, not just a fee problem.

◆ THE STACK

The path, mapped.

Yellowstone gRPC

One long-lived stream pushes accounts, transactions, and slots as the validator processes them - no polling loop, no rate limits, server-side filters.

Explore Yellowstone gRPC →

Decoded shreds

First-seen transaction intent read from the shred layer, before a block is assembled - the earliest your bot can react.

Explore Decoded shreds →

Transaction sender

Delivers straight to the current and upcoming leaders' TPUs over QUIC, with optional Jito-bundle and staked paths, so a good decision actually lands.

Explore Transaction sender →

Solana RPC

Co-located HTTP + WebSocket for the reads, simulations, and history around the hot path.

Explore Solana RPC →

◆ FAQ

Straight answers.

What is the best Solana RPC for trading bots?
The one with the shortest, most predictable path to the cluster for your bot's location - measured, not claimed. For latency-sensitive bots that means co-located, low-hop infrastructure with a gRPC stream (to avoid polling) and a transaction sender that delivers to the leader directly. Read latency, first-seen timing, and landing rate matter more than a headline number; benchmark them for your workload.
Do I need Yellowstone gRPC, or is JSON-RPC enough for a bot?
For a low-volume or non-time-sensitive bot, JSON-RPC is fine. For anything competitive, a gRPC stream removes the polling loop and its rate limits, and pushes state the moment the validator processes it - a structurally earlier and cheaper read path than polling.
Will a higher priority fee make my bot's transactions land?
It helps you win block space, but landing also depends on reaching the current leader in time. A fast fee on a slow, forwarded path still misses. Co-location and a direct-to-leader sender shorten that path; use the priority fee estimator to price the fee itself.

If your bot is fighting the infrastructure instead of the market, that is a fixable problem. Tell us the workload and we will map the path.

Get Started →See pricing →