Goldsky

Optimize your RPC endpoints and cut RPC costs

Talk to our team

What it is

Automatically optimizing your RPC endpoints means putting an RPC CDN in front of your existing RPC provider that answers reads for blocks, transactions, receipts and logs from indexed data and forwards everything else.

Indexers, risk vendors and wallet backends use it because they read the same historical data again and again, and each of those reads is a billable RPC call.

Goldsky’s Boost answers the reads it can from Goldsky’s indexed data and forwards state reads, traces and writes to your provider, so you lower billable RPC calls while keeping your provider, your client code and the decision about which calls to route.

You can optimize your RPC endpoints two ways: put Boost, an RPC CDN, in front of your current provider so indexed reads are answered before they reach it, or move your calls to Edge RPC.

How Boost cuts your RPC costs

The diagram follows your app’s RPC calls through Boost, and shows which get a response from Goldsky’s CDN and which go on to your provider. Your setup may differ.

Your app reads the chainEvery call goes to your Boost endpoint

BoostBoost handles the trafficSits in front of your RPC provider

Fewer billable callsOnly calls routed to your provider are billed

BoostResponse from Goldsky’s CDNIndexed, reorg-safe blocks, receipts and logs

BoostRoute to your providerContract state reads and sent transactions

Goldsky

Ways to optimize your RPC endpoints

Boost sits in front of the provider you already use and forwards whatever it can’t serve, while moving to Edge RPC replaces that provider and its failover.

Usual setupOption 1: RPC CDN in front of your provider

Best for: Read-heavy backends that keep their current provider
Products: Boost
What you run: Your current RPC provider
What you write: One URL change

Option 2: Move to Goldsky’s RPC

Best for: Teams replacing their provider and its failover in one move
Products: Edge
What you run: Your own client code
What you write: JSON-RPC calls, and the decoding of what comes back

Ways to optimize your RPC endpoints
	Usual setupOption 1: RPC CDN in front of your provider	Option 2: Move to Goldsky’s RPC
Best for	Read-heavy backends that keep their current provider	Teams replacing their provider and its failover in one move
Products	Boost	Edge
What you run	Your current RPC provider	Your own client code
What you write	One URL change	JSON-RPC calls, and the decoding of what comes back

Option 1: Cut RPC costs with an RPC CDN in front of your provider

Your app sends its RPC calls to a Boost URL. Boost serves reads for blocks, transactions, receipts and logs from Goldsky’s indexed data and forwards everything else to the provider you already use.

When to put an RPC CDN in front of your provider

Most of your calls read blocks, receipts or log ranges at fixed heights, and you want to keep your provider and client code.

What you’ll need

Goldsky Boost
Your current RPC provider and its endpoint credentials
Access to the config where your services set their RPC URL

Find which calls cost you the most
Boost only lowers billable calls for reads it can answer, so you need to know what your app sends.
Count your calls by method and block tag from your provider’s usage report or your own logs. Calls for fixed blocks, receipts and log ranges are the ones Boost can answer; state reads and traces stay with the provider.
Send reads through Boost
Handled by Goldsky Boost
Boost can only answer calls that reach it.
Point each service’s RPC URL at Boost and give Boost your provider’s endpoint as its upstream. Services left on the old URL keep sending every call to the provider, so list every place the URL is set.
Boost keeps the same JSON-RPC interface, so your app swaps its RPC URL for a Boost URL and Boost uses your project’s configured provider as the upstream.
How Boost fits into your stack (opens in a new tab)
Answer historical reads from indexed data
Handled by Goldsky Boost
Reads for blocks, receipts and logs that already exist give the same response every time, so they don’t need to reach a paid provider.
A read can be served from indexed data only when it names a fixed block, a hash or the latest block. Ranges written with tags such as finalized can’t be answered from indexed data, so rewriting them with block numbers moves more calls off the provider.
Goldsky’s Boost serves eth_getBlockByNumber, eth_getTransactionReceipt, eth_getLogs with concrete heights and similar reads from Goldsky’s indexed data, which follows the chain through reorgs. Traces, eth_call and other state reads still go to your provider.
Which calls Boost serves (opens in a new tab)
Route the rest to your provider
Handled by Goldsky Boost
State reads, traces and writes need a live node, so they still go to the provider you pay.
Calls that can’t be served from indexed data are forwarded with the same method, parameters and ID, and the response comes from your provider. If the provider is down, those calls fail as they would without Boost.
Boost forwards eth_call, traces, transaction sends and any other call it can’t serve from indexed data to the provider set as your project’s upstream.
Which calls Boost forwards (opens in a new tab)
Lower your RPC bill
Every read served from indexed data is a call your provider no longer bills.
Your provider now sees only the calls routed to it: state reads, traces and writes. With usage-based pricing, your bill falls with that call count, and the more of your traffic is historical reads, the larger the drop.

What to know about an RPC CDN

You keep your provider and contract; state reads, traces, writes and pending, safe or finalized tags still reach it.
Only reads with a concrete block height or hash, or latest on block lookups, can be answered from indexed data.
Response headers show which calls Boost answered, so you can measure the change on your own traffic.

Option 2: Optimize your RPC endpoints by moving calls to Edge RPC

Your app sends all its RPC calls to Edge RPC in place of your current provider. Edge RPC routes old-block requests to archive nodes, fails over between upstream nodes and merges identical requests.

When to move your calls to Edge RPC

You’re ready to replace your current provider, and you want one provider to run the RPC layer and its failover for you.

What you’ll need

Goldsky Edge
A list of the chains and RPC methods your app calls
Access to the config where your services set their RPC URL
A test environment to compare responses before switching

List the chains and methods you call
A move only works if the new provider serves everything your app sends.
Pull the chains, methods and any WebSocket subscriptions from your logs or provider report. A method you didn’t list is the one that breaks after the switch.
Point your services at the new endpoint
Handled by Goldsky Edge
Calls move only when each service’s RPC URL changes.
Change the URL service by service, starting with one that reads history, and compare responses with the old provider before moving the rest. Code that relies on WebSocket subscriptions needs rewriting to poll.
Edge RPC takes standard JSON-RPC over HTTPS; to watch the chain without WebSocket, it supports polling with eth_newFilter and eth_getFilterChanges.
Edge RPC transport and methods (opens in a new tab)
Serve reads and writes with failover
Handled by Goldsky Edge
Once you’ve moved, there’s no second provider behind your app unless the new one fails over itself.
The endpoint has to respond when one node lags or fails, and log queries have to come back complete. A provider that returns partial logs without an error gives your app silently wrong data.
With Goldsky, Edge RPC fails over across upstream nodes, cross-checks their responses and merges identical requests from many users into one upstream call.
How Edge RPC handles failover (opens in a new tab)
Retire the old provider
The saving arrives only when the old contract stops billing.
Once traffic has run on the new endpoint long enough to trust it, remove the old URLs and end the contract by its terms. Leaving one service on the old provider keeps the bill alive.

What to know about moving to a different RPC provider

Goldsky runs the provider layer and the failover between nodes; you no longer manage a provider contract alongside it.
Every call moves, including writes and state reads, so check each chain and method you use is covered.
Edge RPC is served over HTTPS only, so code that subscribes over WebSocket has to poll with filter methods.

What you control

Your team: Find which calls cost you the most
Lower your RPC bill

Security and deployment

SOC 2 Type IIIndependently audited security controls.
Dedicated infrastructureSingle-tenant options for production workloads.
Data residencyCloud, on-premises or co-located.