# swqos.com — full reference > swqos.com is a prepaid Solana transaction relay. It forwards already-signed transactions to the current leader over stake-weighted QoS connections that are held open and kept warm. There is no RPC hop, no simulation, no blockhash fetch and no tip instruction in the forwarding path. Site: https://swqos.com ## Endpoints HTTPS https://send.swqos.com QUIC send.swqos.com:11000 (ALPN ultrasend/1; solana-tpu compatibility mode also accepted) Network Solana mainnet-beta Public routes: /healthz, /v1/health, /v1/pricing, /v1/account, /v1/transactions ## Pricing 0.0002 SOL per accepted submission, deducted from a prepaid native SOL balance. You are charged once a submission is accepted and forwarded. Refused submissions are free. Balances are prepaid in native SOL. There is no card, no invoice and no subscription. Billing boundary, exactly as implemented: Accepted and forwarded upstream 0.0002 SOL Duplicate signature within 90s free Invalid transaction envelope free Unknown or invalid API key free Account disabled free Insufficient balance free Forwarding failed upstream charged, then reversed Accepted but never lands on chain 0.0002 SOL ## The distinction that matters most A receipt means we forwarded your bytes and the upstream acknowledged the stream. Landing on chain is the network's decision, not ours. An accepted receipt confirms three things: your bytes were a valid transaction envelope, your account was charged, and an upstream connection acknowledged the stream. It does not confirm the transaction was included in a block. Confirm landing separately with getSignatureStatuses or getTransaction, using the signature from the receipt. The per-send price is a relay fee, not a Solana validator tip. swqos.com never attaches tip instructions and never modifies priority fees. ## Authentication Over HTTPS: Authorization: Bearer , where the key begins usq_live_ Over QUIC: the client derives an Ed25519 keypair from the same key and presents a self-signed certificate carrying it during the handshake. No header. ## Submitting a transaction POST https://send.swqos.com/v1/transactions Content-Type: application/json Authorization: Bearer usq_live_... {"transaction":""} Response: {"signature","accepted","duplicate","charged_lamports","balance_remaining_lamports"} ## Limits Transaction size 1232 bytes serialized HTTP body 8 KiB QUIC response 4 KiB Deduplication window 90 seconds, per account per signature Measured overhead 6.29 ms p50, 20.92 ms p90, 32.3 ms p99 on production QUIC traffic ## Errors 400 INVALID_BASE64 cause: The transaction field is not valid base64. fix: Base64-encode the serialized transaction, not the JSON or a hex string. 400 INVALID_TRANSACTION cause: The serialized envelope is malformed or out of bounds. fix: Send a fully signed legacy or versioned transaction under 1232 bytes. 400 INVALID_REQUEST cause: A request field is missing or malformed. fix: Check the JSON body shape against the reference. 401 UNAUTHORIZED cause: No Bearer credential was supplied. fix: Send an Authorization header of the form 'Bearer '. 401 INVALID_API_KEY cause: The key could not be decoded. fix: Check the key is intact and begins with usq_live_. Keys are secrets, so never log them. 402 INSUFFICIENT_BALANCE cause: The account has no prepaid credit left. fix: Deposit SOL from the dashboard. Credit appears once the deposit finalizes. 403 ACCOUNT_DISABLED cause: The account exists but is switched off. fix: Contact support. This is usually a billing or abuse review. 409 SUBMISSION_IN_PROGRESS cause: The same signature is already in flight. fix: Wait for the first submission to return rather than retrying immediately. 503 BILLING_UNAVAILABLE cause: Billing persistence is unhealthy. fix: Retry with backoff. Nothing was charged. 503 AUDIT_UNAVAILABLE cause: Audit persistence is unhealthy. fix: Retry with backoff. Nothing was charged. 503 UPSTREAM_UNAVAILABLE cause: We could not forward the transaction. fix: Retry. Any charge for this submission is reversed automatically. ## Frequently asked questions Q: What is swqos.com? A: swqos.com is a prepaid Solana transaction relay that forwards already-signed transactions to the leader over stake-weighted QoS connections. You send the serialized bytes over HTTPS or QUIC, and the relay writes them to a connection it already holds open. It costs 0.0002 SOL per accepted send with no subscription and no minimum. Q: Does swqos.com change my transaction? A: swqos.com forwards the exact bytes you submit and never modifies them. It does not add a tip instruction, adjust a priority fee, re-sign, or reorder anything. The signature in your receipt is derived from the bytes you sent, so it will always match the transaction you built. Q: What does an accepted receipt actually mean? A: An accepted receipt means swqos.com forwarded your bytes and the upstream connection acknowledged the stream. A receipt means we forwarded your bytes and the upstream acknowledged the stream. Landing on chain is the network's decision, not ours. Use getSignatureStatuses or getTransaction with the signature from your receipt when you need to know it landed. Q: How much does it cost to send a transaction? A: Each accepted submission costs 0.0002 SOL, deducted from a prepaid SOL balance. You are charged once a submission is accepted and forwarded. Refused submissions are free. A duplicate signature inside the 90 second dedupe window is also free, and if forwarding fails the charge is reversed automatically. Q: Do I need to hold a token or sign a contract? A: No. Balances are prepaid in native SOL. There is no card, no invoice and no subscription. You deposit native SOL from any wallet, the balance is credited once the deposit finalizes on chain, and you spend it down one send at a time. Stop whenever you like; there is nothing to cancel. Q: Should I use QUIC or HTTPS? A: Use QUIC if you care about latency, and HTTPS if you care about simplicity. QUIC at send.swqos.com:11000 lets you hold one connection open and open a single stream per submission, which removes the handshake from every send. HTTPS at https://send.swqos.com is a plain JSON POST and is easier to drop into an existing service. Q: Who holds my keys? A: You do. swqos.com never sees a private key, because you sign locally and submit the already-signed bytes. Your API key is a separate credential that identifies your billing account, and it cannot move funds or sign anything on your behalf. Q: What happens if my balance runs out? A: Submissions are refused with an INSUFFICIENT_BALANCE error and you are not charged for them. Nothing is queued and nothing is silently dropped, so your client sees the failure immediately and can decide what to do. Top up from the dashboard and sending resumes as soon as the deposit finalizes. ## Documentation Overview https://swqos.com/docs What swqos.com is, what it guarantees, and what it does not. Quickstart https://swqos.com/docs/quickstart Key, fund, send, verify. Ten minutes, four languages. Authentication https://swqos.com/docs/authentication How API keys work over HTTPS and QUIC, and how to look after them. Send over HTTPS https://swqos.com/docs/send-http POST /v1/transactions, every field of the request and the receipt. Send over QUIC https://swqos.com/docs/send-quic The low latency path: one connection, one stream per submission. Limits and behaviour https://swqos.com/docs/limits Payload size, deduplication, timeouts and retry guidance. Billing https://swqos.com/docs/billing The exact charge boundary, refunds, and what accepted means. Deposits https://swqos.com/docs/deposits Funding a balance with SOL, and how a deposit becomes credit. Errors https://swqos.com/docs/errors Every error code, what caused it, and how to fix it. FAQ https://swqos.com/docs/faq The questions that come up most, answered at length. ## Engineering articles Why your Solana transactions are not landing https://swqos.com/blog/why-solana-transactions-dont-land Published 2026-08-27. 18 min read. Topic: Fundamentals. A transaction that never lands failed at one of six specific points: blockhash expiry, an underpriced fee, compute budget, RPC forwarding, leader connection limits, or account contention. This walks through each one, how to tell them apart from the outside, and what actually fixes each. Covers: solana transaction not landing; solana transaction dropped; why solana transaction failed; solana transaction never confirmed Stake-weighted QoS, explained properly https://swqos.com/blog/stake-weighted-qos-explained Published 2026-08-27. 16 min read. Topic: Fundamentals. Stake-weighted QoS is how a Solana leader decides whose packets to accept when more arrive than it can process. Connection capacity is allocated in proportion to stake, so a transaction sent through a staked connection competes in a much smaller queue than one sent through a public RPC. Covers: stake weighted qos; swqos solana; solana staked connection; solana qos explained; what is swqos Priority fees on Solana: a practical guide https://swqos.com/blog/solana-priority-fees-guide Published 2026-08-27. 20 min read. Topic: Fundamentals. A Solana priority fee is a per-compute-unit bid that decides where your transaction sits in the leader's scheduling queue. This covers how the fee is actually computed, how to price it from live network data instead of guessing, and the mistakes that make a fee do nothing. Covers: solana priority fees; setComputeUnitPrice; getRecentPrioritizationFees; solana priority fee calculation The blockhash lifecycle, and why it killed your transaction https://swqos.com/blog/blockhash-lifecycle Published 2026-08-27. 15 min read. Topic: Engineering. A Solana blockhash is valid for 150 slots, roughly 60 to 90 seconds, and a transaction referencing an older one is rejected outright. This explains the full lifecycle, why the window is shorter in practice than the arithmetic suggests, and how to structure a sender so it never fights the clock. Covers: solana blockhash expired; blockhash not found; BlockhashNotFound; solana recent blockhash Compute units: the limit that silently fails your transaction https://swqos.com/blog/compute-units-explained Published 2026-08-27. 17 min read. Topic: Engineering. Every Solana transaction gets a compute budget, and exceeding it fails the transaction on chain after you have already paid for it. This covers how compute units are metered, how to measure what your instruction actually consumes, and why requesting the maximum is the wrong default. Covers: solana compute units; setComputeUnitLimit; solana compute budget; exceeded CUs meter Writing a Solana QUIC TPU client from scratch https://swqos.com/blog/solana-quic-tpu-client Published 2026-08-27. 24 min read. Topic: Engineering. A TPU client authenticates with a self-signed certificate carrying an Ed25519 keypair, negotiates the solana-tpu ALPN, and writes one serialized transaction per unidirectional stream. This builds one in Rust, explains every step of the handshake, and covers the connection management that decides whether it is fast. Covers: solana quic client; solana tpu client; solana tpu quic; rust solana quic Landing transactions on pump.fun https://swqos.com/blog/landing-pumpfun-transactions Published 2026-08-27. 21 min read. Topic: Programs. pump.fun buys compete against every other bot watching the same mint, and the winner is usually decided by who reaches the leader first rather than who paid most. This covers bonding curve mechanics, the compute profile of a buy, slippage under contention, and how to structure a sniper that lands. Covers: pump.fun sniper; pump fun bot; land pump.fun transaction; pumpfun bonding curve buy Landing Raydium and Jupiter swaps https://swqos.com/blog/landing-raydium-jupiter-swaps Published 2026-08-27. 19 min read. Topic: Programs. A swap that arrives late does not just miss, it can execute at a price you would not have accepted. This covers the compute profile of Raydium AMM and CLMM swaps, how Jupiter routing changes the risk, how to set slippage that protects you without causing needless failures, and why address lookup tables matter more than people think. Covers: raydium swap transaction; jupiter swap landing; solana swap slippage; raydium clmm compute units Jito bundles versus staked connections https://swqos.com/blog/jito-bundles-vs-staked-connections Published 2026-08-27. 18 min read. Topic: Operations. Jito bundles buy atomic, ordered execution and a shot at the top of a block. Staked connections buy fast, reliable delivery to the leader. They solve different problems, they are not mutually exclusive, and picking the wrong one costs you either money or fills. Covers: jito bundle vs; jito tip vs priority fee; solana bundle atomic; jito bundles explained Measuring your real landing rate https://swqos.com/blog/measuring-landing-rate Published 2026-08-27. 20 min read. Topic: Operations. Landing rate is the share of submitted transactions that reach a finalized block, and almost nobody measures it correctly. This covers how to instrument a sender end to end, which RPC calls give a truthful answer, how to separate delivery failures from on-chain failures, and how to turn the result into a number you can act on. Covers: solana landing rate; measure solana transaction success; getSignatureStatuses; solana transaction monitoring ## Feeds RSS https://swqos.com/blog/rss.xml Sitemap https://swqos.com/sitemap.xml Brief https://swqos.com/llms.txt