RPC Fast Beam (Beta)
Solana transaction delivery for latency-sensitive workloads.
Overview
RPC Fast Beam is currently in beta. Core changes may be introduced as the product evolves.
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.
RPC Fast Beam is a transaction delivery service – not a general-purpose Solana RPC endpoint.
At a Glance
Purpose
Fast Solana transaction delivery
HTTP endpoint
https://beam.rpcfast.com
Tip feed
wss://beam.rpcfast.com/tips?provider=<provider>
Provider score feed
wss://beam.rpcfast.com/provider-scores
Supported methods
sendTransaction, sendBundle
Providers
astralane, bloxroute, 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 (Beta).
Best practices
To maximize reliability and performance, distribute your transaction submissions across multiple providers in parallel. This reduces reliance on any single route and improves overall resilience.
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 Terms of Service.
Endpoints
Transactions submission endpoint
Supports sendTransaction and sendBundle methods.
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
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
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.
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.
Providers
Astralane
✅
fastest, mev_protect
bloXroute
✅
fastest, mev_protect
Falcon by Corvus
❌
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.
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)
Beam is currently in beta, and rate limits are subject to change as the service evolves.
Supported JSON-RPC Methods
Beam currently supports:
sendTransactionsendBundle
sendTransaction
Submit a signed transaction using the standard Solana JSON-RPC payload.
Ignored sendTransaction options
sendTransaction optionsBeam 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.
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 parallel for better resilience.
Use the WebSocket tip feed to adapt tip size dynamically.
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.
For latency-sensitive systems, pair Beam with the Aperture gRPC (Beta) to detect opportunities earlier. Teams that prefer lower-level data can also use Shredstream, with more client-side decoding work.
Quick Reference
Endpoint
Supported Solana RPC 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.
Last updated