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

Capability
Details

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/minute

  • Focus plan - 200 txs/minute

  • Stream, 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_key query argument

  • X-Token header

Query argument


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.

Mode
Use when
Notes

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.

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

Provider
Tip accounts
Bundle support
Mode support

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.

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 transactions

  • success_rate - ratio of valid vs sent transactions

  • score - computed score with following weights

    • 50 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.

Beam is currently in beta, and rate limits are subject to change as the service evolves.


Supported JSON-RPC Methods

Beam currently supports:

  • sendTransaction

  • sendBundle

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:

  • maxRetries

  • skipPreflight=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 provider query 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.

light-emergency-on

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