Solana transaction sending: a direct lane and parallel send paths

Last updated: November 1, 2026

Which send should you use?

The FRA direct lane

https://fra.triport.io/sol takes the same API key and the same JSON-RPC body as https://triport.io/sol, without Cloudflare on the path. The benefit depends on where your server is: the shorter the path to Frankfurt, the more of the gap you keep. A client far from Frankfurt adds its own network distance, and may do no better than the regular endpoint. Measure it from your own server. Our dated measurement, with its method, is in the sendTransaction reference.

There is no failover on this lane. Build the fallback into your client: on a network error or a timeout, send the same signed bytes to https://triport.io/sol. Solana processes a signature at most once, so a duplicate send is safe.

for (const url of ["https://fra.triport.io/sol", "https://triport.io/sol"]) {
  try {
    const res = await fetch(url, {
      method: "POST",
      signal: AbortSignal.timeout(2000),
      headers: { "x-token": process.env.TRIPORT_API_KEY, "Content-Type": "application/json" },
      body: JSON.stringify({
        jsonrpc: "2.0", id: 1, method: "sendTransaction",
        params: [signedTxBase64, { encoding: "base64", preflightCommitment: "confirmed", maxRetries: 0 }],
      }),
    });
    const body = await res.json();
    if (body.error) throw Object.assign(new Error(body.error.message), { final: true });
    return body.result; // accepted, not landed: confirm by signature
  } catch (e) {
    if (e.final) throw e;
  }
}

Parallel paths

On the Frankfurt edge, one sendTransaction request can go down up to three paths at once, and you get the first upstream answer that returns a signature. The tip in your transaction decides which paths are used.

Paths are chosen from the transaction's static account keys, so a tip account loaded through an address lookup table is not detected. Requests inside a JSON-RPC batch use only the Triport RPC path, and so does a request served by a fallback region. The tip account lists are in the reference. For how much to pay, read which payment does what.

See what happened to your request

Every send through the edge says what it did, so you can check instead of guessing:

• X-Triport-Send-Legs: the paths your transaction went down, for example cohort,sender. If you tipped and the path is missing, look at the tip account.
• X-Triport-Send-Winner: the path whose answer you received, or none.
• Server-Timing: time from our edge receiving the request to the winning answer, measured on our server.

What this does not do

• It cannot promise landing. Nobody can. An accepted transaction can be dropped or expire, so diagnose by signature.
• It does not rebroadcast. After a path has accepted the transaction, retrying is your client's job.
• It does not fix fees. Priority fee and compute limit are set when you build the transaction.
• It is not for reads or streams. Keep those on triport.io.

Plans

Requests per second on sol_send_tx, from tier-matrix.yaml, the same source as RPC pricing. This budget is separate from your read budget.

A flat monthly price, no credits or overage. Tips are yours to set, and go to the tip account you choose.

When this is the wrong choice

If your bot needs a colocated send path in a region far from Frankfurt, the direct lane is the wrong tool, and a regional sender service may suit you better: compare send services, including where they run and what they charge. No provider listed there commits to landing either, so plan for retries wherever you send from.

Put it together

The send guide walks through the whole loop: blockhash, compute limit, priority fee, sending, rebroadcast and confirmation. When a send returns an error, start with transaction simulation failed or blockhash not found. To act on transactions before they execute, pair sending with the Shred stream.