swqos.com documentation

swqos.com is a prepaid Solana transaction relay. You submit an already-signed transaction over HTTPS or QUIC, and we forward those exact bytes to the leader over stake-weighted QoS connections we hold open. Each accepted submission costs a flat 0.0002 SOL from a prepaid SOL balance.

What it does#

You build and sign a Solana transaction with your own keypair, exactly as you do now. Instead of handing it to a general purpose RPC, you hand the serialized bytes to swqos.com. We validate the envelope, charge your prepaid balance, and write those unchanged bytes to a stake-weighted QoS connection that is already open and warm.

There is no blockhash fetch, no simulation, no signature status check and no tip instruction anywhere in that path. We keep 4 upstream connections warm at all times, so your transaction never waits on a handshake. Measured relay overhead is 6.29 ms at the median and 32.3 ms at the 99th percentile, measured on production QUIC traffic.

What it guarantees, and what it does not#

This is the most important paragraph in these docs, so it comes early rather than buried in a billing page.

What an accepted receipt does tell you is precise and useful: your bytes were valid, your account was charged, and an upstream connection acknowledged the stream. If any of that had failed you would have an error instead, and in most cases no charge.

The shape of an integration#

Four steps, and only the third one involves us.

1. Build and sign the transaction with the library you already use.
2. Serialize it and base64 encode it, or write the raw bytes to a QUIC stream.
3. Submit it to https://send.swqos.com/v1/transactions or to send.swqos.com:11000.
4. Read the receipt, and confirm landing yourself if your use case needs certainty.

The quickstart walks through all four in TypeScript, Python, Rust and Go, with complete programs rather than fragments.

Checking we are up#

The health route is public and needs no credential. It reports each component independently, so a degraded billing ledger is distinguishable from a degraded forwarding path.

1curl -sS https://send.swqos.com/v1/health
2 
3# {"ok":true,"status":"healthy","billing_ledger":"healthy",
4#  "audit_ledger":"healthy","upstream":"healthy"}

It returns HTTP 503 if any required component is unhealthy. Poll it every fifteen seconds with a three second timeout and alert after three consecutive failures.

Everything in these docs#