SOLANA RPC COMMUNITY
Built for Solana builders.Run by operators.
Join builders running HFT bots, DEX tools, and AI agents on Solana.
Join DiscordSpecial offers
Live support
No spam

Solana RPC for AI agents, built for autonomous systems that act without a human in the loop, engineered to hand the model decoded current state, test an action before it is taken, and keep the bill countable in calls.
Unlike generic RPC polling or delayed WebSocket feeds, Aperture TxStream taps into native raw shred ingestion and streams decoded, filterable transactions over one production-ready gRPC interface.
1 CU per call, so an agent's budget is countable in calls
Decoded instructions with lookup tables already resolved
Batches of up to 64 transactions, with an index field to restore order
Separate applications per agent for separate analytics
Test a pending action before the agent commits to it
One endpoint exposed as a tool across every agent
1
The agent reads decoded instructions with lookup tables already resolved
2
The agent forms an intent and builds a transaction
3
The prediction is attached at 791 µs for full payload, 832 µs for signatures only
4
A predicted failure never reaches the chain, so it costs nothing
5
The agent retries with corrected parameters or reports the blocker
vs Jito ShredStream, signatures only
77.6%
of races — TxStream first
vs Jito ShredStream, full payload
75.6%
of races — TxStream first
vs Yellowstone gRPC
99.97%
of races — TxStream first
LEAD SOLANA. OWN THE TRADE
Ready to give your agent state it can act on?
Access tuned RPC, gRPC, and trading-grade streams from day one.
FAQ
An AI agent is an autonomous program that watches the chain, decides what to do, and acts without a human in the loop. It connects through an RPC endpoint, ingests real-time data, passes that data through a model, and submits transactions when its logic says the opportunity is there. The loop runs continuously: observe, evaluate, execute, then observe the result and adjust.
What separates an agent from a conventional trading bot is where the decision comes from. A bot follows rules someone wrote. An agent evaluates conditions against a model that was trained rather than hand-specified.
Because the opportunities they trade on do not last. A window of a few hundred milliseconds is normal on Solana, and the agent has to detect the condition, decide, and land a transaction inside it. Every millisecond spent waiting on the RPC layer comes out of that budget.
This is why the same agent logic produces very different results on different infrastructure. An agent on a slow or shared endpoint is not making worse decisions; it is making the same decisions too late for them to be worth anything.
The common categories are trading bots, market makers, arbitrage agents, liquidation hunters, portfolio managers, yield optimizers and analytics agents. They differ in what they optimize for, but they share the same shape: continuous data ingestion, a model that scores conditions, and automated execution.
Under 50 milliseconds is where agents operate comfortably. Between 50 and 100 milliseconds is workable for most strategies. Between 100 and 300 milliseconds you are still functional but losing contested opportunities to faster participants. Above 300 milliseconds, latency-sensitive strategies stop being viable, because the window has usually closed before the transaction arrives.
Where your strategy sits on that scale depends on what it competes for. A yield optimizer rebalancing hourly does not care. An arbitrage agent does.
The agent initializes a connection with its API key, subscribes to the data streams it needs rather than polling for them, feeds incoming events into its model, and submits transactions back through the same endpoint. After execution it monitors the outcome and feeds that result back into its own state.
The subscription step matters more than it looks. An agent that polls for state is reacting on a delay it cannot control, no matter how fast its model is.
Price data, liquidity pool state, trading volumes, account balances, on-chain events and market microstructure, updated continuously rather than on request. Active agents consume hundreds of updates per second.
It depends entirely on how often the agent acts and how heavy its model is:
Cloud hosting is easier to scale and quicker to start with. Dedicated hardware works out cheaper over time and gives you control over placement, which matters once physical distance to the leader becomes your bottleneck.
Yes, and most serious deployments do. Running five or ten wallets with separate strategies is common, with each position carrying its own risk limits so that one strategy failing does not drain the others.
The practical constraint is request volume. Every wallet the agent monitors and every position it manages multiplies its RPC usage, so multi-wallet operation needs a plan sized for that throughput rather than an entry tier.
Three line items: the RPC plan, the hosting, and any external data or API subscriptions. Hosting is usually the largest of the three, and it scales with how demanding the strategy is.
Through a mix of approaches. Reinforcement learning lets an agent adjust based on the outcome of its own trades. Supervised learning trains it on labelled historical data. Unsupervised methods surface patterns nobody specified in advance.
In practice the early gains are the largest, because the initial model is usually the crudest. After that, improvement slows and the work shifts from training to maintenance: models drift as market conditions change, so retraining is an ongoing operational task rather than a one-time step.
The exposures fall into a few groups:
Most of these are mitigated the same way: isolate keys from the agent process, test against historical and simulated conditions before deploying capital, monitor live behaviour rather than assuming it matches the backtest, and cap exposure so a single failure is survivable.
Continuous operation is an infrastructure problem, not a model problem. The pattern that holds up is redundant endpoints with automatic failover, health checks frequent enough to catch a stall before it costs money, automatic restart on crash, and deployments that roll out without taking the agent offline.
The failure that hurts most is the silent one: an agent that is running but reading stale data. That is why health checks should verify freshness, not just that the process is alive.
Yes, provided they are not chasing the same opportunity. Arbitrage, market making and yield farming operate on different signals and do not interfere with each other. Two arbitrage agents pointed at the same pair on the same venue absolutely do compete, and the usual result is that they bid against each other and both do worse.
If you run several agents, separate them by strategy and market rather than by wallet.
TensorFlow and Keras are common for deep learning work, PyTorch dominates in research, XGBoost is popular where inference has to be fast, and Scikit-Learn covers the simpler models. On architecture: LSTMs are still used for price sequences, transformers for more complex pattern work, and reinforcement learning where the agent needs to learn from its own outcomes.
The framework matters less than the latency budget it fits into. A model that takes 200 milliseconds to run has already spent most of the window, regardless of how good it is.