.jpg)
Continuing wave-breaking in the Solana ocean with you, the RPC Fast team is happy to announce the launch of RPC Fast Beam, a low-latency Solana transaction delivery service for HFT, MEV searchers, and liquidation bots. It helps route signed transactions through SWQoS validators, the Jito Block Engine, and partner infrastructure to enable faster landing and reduce latency variance.
Does your project need Beam?
Beam solves a specific problem for a specific audience: teams where transaction speed and landing probability directly impact revenue.
This includes:
- High-frequency trading systems that compete on milliseconds;
- MEV searchers and liquidation bots that need reliable execution during volatility;
- Arbitrage engines that depend on sub-slot confirmation;
- Latency-sensitive market makers who can't afford to miss opportunities;
- Wallets and dApps that need stronger delivery guarantees against sandwich attacks and front-running.
If your system sends fewer than 10 transactions per minute, or if transaction latency doesn't affect your bottom line, standard RPC endpoints are sufficient.

If you're running a trading bot, a liquidation protocol, or any system where execution speed determines profitability, Beam is built for you.
How Beam works: The architecture
When you send a transaction through Beam, it doesn't go to a generic RPC node. Instead, it's routed via your selected provider—Astralane, bloXroute, or Falcon—each with their own low-latency infrastructure.

Under the hood, Beam leverages provider-specific delivery paths:
- SWQoS-backed validator routes for priority propagation;
- Jito Block Engine submission for MEV-aware ordering;
- Harmonic and Rakurai infrastructure for alternative delivery paths.
The result: your transaction reaches the current leader faster and has a higher landing probability during congestion. In competitive conditions, this can mean the difference between execution and expiration.
Beam also supports two operational modes:
Choose the mode that matches your transaction intent. Both are available on all supported providers.
Key Beam features explained

1. Multiple provider routes
Beam doesn't lock you into a single delivery path. You can route through Astralane, bloXroute, or Falcon—each with different latency profiles and landing characteristics. The best practice is to distribute submissions across multiple providers in parallel to reduce reliance on any single route and improve overall resilience.
2. Real-time tip guidance
Beam provides a WebSocket tip feed that streams real-time percentile guidance for each provider. Instead of guessing tip amounts, you get live data on what's landing at the 25th, 50th, 75th, 95th, and 99th percentiles. Adapt your tip size dynamically based on network conditions.
3. Provider scoring feed
Another WebSocket stream tracks provider performance in real-time: landing latency, landing rate, and success rate. Use this to make intelligent routing decisions—send to the provider with the best current score, not the one with the best historical average.
4. Bundle support
For teams running MEV strategies or coordinated transactions, Beam supports sendBundle on Astralane and bloXroute. Submit multiple transactions atomically and let the provider handle ordering and inclusion.
5. Transparent rate limits
No hidden throttling. The Start plan gets 1 TPS. Paid plans get 15 TPS. That's it. Scale predictably without surprise rate-limit errors.
Setup and Integration
Getting started with Beam requires three steps:
Step 1: Append a tip instruction
Every transaction sent through Beam must include a valid tip transfer instruction to your chosen provider. Beam does not inject tips automatically—your application must append the instruction before signing.
// Example: Add tip instruction before signing
const tipInstruction = SystemProgram.transfer({
fromPubkey: payer.publicKey,
toPubkey: tipAccount, // Provider-specific tip account
lamports: tipAmount,
});
tx.add(tipInstruction);
tx.sign(payer);Step 2: Rotate tip accounts
Don't hardcode a single tip destination. Rotate across provider tip accounts on every transaction. This improves privacy and distributes load across the provider's infrastructure.
Step 3: Send via Beam endpoint
Use the Beam endpoint with your API key and optional query parameters:

Authorization via X-Token header or api_key query argument. Both work.
Quickstart: Send your first transaction
Here's a minimal example in TypeScript using the Solana Web3.js library:
import {
Keypair,
PublicKey,
SystemProgram,
Transaction,
Connection,
} from "@solana/web3.js";
const BEAM_URL = "https://beam.rpcfast.com/?mode=fastest";
const RPCFAST_TOKEN = "your-api-key";
const tipAccounts = [
"ASdXviZw2kbViFuAgZF26RPZL1HdybUoWdcveG2nfU8D", // astralane
"rfBP8KJ6KMqvBhmqaV7EoNHVexXQdn1sX4CJ9aLv5w2", // bloxroute
];
async function sendBeamTransaction(
payer: Keypair,
instructions: any[],
tipLamports: number
) {
const beamRpc = new Connection(BEAM_URL, {
commitment: "processed",
httpHeaders: { "X-Token": RPCFAST_TOKEN },
});
const { blockhash } = await beamRpc.getLatestBlockhash("processed");
const tx = new Transaction({
feePayer: payer.publicKey,
recentBlockhash: blockhash,
});
// Add your application instructions
for (const ix of instructions) {
tx.add(ix);
}
// Add tip instruction (rotate tip account)
const tipAccount = tipAccounts[Math.floor(Math.random() * tipAccounts.length)];
tx.add(
SystemProgram.transfer({
fromPubkey: payer.publicKey,
toPubkey: new PublicKey(tipAccount),
lamports: tipLamports,
})
);
tx.sign(payer);
// Send via Beam
const signature = await beamRpc.sendRawTransaction(tx.serialize(), {
skipPreflight: true,
maxRetries: 0,
});
return signature;
}Best practices for production
To maximize reliability and performance with Beam:
- Always include a valid tip instruction. Beam requires a tip on every transaction. No tip = send failure.
- Rotate tip accounts. Don't hardcode a single destination. Rotate across provider accounts to improve privacy and distribution.
- Distribute across providers. Send the same transaction to multiple providers in parallel. This reduces reliance on any single route and improves overall resilience.
- Use the tip feed. Subscribe to the WebSocket tip guidance feed and adapt your tip size dynamically based on network conditions.
- Monitor provider scores. Use the provider scoring feed to route to the best-performing provider in real-time.
- Handle retries in your application. Beam ignores
maxRetriesandskipPreflightparameters. Implement retry logic on your side. - Keep connections warm. Reuse a long-lived RPC client. Use HTTP/2 and enable TCP keepalive.
- Pair with Aperture gRPC. For latency-sensitive systems, combine Beam with Aperture gRPC to detect opportunities earlier and execute faster.
Pricing and availability
Beam is available on all RPC Fast plans—Start, Growth, Pro, and Business.
Each sendTransaction request costs 5 compute units. Bundle support (sendBundle) is available only on paid plans.
Rate limits:
- Start plan: 1 TPS
- Paid plans: 15 TPS
Beam is currently in beta. Core features may evolve as we gather feedback from production users. Rate limits are subject to change.
Benchmarking Beam in your environment
Beam is new. We encourage you to benchmark it against your current setup.
Measure what matters:
- Landing latency: Time between submission and first appearance in shreds
- Landing rate: Percentage of transactions that land within 3 slots
- Success rate: Percentage of valid transactions that don't fail on-chain
Use the provider scoring feed to track these metrics in real-time. Compare Beam against your current RPC provider during peak congestion windows (typically 14:00–18:00 UTC).
The numbers will speak for themselves.
Become the pioneer of RPC Fast Beam
Beam is in beta, and now we're actively developing additional provider integrations. We're open to communication with production users.
If you hit edge cases, have feature requests, or want to discuss your use case, reach out to support@rpcfast.com or join our community chat.



