Edge Boost is in private beta. The API may change without notice, and there’s no SLA yet. Share feedback with your Goldsky contact.
Copy prompt
Open in Claude
Open in ChatGPT
Open in Perplexity
How it works
Three things are true of every request:- Nothing is interpreted. A forwarded call reaches your endpoint with its method and params exactly as you sent them, carrying your own headers (header forwarding), and its result comes back to you untouched.
- A miss costs you a little latency, never correctness. If our lookup is slow, errors, or doesn’t have the data, we fall back to your endpoint.
- You pay only for hits. A forwarded request is free passthrough.
Quickstart
Edge Boost gives you one address per chain:{chain} is a chain name or a chain ID — /boost/ethereum and /boost/1 are the same endpoint, and names are case-insensitive.
Your own endpoint is not part of the URL. You configure it once against your API key, and Edge Boost forwards to it whenever it can’t answer from cache.
1
Configure your endpoint
In the dashboard, pick the chain you want to boost and paste your provider’s RPC URL. Add any custom headers your provider needs.Then take an API key from the same project. Boost configuration belongs to the key, so an API key is a Boost endpoint: the key in the URL decides which upstream we forward to.
2
Make a request that hits the cache
Drop in your key, pick a chain, and copy the generated command:
The response headers tell you who answered:
Prefer a static example?
Prefer a static example?
The first call for a block we haven’t served recently may still come back
x-cache: MISS while the reader warms that range from storage — run it
twice. Repeats answer from cache in single-digit milliseconds.3
Compare against a miss
Ask for something we don’t index — say, a method we don’t serve — and the same request forwards to your endpoint:
Your endpoint URL usually embeds a provider API key. It lives in your endpoint configuration rather than riding along on every request, and Edge Boost never writes it to logs, errors, or metrics. Credentials given as URL userinfo (
https://user:pass@…) are converted to an Authorization: Basic header before the request leaves us. The URL is still stored by Goldsky, so treat the beta accordingly.Configuring your endpoint
Everything about where a request forwards to lives in the dashboard, on the API key — not in the request. Per chain you configure:- A provider URL, plus any custom headers the provider needs for auth.
- Optional standby upstreams for the same chain. Only one is active at a time; you switch with an explicit action, so failover is a configuration change you make, not something we do behind your back.
- An optional forward timeout, per chain, for how long we wait on your endpoint before giving up.
What gets served from cache
These read methods can be answered from Goldsky’s data:eth_chainId and net_version are answered directly by Edge Boost without touching either backend.
Every other method forwards to your endpoint. Writes, traces, state reads like eth_call and eth_getBalance — all passthrough, all free. Eligible is not the same as guaranteed: a method in this table still forwards if we don’t have that specific data yet.
Block tags always forward
A request for a tagged block —latest, pending, safe, finalized, or earliest — is always forwarded to your endpoint, never served from cache.
This is deliberate. We resolve a tag against our own view of the chain, and our view of the head can trail yours by a block or two. Serving latest from cache would occasionally hand you a stale or soon-reorged block. Your endpoint is the authority on where the head is, so tags go there. Ask for a concrete height and you get the cache.
The same rule applies to eth_getLogs with a tag as a range bound.
Batch requests
Send a JSON-RPC batch and Edge Boost serves it per item: the calls we hold are answered from cache, the rest are forwarded to your endpoint in a single onward batch. You are billed only for the items we served. Nothing to enable — post an array to the same address. For a batch,x-edge-billable carries the count of items we served, and x-cache is HIT only when every item was one of ours. A batch where 44 of 45 items came from cache still reports MISS, so read the billable count rather than x-cache alone.
Two things to know:
- Give every item a unique
id. JSON-RPC doesn’t guarantee the order of a batch response, so match results byidrather than by position. - Arrays over 100 items forward whole. They reach your endpoint verbatim as one free passthrough call, with no cache lookups. Split larger arrays into 100-item batches to keep the cache hits.
Supported networks
Cache lookups are available for:
Use either the name or the chain ID in the path —
/boost/ethereum and /boost/1 are equivalent.
Response headers
Every response carries these:x-cache is the one to graph. It’s the same header CDNs use, so most tooling already understands it.
Header forwarding
Edge Boost is a proxy in the middle of a chain you built: your client, us, your provider. Headers pass through in both directions. We touch only the ones that are ours to manage.What reaches your provider
On a forwarded request (x-cache: MISS), your provider receives the headers your client sent, plus any custom headers you configured on the endpoint. Your configured headers are applied last, so they win over anything a caller sends under the same name.
We keep back only the headers we manage:
Everything else passes through unchanged — trace context (
traceparent, tracestate, b3, baggage), User-Agent, and any custom x-* header your provider expects.
The caller’s IP
X-Forwarded-For reaches your provider, relayed as a whole chain, unmodified, on every forwarded request.
Read the last entry. That is the address our load balancer observed:
X-Forwarded-For you receive.
X-Real-IP, Forwarded, CF-Connecting-IP, and True-Client-IP are relayed too if your client sends them. We never set them ourselves.
This was briefly a per-endpoint toggle, and it defaulted to off. It is now the default for every endpoint: your provider is the party that rate-limits you per IP, applies your per-IP allowlists, and draws your per-IP analytics. None of that works if the only address it ever sees is ours.
If you need us to withhold the caller’s address from your provider instead, contact us — it is a per-endpoint setting we can turn off for you.
Sending auth headers to your provider
Some providers want a bearer token or an API-key header rather than a key in the URL. That works, and it works because your Goldsky key goes in the query string:Authorization and X-API-Key are forwarded to your provider untouched.
For a credential that never changes, prefer the endpoint’s custom headers in the dashboard. They are stored once, applied to every forwarded request, and your callers never have to hold them.
What comes back to you
Your provider’s response headers ride back to your client:Cache-Control, Retry-After, ETag, and any custom x-* it sets.
These are dropped:
CORS
Browser access is controlled by the endpoint’s Allowed domains list in the dashboard, not by your provider. The edge answers the browser’s preflight itself and reflects an allowed origin. Credentialed requests (cookies, HTTP auth) are not allowed, so your provider’sAccess-Control-* headers — which describe their origin, not ours — are dropped rather than merged.
Every response header we send is readable from browser JavaScript (Access-Control-Expose-Headers: *), so x-cache is available to fetch and XHR.
Where our requests come from
We forward from AWS Fargate tasks in three regions:us-east-1, us-west-2, and eu-central-1. Those tasks take public addresses from each region’s AWS pool and get new ones whenever a task is replaced — on a deploy, a scale-out, or a restart. There is no fixed list of egress IPs to allowlist.
So authenticate us rather than allowlisting us. Keep your provider’s credential in the endpoint URL, or configure it as a custom header on the endpoint; either reaches your provider on every forwarded request, from whichever task serves it.
If your provider supports only IP allowlisting, talk to us before you build on it. A stable egress address is infrastructure we would have to add, not a setting we can turn on.
Billing
Boost is free to use. Cached requests and forwarded requests both cost nothing from Goldsky — forwarded requests go straight to your endpoint, which you already pay your provider for. Usage is still measured, and both appear on your invoice as zero-dollar line items: cache hits (x-cache: HIT, equivalently x-edge-billable: 1) and forwarded requests, separately. That keeps the economics easy to reason about — the hits line is exactly the calls we saved you from paying your provider for.
Limits
- Every request needs a
key. Get one from the dashboard — it carries your Boost configuration and your budget. Keyless requests are answered with an x402 payment challenge rather than served. - The chain in the URL must be one your key is configured for. A chain with no active upstream comes back as a JSON-RPC error.
- Your configured endpoint must be reachable over
httpsfrom the public internet. Private, loopback, and link-local addresses are rejected.