boost

Goldsky Boost

Boost is a CDN in front of the RPC endpoint the user already pays for. Every request is checked against Goldsky's indexed data first: if Boost has the answer it serves it, and the provider never sees the call (so never bills for it). If it doesn't, the request forwards to the user's endpoint unchanged and the response comes back verbatim.

Boost is free. CDN hits and forwarded requests both cost nothing from Goldsky. That shapes how to talk about it: there is no upsell here, and the only number that matters to the user is how much of their existing provider bill disappears.

The mental model that prevents most mistakes

Three facts explain nearly every question users have:

1. An API key is a Boost endpoint. Configuration lives on the key, not in the request. The key in the URL is how Boost knows which upstream to forward to. The user's own provider URL never travels with a request.
2. A project has exactly one Boost. There are no named Boost endpoints to create or list. If you find yourself reaching for goldsky boost create or goldsky boost list, those commands do not exist — see Command surface.
3. Boost never guesses about the head of the chain. Block tags always forward. This is the single most common "why didn't it cache?" question and the answer is deliberate design, not a bug.

Endpoint format

https://edge.goldsky.com/boost/{chain}?key={GOLDSKY_API_KEY}

{chain} is a chain name or a chain ID, case-insensitive — /boost/ethereum and /boost/1 are the same endpoint.

?key= is required on every request, and the two ways it can fail look different. Both verified against production:

Request	Response	Means
no ?key=, ?key= empty, or ?KEY= (the name is case-sensitive)	401, empty body	the edge never resolved a key at all
?key=<something unrecognised>	404 + {"error":{"code":-32000,"message":"no Boost configuration for this key"}}	a key was read, but it carries no Boost config