Response Compression

Solana Vibe Station supports zstd response compression on all JSON-RPC endpoints. By adding a single request header, you can shrink RPC responses by up to 80–90% — cutting your bandwidth bill, speeding up large reads, and reducing time-to-first-byte on slow or metered connections.

Compression is opt-in and fully transparent: you ask for it with a header, and any HTTP client that understands zstd decodes it automatically. Responses are byte-for-byte identical once decompressed — nothing about your application logic changes.

TL;DR — Send Accept-Encoding: zstd with your requests. That's it. If your HTTP client supports zstd (most modern ones do), you get smaller responses and lower bandwidth usage for free.

---

Why use it

RPC responses are JSON, and JSON compresses extremely well — it's highly repetitive (field names, base58/base64 strings, structural punctuation). zstd (Zstandard) is a modern compression algorithm from Meta that gives ratios comparable to or better than gzip while decompressing much faster, so the client-side cost is negligible.

The payoff is largest on exactly the calls that hurt the most today: big account scans and full blocks.

Method	Uncompressed	With zstd	Savings
getClusterNodes	~1.67 MB	~0.30 MB	~82%
getBlock (full transactions)	~4.4 MB	~0.65 MB	~85%
getProgramAccounts (large sets)	multi-MB	typically 80–90% smaller	~80–90%

Figures are representative; your exact ratio depends on the response contents.

What this means for you

• Lower bandwidth costs. If you or your infrastructure pay for egress/ingress, compressed responses can cut transfer volume on read-heavy workloads by 4–10×.

• Faster large responses. Less data on the wire means quicker downloads, especially over mobile, VPN, or long-haul links.

• No change to your data. You receive the same JSON you always have — only the bytes in transit are compressed.

---

How to use it

Add the Accept-Encoding header to your request:

Accept-Encoding: zstd

When the proxy sees this header, it compresses eligible responses and returns:

Content-Encoding: zstd

Your HTTP client detects Content-Encoding: zstd and decompresses the body before handing it to your code. If your client does not send the header (or doesn't support zstd), you get an ordinary uncompressed response — so it's always safe to enable.

curl

Modern curl (7.72.0+, built with zstd) decodes it for you automatically:

curl --zstd https://<your-endpoint>.rpc.solanavibestation.com/?api_key=<YOUR_API_KEY> \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getClusterNodes"}'

--zstd both sends Accept-Encoding: zstd and transparently decompresses the response.

If your curl is older or wasn't built with zstd, request the raw compressed bytes and decode them with the zstd CLI:

curl -s https://<your-endpoint>.rpc.solanavibestation.com/?api_key=<YOUR_API_KEY> \
  -X POST \
  -H "Content-Type: application/json" \
  -H "Accept-Encoding: zstd" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getClusterNodes"}' | zstd -d

JavaScript / TypeScript

Browsers negotiate encodings automatically — fetch in a modern browser will request and decode zstd for you with no code changes.

In Node.js, zstd decoding in the built-in fetch requires Node 22.15+ / 23+. On those versions, decoding is automatic:

const res = await fetch(
  "https://<your-endpoint>.rpc.solanavibestation.com/?api_key=<YOUR_API_KEY>",
  {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Accept-Encoding": "zstd",
    },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method: "getClusterNodes" }),
  }
);
const data = await res.json(); // already decompressed

The official @solana/web3.js Connection uses your runtime's HTTP stack. If that stack supports zstd, you benefit automatically; if not, requests fall back to uncompressed responses transparently.

Python

requests doesn't decode zstd out of the box. Install the zstandard package and decode manually, or use a client that negotiates it for you (e.g. httpx with zstd support):

import requests, zstandard

r = requests.post(
    "https://<your-endpoint>.rpc.solanavibestation.com/?api_key=<YOUR_API_KEY>",
    headers={"Content-Type": "application/json", "Accept-Encoding": "zstd"},
    json={"jsonrpc": "2.0", "id": 1, "method": "getClusterNodes"},
)

if r.headers.get("Content-Encoding") == "zstd":
    body = zstandard.ZstdDecompressor().decompress(r.content)
else:
    body = r.content

import json
data = json.loads(body)

Rust

reqwest decodes zstd automatically when built with the zstd feature:

reqwest = { version = "0.12", features = ["json", "zstd"] }

With the feature enabled, reqwest sends Accept-Encoding: zstd and decompresses responses for you — no manual handling required.

---

What gets compressed

Compression applies to JSON-RPC response bodies (Content-Type: application/json). A few rules keep it efficient:

• Only responses above ~256 bytes are compressed. Tiny responses (e.g. getHealth, a single getSlot) are sent uncompressed, because compressing a few bytes adds overhead without saving anything. This is expected — don't be surprised to see no Content-Encoding header on small replies.

• Already-compressed responses are passed through, not re-compressed. The /historical endpoint already serves zstd from its backend; if you request zstd there, you get that compressed stream directly, and if you don't, it's decompressed for you. Either way you get correct data.

• Compression is applied per-request. Sending the header on one request and not another is fine; each response is handled independently.

Availability

zstd response compression is enabled on all standard JSON-RPC endpoints across tiers and regions, including the /historical path. It does not apply to gRPC/streaming endpoints, which use their own framing.

---

Frequently asked questions

Do I have to change my requests or parse responses differently? No. The only change is one request header. Decompression is handled by your HTTP client, and the JSON you get back is identical.

Is there a downside or extra cost? No. Compression is free to use, decompression is very fast with minimal overhead, and if your client can't handle zstd you simply get an uncompressed response. There is no separate charge and it does not affect your rate limits.

Does it count against my rate limit differently? No. Rate limiting is based on the requests and methods you call, not on response size or encoding. Compression changes only the bytes on the wire.

Why did I get an uncompressed response even though I sent the header? Two common reasons: the response was below the ~256-byte minimum (small responses are intentionally not compressed), or your HTTP client stripped/renegotiated the Accept-Encoding header. Check for the Content-Encoding: zstd response header to confirm what you received.

Can I use gzip instead? These endpoints are optimized for zstd, which outperforms gzip on JSON-RPC payloads in both ratio and speed. We recommend Accept-Encoding: zstd.

My client doesn't support zstd — what should I do? You can keep making uncompressed requests as you do today (everything continues to work), decode manually using a zstd library (see the examples above), or upgrade to a client/runtime version with built-in zstd support.

---

Recommendation

If you make read-heavy calls — getProgramAccounts, getBlock, getClusterNodes, batched account lookups, historical queries — enable zstd. For most workloads it's a one-line change that cuts response bandwidth several-fold with no downside. Send Accept-Encoding: zstd, confirm you see Content-Encoding: zstd on large responses, and enjoy the savings.