Transaction Submission API

Direct HTTP endpoint for submitting Solana transactions through Cascade without JSON-RPC overhead.

Triton's Cascade-enabled Solana endpoints support a direct HTTP transaction submission path that bypasses the JSON-RPC layer entirely:

POST /sendtx

This endpoint is designed for latency-sensitive workloads where every millisecond of overhead matters. It accepts a plain transaction payload over HTTP and eliminates several sources of latency present in a standard sendTransaction JSON-RPC call.

Why use /sendtx instead of sendTransaction?

The standard Solana sendTransaction RPC method wraps your transaction in a JSON-RPC envelope, which adds overhead at every stage of the request. The /sendtx endpoint removes that overhead.

  • No JSON parsing. The server receives your transaction bytes directly, skipping JSON deserialization.

  • No CORS preflight. When using Content-Type: application/octet-stream or text/plain, browsers skip the preflight OPTIONS request. That saves a full round-trip.

  • Smaller payloads. Without the JSON-RPC wrapper (jsonrpc, id, method, params), the request body is smaller on the wire.

  • Simpler client code. You don't need a Solana JSON-RPC client library. A single HTTP POST is all it takes.

This makes /sendtx a good fit for browser-based applications that are sensitive to preflight latency and high-frequency backends that send large volumes of transactions.

If you need a transaction signature returned in the response, use the response=signature query parameter. Otherwise, track signatures client-side before submitting. The signature is deterministic and can be derived from the signed transaction before it is sent.

If you prefer the standard Solana RPC interface or need full sendTransaction options like skipPreflight, you can continue using sendTransaction as normal. See our Transaction sending advice for best practices.

Request format

Method: POST Path: /sendtx

The request body should contain your serialized transaction. You can submit it in one of two ways:

  • Raw bytes. Set Content-Type: application/octet-stream and send the transaction as a binary payload.

  • Encoded string. Set Content-Type: text/plain and send the transaction as a text body (base58 or base64). Use the encoding query parameter to indicate the format.

Query parameters

Parameter
Values
Required
Description

encoding

base58, base64

No

Encoding format when sending the transaction as text. Defaults to base58.

response

signature

Recommended

When set, the response body contains the transaction signature on success.

max_retries

integer

No

Override the default retry count for this transaction.

Optional headers

Header
Description

solana-forwardingpolicies

Comma-separated Yellowstone Shield policy addresses to apply when forwarding.

Examples

Raw bytes

Base64-encoded transaction

Base64 with a Yellowstone Shield forwarding policy

Response

On success:

  • HTTP 200 OK

  • If response=signature was set, the body contains the transaction signature as plain text.

  • If response=signature was not set, the body is empty. Derive the signature client-side from your signed transaction before submitting.

On error:

  • HTTP 4xx or 5xx

  • The response body contains error details describing what went wrong.

Notes

  • /sendtx is for transaction submission only. It does not support simulation or other RPC methods.

  • For best results, follow our Transaction sending advice for client-side retries, compute budgets, priority fees, and preflight handling.

  • If you are using Yellowstone Shield policies, see the Shield documentation for configuration details.

Last updated

Was this helpful?