SOLANA RPC COMMUNITY
Built for Solana builders.Run by operators.
Join builders running HFT bots, DEX tools, and AI agents on Solana.
Join Discord
Special offers
Live support
No spam
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 exchanges, built for venues whose liability depends on what they can prove, engineered to surface deposits before they become block data, let your own policy decide when a balance is credited, and land withdrawals through Beam.
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. Aperture is an early transaction stream, not a final source of execution truth, so crediting is always reconciled against confirmed state on your side.
197–231 µs median lead over shredded streams
Server-side filtering across your deposit address lists
Decoded instructions with lookup tables already resolved
Batches of up to 64 transactions, with an index field to restore order
Program-account queries that answer in time instead of timing out
Beam delivery for withdrawals, fastest or MEV-protected routing
1
A transaction enters the shred pipeline — before the block exists
2
Stream reconstructs and decodes it server-side, filtered to your deposit addresses
3
The prediction is attached at 791 µs for full payload, 832 µs for signatures only
4
Your ledger sees the incoming transfer before it is available as block data
5
You credit at the commitment level your policy chose, confirmed by a standard RPC call
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 see the deposit before the block forms?
Access tuned RPC, gRPC, and trading-grade streams from day one.
FAQ
An RPC endpoint is how an exchange talks to the Solana blockchain at all. Every deposit it detects, every withdrawal it broadcasts, and every settlement it confirms goes through that connection. When a user sends SOL to their deposit address, it is the exchange's RPC that spots the incoming transaction and confirms it; when the user withdraws, it is the same connection that pushes the signed transaction out to the network. Without reliable RPC access, an exchange simply cannot operate on Solana.
The user copies their deposit address from the exchange and sends SOL to it from a personal wallet. That transaction goes onto the chain, and the exchange's RPC connection is watching for it. Once the transaction has enough confirmations, the exchange credits the account and the user can trade immediately.
The speed of that RPC connection is what decides how quickly the deposit shows up. A slow endpoint means the user is refreshing the page waiting for funds that are already on-chain.
A centralized exchange like Binance or Crypto.com is custodial: it holds user funds, matches orders on its own servers, and operates under a regulatory regime. A decentralized exchange like Raydium or Orca is non-custodial: users keep their own funds, and trades execute against an automated market maker on-chain.
Both depend on RPC, but for different reasons. A CEX needs it for deposits, withdrawals and settlement, running very high request volumes against its own infrastructure. A DEX needs it because every swap is an on-chain transaction, so the RPC is the user's only path to the trade.
It scales with volume, because every deposit check, withdrawal and settlement is a separate RPC request. As a rough guide:
High-volume venues need an enterprise tier rather than a shared plan, mostly because shared endpoints throttle exactly when traffic peaks.
When a user requests a withdrawal, the exchange builds a transaction to the destination wallet, signs it with the key held in its custody system, and sends it to the network through its RPC endpoint. The network confirms it within a second or two, and the funds arrive.
Almost all of the variable time in that sequence sits in the broadcast and confirmation step, which is why withdrawal speed tends to track RPC quality more closely than anything else in the stack.
Under 50 milliseconds is what an exchange wants for active trading paths. Between 50 and 100 milliseconds is comfortable for settlement work. Deposits and withdrawals remain acceptable up to around 300 milliseconds, though users start noticing. Above that, complaints follow.
In practice most exchanges target under 100 milliseconds as their working ceiling, because that is the point at which deposit and withdrawal delays stop being visible to the person waiting.
The exchange watches the chain for the incoming transaction, verifies the signature and the amount, and waits for the transaction to be finalized before crediting anything. Once finalized, a Solana transaction cannot be reversed, which is what makes the credit safe.
A hot wallet is connected to the internet and typically holds somewhere in the range of 5 to 10 percent of an exchange's funds. It exists to make withdrawals fast, and it carries the corresponding risk. Cold storage keeps the remaining 90 to 95 percent offline, where it is far safer but much slower to access.
Exchanges run both. The hot wallet handles day-to-day operations through the RPC connection, while cold storage holds the bulk of customer assets and is only touched deliberately.
Differently from everyone else, and much more aggressively. HFT desks connect to the fastest endpoint they can get, stream real-time market data rather than polling for it, execute large numbers of trades per second, and settle continuously on-chain. Sub-10 millisecond latency matters to them because their edge is measured in the same units.
This is a professional requirement, not a general one. A regular exchange user gains nothing from that tier of infrastructure.
Congestion is where the difference between endpoints becomes obvious. On a slow or shared endpoint, withdrawals that normally take a couple of seconds start taking ten to thirty, because requests are queuing behind everyone else's. On a well-provisioned endpoint they stay in the two to three second range.
The underlying reason is that public endpoints degrade hardest at exactly the moment demand peaks, which is when your users are most likely to be watching.
The realistic risks are these:
The mitigations are mostly unglamorous: enforce HTTPS, monitor transactions independently rather than trusting a single source, keep custody keys in hardware, and use an endpoint you have a contractual relationship with rather than a public one.
On a DEX there is no central server holding funds or matching orders. The user connects a wallet, the RPC carries the swap transaction to the chain, and the smart contract executes it. Tokens move directly between wallets.
That means a DEX needs its RPC to be extremely reliable, because an outage stops trading entirely, but its raw throughput requirements are usually lower than a large CEX handling continuous deposits, withdrawals and internal settlement.
An exchange accepts SOL deposits, delegates the pooled stake to one or more validators, and passes a share of the resulting rewards back to users, typically on a monthly cycle. Tracking those rewards accurately means querying validator and account state through RPC on an ongoing basis.
During planned maintenance an exchange normally halts deposits and withdrawals while keeping the rest of the platform available. An unplanned RPC outage is worse, because the exchange loses its view of the chain: no new deposits can be detected, no withdrawals can be broadcast, and although internal order matching may keep running on the exchange's own servers, nothing can settle.
