For the complete documentation index, see llms.txt. This page is also available as Markdown.

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

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

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_key query argument

  • X-Token header

Query argument

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.

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.


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:

Method
Use when
Response

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:

  • provider is 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 signature is provided, Beam can use it for landing metrics.

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.

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

Provider
Tip accounts
Min. required tip
Bundle support
Mode support

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.

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.

QUIC submissions are subject to the same Beam plan limits as HTTP submissions. sendTransactionFast counts as a transaction submission request.

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


Supported Submission Methods

Beam currently supports HTTP JSON-RPC and QUIC submission methods.

HTTP JSON-RPC supports:

  • sendTransaction

  • sendBundle

QUIC supports:

  • sendTransaction

  • sendTransactionFast

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.

  • For Rust QUIC integrations, use the shared beam-quic-client crate 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 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 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 BeamQuicClient instead of reconnecting per transaction.

  • Use regular QUIC sendTransaction when you need Beam response feedback.

  • Use sendTransactionFast only when your application can handle fire-and-forget submission.

  • Pass signature to sendTransactionFast when you want Beam-side landing metrics.

  • Choose provider explicitly for sendTransactionFast.

light-emergency-on

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