RPC Fast Beam (Beta)
Solana transaction delivery for latency-sensitive workloads.
Overview
RPC Fast Beam is a low-latency Solana transaction submission service for execution-sensitive systems.
Beam routes signed transactions through partner delivery paths such as SWQoS-backed validators, Jito Block Engine submission, and other provider-specific low-latency infrastructure. This improves landing probability during congestion and reduces latency variance.
Beam is built for HFT, MEV searchers, liquidation bots, arbitrage engines, latency-sensitive market makers, and apps that care about delivery quality.
Beam is also useful for users who need maximum transaction protection from sandwich attacks, front-running, and toxic MEV.
At a Glance
Purpose
Fast Solana transaction delivery
HTTP endpoint
https://beam.rpcfast.com
QUIC endpoint
beam.rpcfast.com:9900
Tip feed
wss://beam.rpcfast.com/tips?provider=<provider>
Provider score feed
wss://beam.rpcfast.com/provider-scores
HTTP methods
sendTransaction, sendBundle
QUIC methods
sendTransaction, sendTransactionFast
Rust QUIC client
Providers
astralane, bloxroute, nozomi, falcon
Modes
fastest, mev_protect
Authorization
api_key query arg or X-Token header
Availability
All plans
CU cost
5 CU per request
Rate limit
Start plan -
60 txs/minuteFocus plan -
200 txs/minuteStream, Aperture -
500 txs/minute
Required on every send
Tip transfer instruction
Ignored on send path
Node-side retries and preflight controls
How Beam Works
When you send a transaction through Beam, it’s routed via your selected provider.
Under the hood, Beam leverages provider-specific low-latency infrastructure – such as SWQoS-backed validator paths, Jito Block Engine, Harmonic, or Rakurai submission – to maximize how quickly your transaction reaches the current leader. In competitive conditions, this can significantly improve landing probability.
This becomes critical in scenarios where packet delivery speed matters just as much as on-chain priority fees.
For deeper background, see SWQoS and Aperture gRPC.
Abuse prevention policy
Users are prohibited from abusing the platform infrastructure, including but not limited to excessive spam transaction generation, persistent failed bundle submissions, artificial traffic amplification, or any activity that negatively impacts platform stability, SWQoS partners, or other users of the service.
Because our sender service is currently provided in Beta, our abuse-detection systems, fair-use thresholds, rate limits, and enforcement policies may change at any time without prior notice. We reserve the right to make enforcement decisions at our sole discretion when necessary to protect the platform, infrastructure providers, or other users. Read more in the Terms of Service.
Endpoints
Transactions submission endpoint
Supports sendTransaction and sendBundle methods.
QUIC submission endpoint
Use the Beam QUIC endpoint provided for your account.
Tip guidance feed
Replace <provider> with one of:
Authorization
Beam accepts an API key through either of these methods:
api_keyquery argumentX-Tokenheader
Query argument
Header
QUIC
For QUIC, pass the same RPC Fast API key to BeamQuicClient::connect. The client authenticates with an ephemeral client certificate whose Common Name contains the API key; the key is not sent as a query argument, HTTP header, or request-frame field.
Query Arguments
Beam supports transaction mode selection and provider override through URL query arguments.
Provider override
If provider is not specified, Beam detects the provider from the tipping address you have included in your transaction.
Example
Submit mode
If mode is not specified, Beam uses fastest by default.
Supported modes depend on the selected provider. See Providers.
fastest
Lowest possible submission latency matters most
Best for HFT, arbitrage, liquidations, and same-slot competition
mev_protect
Protection against frontrunning, backrunning and sandwiching matters most
Best for sensitive order flow and execution privacy
Choose the mode that matches the intent of the transaction.
QUIC Transaction Submission (Beta)
Use Beam QUIC when transaction delivery latency matters more than HTTP compatibility. It is best suited for HFT systems, MEV searchers, liquidation bots, arbitrage engines, and market makers that keep a long-lived sender process running.
Beam QUIC supports:
sendTransaction
You want low-latency submission and still need Beam to return the signature and routed provider.
✅
sendTransactionFast
You want the lowest-latency fire-and-forget path and can track the transaction in your own system.
❌
sendTransactionFast is intentionally a separate low-latency path:
provideris required.Beam does not return a response.
Beam does not wait for an upstream provider response.
Beam skips Beam-side transaction deserialization, signature extraction, and tip validation.
If
signatureis provided, Beam can use it for landing metrics.
Use regular QUIC sendTransaction if your application needs immediate request-level feedback. Use sendTransactionFast only when your application can handle fire-and-forget submission.
Rust QUIC client
The recommended Rust integration is the shared beam-quic-client crate.
The client reuses a QUIC connection, generates the Beam client certificate automatically, places your API key in the certificate Common Name, and reconnects if the connection is closed.
See the Rust QUIC tab in Code Examples for a complete integration that fetches a blockhash, appends a provider tip, signs the transaction, and submits it through beam-quic-client.
Providers and Tips
Every transaction sent through Beam must include a valid tip instruction to the addresses provided in these docs.
RPC Fast Beam does not inject tip instructions automatically. Your application must append the provider-specific tip transfer before signing and sending.
Sending a transaction without a valid provider tip is not supported and will lead to send failure.
It is strongly recommended to rotate the tip account on every transaction.
Regular QUIC sendTransaction follows the same provider and tip validation rules as HTTP sendTransaction.
sendTransactionFast requires an explicit provider and skips Beam-side tip validation/signature extraction for latency reasons. Your transaction should still include the appropriate provider tip instruction before signing.
Providers
Astralane
0.0001 SOL
✅
fastest, mev_protect
bloXroute
0.001 SOL
✅
fastest, mev_protect
Nozomi by Temporal
0.001 SOL
❌
fastest
Falcon by Corvus
0.001 SOL
❌
fastest
sendBundle is supported only by astralane and bloxroute.
mev_protect is supported only by astralane and bloxroute.
Recommended tip amounts
RPC Fast Beam provides real-time tip guidance over WebSocket.
WebSocket URL
Example response
All percentile values are denominated in SOL.
Higher percentiles generally improve landing probability during contention. Lower percentiles may be enough in quieter conditions.
Provider score feed
RPC Fast Beam provides real-time provider scoring feed over WebSocket.
WebSocket URL
Example response
Response fields
landing_latency- delay between transaction received on Beam and first seen across shreds.landing_rate- ratio of landed vs sent transactionssuccess_rate- ratio of valid vs sent transactionsscore- computed score with following weights50 for landing_rate
30 for landing_latency
20 for success_rate
Pricing & Availability
Beam is available on all RPC Fast plans!
Transaction bundles submission is available only on paid plans.
Compute Units cost
Each transaction submission request costs 5 CU.
Rate limits
RPC Fast Beam currently offers:
60 transactions per minute on Start plan
200 transactions per minute on Focus plan
500 transactions per minute on Stream and Aperture plans
These limits apply to both sendTransaction and sendBundle methods. Each transaction in a bundle is taken into account when calculating the rate limit.
QUIC submissions are subject to the same Beam plan limits as HTTP submissions. sendTransactionFast counts as a transaction submission request.
Please note that Beam has built-in spam classifier, so you need to maintain the quality of your transactions, otherwise rate limit penalties may be applied to your account.
For more info: Spam Transactions & Abuse Prevention Policy (Beta)
Supported Submission Methods
Beam currently supports HTTP JSON-RPC and QUIC submission methods.
HTTP JSON-RPC supports:
sendTransactionsendBundle
QUIC supports:
sendTransactionsendTransactionFast
sendTransaction
Submit a signed transaction using the standard Solana JSON-RPC payload.
Ignored sendTransaction options
Beam ignores Solana retry and preflight controls on the send path.
The following parameters are ignored:
maxRetriesskipPreflight=false
Retry logic must be implemented in your application. If a transaction does not land, rebuild or re-sign as needed and resubmit according to your own policy.
sendBundle
Use sendBundle when submitting bundles through a supported provider path. Bundles are mostly used in cases where you need atomic execution of transactions. These transactions are executed sequentially. If one of transaction fails the whole bundle gets reverted and never appears on-chain.
Supported providers: astralane, bloxroute.
Code Examples
The same rules apply in every language:
Reuse one RPC client across all sends.
Use HTTP/2.
Keep connections warm.
Enable keep-alive and TCP keepalive where supported.
Rotate the tip account for every transaction.
Append the tip instruction before signing.
For Rust QUIC integrations, use the shared
beam-quic-clientcrate and reuse one long-lived client.
For fire-and-forget submission, use sendTransactionFast:
Best Practices
For best results with RPC Fast Beam:
Always include a valid tip transfer instruction.
Use appropriate tip account when specifying
providerquery parameter.Use only those tip accounts specified in our docs, otherwise request will be rejected.
Rotate tip accounts instead of hardcoding one destination.
Send transaction to multiple providers in round-robin for better resilience.
Use the WebSocket tip feed to adapt tip size dynamically.
Use provider score websocket feed to check which provider performs better.
Reuse a long-lived RPC client.
Use HTTP/2 and keep connections warm.
Handle retries in the application.
Do not rely on preflight checks on the send path.
Keep your signing and submission path hot.
Reuse one long-lived
BeamQuicClientinstead of reconnecting per transaction.Use regular QUIC
sendTransactionwhen you need Beam response feedback.Use
sendTransactionFastonly when your application can handle fire-and-forget submission.Pass
signaturetosendTransactionFastwhen you want Beam-side landing metrics.Choose
providerexplicitly forsendTransactionFast.
For latency-sensitive systems, pair Beam with the Aperture gRPC to detect opportunities earlier. Teams that prefer lower-level data can also use Shredstream, with more client-side decoding work.
Quick Reference
Endpoint
QUIC endpoint
Supported HTTP JSON-RPC methods
Supported QUIC methods
Query arguments
Defaults
Tip feed
When to Use Beam
Beam is a strong fit for:
High-frequency trading systems
MEV searchers
Liquidation bots
Arbitrage engines
Latency-sensitive market makers
Wallets or apps that need stronger delivery guarantees
Users who want protection from backrunning and sandwich attacks
For standard, low-priority transaction flows, a regular Solana RPC endpoint may be sufficient.
Selecting Provider: Use Cases
A good rule of thumb is to split Beam use cases into two categories:
Atomic, coordinated execution – use providers with Bundle support (Astralane, bloXroute).
Single-transaction speed and landing probability – any provider (Nozomi, Falcon, Astralane, bloXroute), selecting the one with the best real-time performance score. Beam's provider scoring feed is designed exactly for this.
Use Bundle-capable providers (Astralane & bloXroute) for:
MEV searchers
Multi-leg arbitrage
Complex liquidation strategies
Any workflow requiring atomic execution
User-facing swaps that need
mev_protect
Use any Beam provider for:
HFT
Market making
Simple arbitrage
Standard liquidation bots
General latency-sensitive transaction submission
The use of the fastest and mev_protect modes:
fastest→ optimize for lowest latency and highest landing probability (HFT, liquidations, market making).mev_protect→ optimize for execution privacy and protection from frontrunning/sandwich attacks (wallets, swaps, sensitive order flow).
Last updated