Best Performance for Landing Transactions

Guidelines for improving transaction landing speed through priority fees, tips, and optimized submission flow.

Optimizing Transaction Performance

For paid tiers, bloXroute automatically enhances transaction propagation using multiple advanced features.

To ensure high speed and inclusion rate for singular transactions, follow these guidelines:

1. Priority Fee:

Add a compute price instruction to improve validator prioritization within the slot.
Total priority fee is calculated as: compute unit limit × compute unit price
Use the Priority Fee Stream to fetch current market recommendations and pair them with a realistic compute unit limit for your transaction.

const modifyComputeUnits = ComputeBudgetProgram.setComputeUnitLimit({ 
  units: 1000000 
});

const addPriorityFee = ComputeBudgetProgram.setComputeUnitPrice({ 
  microLamports: 1 
});

const transaction = new Transaction()
.add(modifyComputeUnits)
.add(addPriorityFee)
...
  );

let txn = submit_transaction(
  &connection,
  &wallet_signer,
  // Array of instructions: 0: Set Compute Unit Limt, 1: Set Prioritization Fee, 
  // 2: Do something, 3: Do something else
  [ComputeBudgetInstruction::set_compute_unit_limit(1_000_000u32),
  ComputeBudgetInstruction::set_compute_unit_price(1u32),
  ...
)?;

2. Include a Tip Instruction:

Ensure your transaction includes a tip for enhanced propagation.
Larger tips increase the your transactions priority when propagating through our systems.
Avoid using address lookup tables (ALTs) in your bloXroute tip instruction to avoid potential lookup overhead.

import (
	"github.com/gagliardetto/solana-go"
	"github.com/gagliardetto/solana-go/programs/system"
)

const (
	// BloxrouteTipAddress is from here and may fall out of date from time to time. Check our docs:
	// https://docs.bloxroute.com/solana/trader-api-v2/front-running-protection-and-transaction-bundle
	BloxrouteTipAddress = "HWEoBxYs7ssKuudEjzjmpfJVX7Dvi7wescFsVx2L5yoY"
)

// CreateBloxrouteTipTransactionToUseBundles creates a transaction you can use to when using PostSubmitBundle endpoints.
// This transaction should be the LAST transaction in your submission bundle
func CreateBloxrouteTipTransactionToUseBundles(privateKey solana.PrivateKey, tipAmount uint64, recentBlockHash solana.Hash) (*solana.Transaction, error) {
	recipient := solana.MustPublicKeyFromBase58(BloxrouteTipAddress)

	tx, err := solana.NewTransaction([]solana.Instruction{
		system.NewTransferInstruction(tipAmount, privateKey.PublicKey(), recipient).Build()}, recentBlockHash)
	if err != nil {
		return nil, err
	}

	signatures, err := tx.Sign(func(key solana.PublicKey) *solana.PrivateKey {
		if key.Equals(privateKey.PublicKey()) {
			return &privateKey
		}
		return nil
	})
	if err != nil {
		return nil, err
	}

	tx.Signatures = signatures

	return tx, nil
}

import {
    Keypair,
    PublicKey,
    Transaction,
    TransactionInstruction,
    MessageCompiledInstruction,
    VersionedTransaction,
    SystemProgram,
} from "@solana/web3.js"

// check documentation for latest tip wallet, and how to send tip transactions
// https://docs.bloxroute.com/solana/trader-api-v2/front-running-protection-and-transaction-bundle
const TRADER_API_TIP_WALLET = "HWEoBxYs7ssKuudEjzjmpfJVX7Dvi7wescFsVx2L5yoY"

// createTraderAPIMemoInstruction generates a transaction instruction that places a memo in the transaction log
// Having a memo instruction with signals Trader-API usage is required
export function CreateTraderAPITipInstruction(
    senderAddress: PublicKey,
    tipAmount: number
): TransactionInstruction {
    const tipAddress = new PublicKey(TRADER_API_TIP_WALLET)

    return SystemProgram.transfer({
        fromPubkey: senderAddress,
        toPubkey: tipAddress,
        lamports: tipAmount,
    })
}

from numpy import uint64
from solders import pubkey as pk
from solders import instruction as inst
from solders import transaction as solders_tx
from solders.hash import Hash
from solders.keypair import Keypair
from solders.message import Message
from solders.pubkey import Pubkey
from solders.system_program import transfer, TransferParams
from solders.transaction import Transaction

# as of 2/12/2024, this is the bloxRoute tip wallet... check docs to see latest up to date tip wallet:
# https://docs.bloxroute.com/solana/trader-api-v2/front-running-protection-and-transaction-bundle
BloxrouteTipWallet = pk.Pubkey.from_string(
    "HWEoBxYs7ssKuudEjzjmpfJVX7Dvi7wescFsVx2L5yoY"
)


# create_trader_api_tip_instruction creates a tip instruction to send to bloxRoute. This is used if a user wants to send
# bundles or wants front running protection. If using bloXroute API, this instruction must be included in the last
# transaction sent to the API
def create_trader_api_tip_instruction(
    tip_amount: uint64,
    sender_address: Pubkey,
) -> inst.Instruction:
    instruction = transfer(
        TransferParams(
            from_pubkey=sender_address,
            to_pubkey=BloxrouteTipWallet,
            lamports=int(tip_amount),
        )
    )

    return instruction

If your language of choice is not included above, you can create an instruction referencing our tip-receiving addresses

3. Submission Endpoint Configuration:

Use the submit endpoint
Disable TLS to prevent encryption overhead
Use the following parameters for best performance:
- frontRunningProtection: false
- useStakedRPCs: true
- submitProtection: SP_LOW

# USE HTTP, NOT HTTPS, FOR THE BEST PERFORMANCE

curl -X 'POST' \
  'http://ny.solana.dex.blxrbdn.com/api/v2/submit' \
  -header "Authorization: $AUTH_HEADER" \
  -d '{
 "transaction": {"content": "AjF+Br2CUIENJqV1...BAAABCQ=="},
 "frontRunningProtection": false,
 "useStakedRPCs": true,
 "submitProtection": SP_LOW
}'

wscat -c ws://ny.solana.dex.blxrbdn.com/ws --execute '{"jsonrpc": "2.0", "id": 1, "method": "PostSubmit", "params": {
  "transaction": {"content": "AjF+Br2CU...AMBAAABCQ=="},
   "frontRunningProtection": false,
   "useStakedRPCs": true,
   "submitProtection": SP_LOW
}}'

# submitting raw transactions
await api.post_submit(
    post_submit_request=proto.PostSubmitRequest(
        transaction=proto.TransactionMessage(content=signed_tx),
        front_running_protection=False,
        use_staked_RPCs=True,
        submit_protection=SP_LOW
)

4. Send to the Right Regions

We recommend that users at minimum submit their transactions to both the global edge endpoint and your closest regional endpoint. Send to all regions in parallel to achieve optimal landing speeds.

Global endpoint (recommended, submit-only)

Our global edge endpoint will automatically route your transaction submissions to the closest Trader API transaction-handling instances. This reduces end-to-end-latency and improves landing performance. This is especially for users who are not co-located to common bare-metal provider regional hubs, such as residential or AWS users.

How to use

Primary target: Point your Trader API base URL/host to the Global endpoint
Parallelization: Also send the same transaction to your nearest regional endpoint(s) in parallel to maximize time-to-first-land.
No other config changes needed.
Global supports http, https, ws, wss, and gRPC

Region

Host

🌎 Global

global.solana.dex.blxrbdn.com

To ensure accurate routing, use a public DNS resolver that supports EDNS Client Subnet (ECS), such as Google DNS (8.8.8.8) or OpenDNS (208.67.222.222 / 208.67.220.220). Resolvers without ECS support (e.g., Cloudflare) may obscure the client ASN, leading to suboptimal routing.

Choose your closest region

For consistent best performance, pair the Global endpoint with the closest region to where your bot runs.

Find regions & hosts: See the full, always-updated list here
Pick the nearest region: Choose the region with the lowest RTT from your bot host. If you’re already ~2 ms from a Trader API region, the Global endpoint will typically select it—and parallel sends ensure you still catch the fastest path.
Practical tip: Measure latency from the same machine that runs your bot.

Latency check examples

# Quick TCP connect timing (good proxy for RTT)
curl -s -o /dev/null -w "connect:%{time_connect}\n" http://<region-host>

# ICMP ping (if enabled on your network)
ping -c 5 <region-host>

Parallel submit pattern (pseudo-code)

# Send once to Global, and in parallel to your nearest region(s)
targets = [
  "http://global.solana.dex.blxrbdn.com", # Global Endpoint HTTP version
  "http://<your-nearest-region-host>"  # from the Regions page above
]


# Fire in parallel; accept the first success
first_ok = race([submit_tx(t, tx_bytes) for t in targets])
return first_ok

# HTTPS – Global over HTTPS, region over HTTP
targets = [
  "https://global.solana.dex.blxrbdn.com", # Global HTTPS endpoint
  "https://<your-nearest-region-host>",     # from the Regions page above
]

first_ok = race([submit_tx(t, tx_bytes) for t in targets])
return first_ok

# WSS – Global over WSS, region over HTTP (REST)
targets = [
  "wss://global.solana.dex.blxrbdn.com/ws", # Global secure WebSocket endpoint
  "wss://<your-nearest-region-host>",     # from the Regions page above
]

first_ok = race([submit_tx(t, tx_bytes) for t in targets])
return first_ok

# WS – Global over WS, region over HTTP (REST)
targets = [
  "ws://global.solana.dex.blxrbdn.com/ws", # Global WebSocket endpoint
  "ws://<your-nearest-region-host>",     # from the Regions page above
]

first_ok = race([submit_tx(t, tx_bytes) for t in targets])
return first_ok

# gRPC – Global over gRPC, region over HTTP (REST)
targets = [
  "global.solana.dex.blxrbdn.com", # Global gRPC endpoint
  "<your-nearest-region-host>",         # from the Regions page above
]

first_ok = race([submit_tx(target, tx_bytes) for target in targets])
return first_ok

Guidance

Always include Global in your send set.
Add 1–2 closest regions in parallel for resilience and the best possible landing time.
Keep your region list current using the Regions page linked above.

5. Use Long-Lived connections with Keep-Alive

Avoid opening a new connection for every submission. Reusing warm HTTP, WebSocket, or gRPC connections reduces TCP/TLS handshake overhead and removes connection setup latency from the critical path.

For HTTP/HTTPS, use a client with connection pooling and keep-alive enabled so requests reuse existing connections. Trader API uses a server timeout of about 60 seconds, so clients should send keep-alive requests at a higher interval (we recommend every 30-seconds) to ensure their connections stay warm.
For WebSocket, maintain a persistent session instead of reconnecting for each submission. If your client may sit idle for extended periods, send periodic heartbeats or reconnect proactively before the next latency-sensitive send.
For gRPC, use a long-lived channel and enable client keepalive. Trader API explicitly supports keepalive without active streams and is configured with server keepalive parameters of roughly 20-seconds keep-alive time and 5s timeout.
For QUIC, keep a persistent QUIC session open and reuse it for multiple submissions instead of reconnecting for every transaction. Our QUIC client SDK is built around this model and supports submission over bidirectional streams, unidirectional streams, and datagrams. Reusing a warm QUIC session avoids repeated TLS and connection setup overhead on latency-sensitive sends.

As a general rule, your submission path should already be connected before the transaction is ready to send.

6. Rotate Tipping Wallets

Because Solana transactions lock writable accounts during execution, repeatedly tipping the same wallet can create unnecessary contention under heavy flow. Rotating across multiple bloXroute tip wallets helps distribute that load and can improve landing performance.

If your order flow is especially high frequency and public tip wallets may still become a point of contention, reach out to our support team to have private tipping wallets created and enabled for your account.

7. Choosing the Right Protocol

For most users, HTTP, WebSocket, or gRPC are sufficient and easier to integrate. Users submitting over HTTP or HTTPS should prefer the submit-plain-text endpoint to minimize unnecessary request overhead on those transports. For users optimizing for absolute minimum submission latency, QUIC is the preferred choice.

Instead of sending JSON or protobuf-framed API requests through a general-purpose interface, QUIC submission sends raw signed transaction bytes over a transport designed specifically for low-latency delivery, reducing serialization, framing, and request-processing overhead and gives performance-sensitive clients the leanest submission path supported by Trader API.

Refer to our QUIC SDK for learning how to submit transactions over QUIC.

Commonly Used Submission Modes.

This table summarizes different submission modes by different parameter configurations.

Mode - Nickname

Parameter config

Minimum Tip

Description

Fastest mode

frontRunningProtection: False, useStakedRPCs: True, submitProtection: SP_LOW

0.001 SOL

Max speed by leveraging staked RPC connections.
Ideal for time-sensitive transactions.

MEV-protected mode

frontRunningProtection: True, submitProtection: SP_MEDIUM

0.001 SOL

Protects against MEV attacks based on the bloXroute Malicious Leader detection system.
Slightly slower if consecutive flagged malicious validators are present.
submitProtection: SP_HIGH can be used to further the MEV protection level.

Transaction Revert Protection

frontRunningProtection: True, reverProtection: True

0.001 SOL

Transactions will only be sent to the Jito block engine and the Paladin leader.
Failed transactions won't land on the chain.
This method is the slowest method as no public RPC propagation channels will be used. If consecutive non-Jito nor non-Paladin validators are present, it could be even slower.

Previousroute-swap NextSupport

Last updated 2 months ago