Skip to main content

​
Endpoint format

{chain} accepts a path name or chain ID and is case-insensitive. For example, /boost/ethereum and /boost/1 are equivalent. The key identifies your project’s Boost. The chain must be enabled and have an active upstream in that project’s configuration.

​
Request options

Write the value as exactly true; any other value leaves the option off. Unrecognized query parameters are ignored, so your own tracking parameters pass through harmlessly.

​
gRPC endpoint

Boost serves the BDS bds.evm.RPCQueryService natively, on the same host as JSON-RPC. Point a BDS client here to skip JSON encoding entirely.
The proto fixes the path, so addressing rides gRPC metadata: Both protocols share one routing path, one set of eligible methods, and one usage record, so everything in how Boost routes requests applies to either. Responses differ only in shape:
  • A method Boost answers returns the typed BDS message. Data that does not exist returns a successful response with the data field unset, matching the proto’s “null if not found” convention.
  • Errors arrive as gRPC statuses: UNIMPLEMENTED for an unsupported method, INVALID_ARGUMENT for a bad parameter, RESOURCE_EXHAUSTED for an oversized eth_getLogs range, and NOT_FOUND for a cache-only refusal.
  • Structured errors carry bds.common.ErrorDetails in the status details, so a cache-only refusal carries DATA_NOT_FOUND and an oversized range carries RANGE_TOO_LARGE.
  • The observability headers arrive as initial metadata under the same names.

​
Supported networks

Boost offers networks whose indexed coverage starts at genesis. Networks with a later coverage floor are excluded so the same endpoint does not unpredictably serve recent history while forwarding older ranges. The dashboard and goldsky boost chains command are the live sources for availability. Goldsky indexes additional networks that Boost does not currently offer, including Arbitrum, BNB Chain, Celo, Gnosis, Sei, Tron, and Abstract. Their indexed coverage begins above genesis.

​
Billing

Boost is free to use. Goldsky does not charge for either served reads or forwarded requests. Forwarded calls still reach the RPC provider you pay separately. Usage appears on invoices as zero-dollar line items for calls Boost served and requests it forwarded. For mixed batches, use x-edge-billable to count the individual items Boost served.

​
Limits

  • Every request needs a Goldsky key. A keyless request receives an x402 payment challenge from the shared edge rather than using Boost.
  • The requested network must be enabled and have an active upstream in the project’s Boost configuration.
  • Upstream endpoints must be reachable over public HTTPS. Private, loopback, and link-local addresses are rejected.
  • Boost supports JSON-RPC and BDS gRPC over HTTPS. There is no WebSocket endpoint; keep eth_subscribe and other subscriptions pointed at your provider.
  • Batches can contain up to 100 items for per-item routing. Larger arrays are forwarded whole.
  • Rate limits are Goldsky-managed. Boost endpoints use a Goldsky-set budget rather than a customer-configured rate-limit budget.
  • Requests are unmetered within fair use. Contact Goldsky if you need a written volume commitment.