Goldsky

Improve RPC uptime and reliability with failover

Talk to our team

What it is

Improving RPC uptime means adding a backup RPC provider that your app fails over to when the main one times out, falls behind or returns incomplete results, so calls keep getting answered.

Teams that hold customer money build in that redundancy because an outage at a single blockchain data provider becomes their outage, with balances that stop updating and payments that can’t be sent, and high availability can’t depend on one provider.

Goldsky’s Edge RPC can serve the calls your client fails over, or replace your provider outright, since it fails over between several upstream nodes and checks their responses itself.

You keep your failover rules and the decision about when to switch.

You can improve RPC uptime and reliability three ways: fail over your RPC calls to Edge RPC as a backup provider, move all your calls to Edge RPC, which fails over between upstream nodes itself, or cross-check your main provider’s balances and transfers against the Feeds API.

How RPC failover keeps your app up

The diagram follows one failed call from the moment your main provider falters to your app still serving users. Your setup may differ.

Main provider faltersCalls time out or return gaps

Retry on the backupYour client sends failed calls to Edge

EdgeAnswer the callCross-checked across Edge’s own providers

TurboKeep events arrivingA running pipeline posts the same events

Stay onlineYour app keeps serving users

Goldsky

Ways to improve RPC uptime and reliability

Failover keeps your provider and puts Edge RPC behind it. Moving replaces your provider with Edge RPC and its built-in redundancy. Cross-checking leaves your provider in the path and compares its balances and transfers with the Feeds API, which catches wrong data rather than downtime.

Usual setupOption 1: RPC failover

Best for: Apps that must keep working when the main provider fails
Products: Edge Turbo
What you run: Your own client code
What you write: JSON-RPC calls, and the decoding of what comes back
Where your data lives: Read from the chain

Option 2: Move to Edge RPC

Best for: Teams that want failover built into one provider
Products: Edge
What you run: Your own client code
What you write: JSON-RPC calls, and the decoding of what comes back
Where your data lives: Read from the chain

Option 3: Cross-check with an API

Best for: Spot checks and per-wallet comparisons against the main provider
Products: Feeds
What you run: Nothing; you call an endpoint and keep what you need
What you write: REST requests
Where your data lives: Hosted by Goldsky

Ways to improve RPC uptime and reliability
	Usual setupOption 1: RPC failover	Option 2: Move to Edge RPC	Option 3: Cross-check with an API
Best for	Apps that must keep working when the main provider fails	Teams that want failover built into one provider	Spot checks and per-wallet comparisons against the main provider
Products	Edge Turbo	Edge	Feeds
What you run	Your own client code	Your own client code	Nothing; you call an endpoint and keep what you need
What you write	JSON-RPC calls, and the decoding of what comes back	JSON-RPC calls, and the decoding of what comes back	REST requests
Where your data lives	Read from the chain	Read from the chain	Hosted by Goldsky

Option 1: Improve RPC uptime with failover to a backup provider

Your client sends calls that fail at your main provider to Edge RPC, which responds from several upstream nodes and cross-checks their responses. If your main provider also sends you event webhooks, a pipeline can send the same events as a second feed.

When to use RPC failover

An outage at your main provider stops balances, history or payments in your app, and you need calls served while it’s down.

What you’ll need

Goldsky Edge
Goldsky Turbo
Your main RPC provider
A client or proxy that can retry calls on a second endpoint
An endpoint that receives event webhooks, if you also want a second event feed

Keep your main provider as the first call
A second source is a backup, so your app still sends its calls to the provider it already uses.
Your client has a list of endpoints in order of preference, with the main provider first. If the order lives in several services that each pick their own provider, a failover in one service can leave another still calling the endpoint that’s down.
Notice when the main provider falters
Failover only helps if your app can tell a bad response from a slow one before users notice.
Set what counts as a failure: a timeout, an error, or a block height that stops moving or lags the chain. A provider can also return a log query with gaps and no error, so checks on height and completeness catch more than error codes alone.
Retry failed calls on the backup
A call that failed at the main provider has to be served somewhere before the user notices.
Your client sends the same call to the second endpoint, once, within the time your app can wait. Retrying the same failing provider in a loop adds load and delay without an answer.
Answer the call from a checked source
Handled by Goldsky Edge
The backup only helps if its response is complete and current.
The second source has to return the same data the main provider should have, including archive reads and complete log ranges. A backup that returns stale or partial data turns an outage into wrong balances.
Edge RPC fails over between its own upstream nodes, tracks block heights across them and cross-checks responses so stale, incorrect or partial data doesn’t reach your app.
How Edge RPC checks responses (opens in a new tab)
Keep event notifications arriving
Handled by Goldsky Turbo
If your main provider also pushes events to you, such as incoming transfers, those stop during its outage too.
Whether to run a second event feed is your choice. If you do, your endpoint receives each event twice in normal times, so it needs a stable ID per event to drop repeats.
A running Turbo Pipelines pipeline can post the same events to your endpoint through its webhook sink, with retries on failure; corrections after a reorg arrive as records your endpoint applies.
Set up the webhook sink (opens in a new tab)
Keep serving users through the outage
The point of the second source is that customers see balances and history as usual while the main provider is down.
Your app serves from whichever source responded and records which one it was, then returns to the main provider when it recovers by the rule you set. Without that record, support can’t explain a balance that briefly looked different.

What to know about RPC failover

Your client decides when to fail over and when to return; Goldsky runs the second endpoint and its own failover between nodes.
The backup is in the request path, so it has to cover the same chains and methods your app calls.
A second event feed is optional, and its webhook receives reorg corrections that your endpoint applies itself.

Option 2: Improve RPC uptime by moving to Edge RPC

Your app sends all its RPC calls to Edge RPC in place of your current provider. Edge RPC fails over between several upstream nodes and cross-checks their responses, so the redundancy is built in and there’s no second provider to run.

When to move your calls to Edge RPC

You’re ready to replace your current provider, and you’d rather one provider run the redundancy than run failover between two yourself.

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 keeps your app up 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 fails after the switch.
Point your services at Edge RPC
Handled by Goldsky Edge
Calls move only when each service’s RPC URL changes.
Change the URL service by service 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 every call with failover
Handled by Goldsky Edge
With one provider, your uptime is its uptime, so it has to fail over inside 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, tracks block heights across them and cross-checks their responses before answering.
How Edge RPC handles failover (opens in a new tab)
Retire the old provider or keep it as a fallback
Once Edge RPC carries your traffic, the old provider is either a cost or a second line of defense.
After traffic has run on Edge RPC long enough to trust it, remove the old URLs and end the contract, or keep one as a client-side fallback behind Edge RPC. Leaving a service on the old provider by mistake keeps its outages yours.

What to know about moving to Edge RPC

Goldsky fails over between upstream nodes, so availability no longer depends on your client’s retry logic.
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.

Option 3: Improve RPC reliability by cross-checking with an API

Your app calls the Feeds API for the same wallets’ balances and transfers that your main provider reports, and compares the two responses.

When to cross-check with a balances and transfers API

Your concern is wrong or missing data from the main provider, and you want to catch it by comparing a set of wallets with a second source.

What you’ll need

Goldsky Feeds
Your main blockchain data provider
The list of wallets to check
A place to record mismatches and who follows them up

Keep your main provider as the first call
A second source is a backup, so your app still sends its calls to the provider it already uses.
Your client has a list of endpoints in order of preference, with the main provider first. If the order lives in several services that each pick their own provider, a failover in one service can leave another still calling the endpoint that’s down.
Choose the wallets to check
A second source is most useful on the wallets where a wrong answer costs most.
Pick the wallets, chains and how often to compare them, such as treasury wallets daily and a sample of customer wallets. Checking everything every few seconds costs more than the errors it catches.
Read the same wallets’ balances from a second source
Handled by Goldsky Feeds
You need an independent response to compare with what your main provider says.
The second response has to be for the same wallet, chain and token. A balance read from a different moment can differ for honest reasons, so note when each was taken.
Goldsky’s Feeds Balances endpoint returns a wallet’s native and ERC-20 holdings with USD values, and the docs note it works as a second source alongside another provider.
Read wallet balances (opens in a new tab)
Read the same wallets’ transfers
Handled by Goldsky Feeds
Balances can match while a transfer is missing, so the transfer history is checked too.
Pull transfers in and out for the same window from both sources. A transfer one source has and the other doesn’t is the clearest sign of dropped data.
The Feeds Transfers endpoint returns a wallet’s transfers newest first and can be limited by time or, on one chain, by from_block and to_block.
Query a wallet’s transfers (opens in a new tab)
Compare the two sources and chase breaks
A mismatch only helps if someone finds out which source is wrong and fixes what depended on it.
Your code compares balances and transfers and records each difference with both answers. Someone on your team checks the chain itself and corrects any customer balance that was built on the wrong answer.

What to know about cross-checking with an API

Your app pulls both sources, so a mismatch shows up only when you run the check.
The main provider stays in the request path, so this catches wrong data but doesn’t keep your app up during an outage.
The API covers the chains Feeds supports, so check your chains are on the list.
Your code does the comparing, so you decide what counts as a match and what to do with a break.

How to run RPC redundancy for oracle nodes

Give each oracle node several independent RPC providers per chain, so a provider outage doesn’t stop its reports.

Each oracle node lists several independent RPC endpoints for every chain it serves and moves to another when one fails or falls behind. Goldsky’s Edge RPC can be one of those endpoints, with its own failover across upstream providers.

What you’ll need

Goldsky Edge
Independent RPC providers for each chain the node serves
Your oracle node software and its configuration
Monitoring for node health and RPC errors

Line up independent RPC providers
A node that reads and writes through one provider stops reporting when that provider does.
Oracle networks ask the chains they integrate to have at least three separate, independent RPC providers. Independent means separate infrastructure, since two endpoints in front of the same nodes fail together.
List every endpoint in the node’s configuration
The node can only switch to an endpoint it already knows about.
Give each chain several endpoints with a priority order, and mark any that should only send transactions as send-only. Oracle node software can pick the endpoint with the highest block, rotate through them, or follow the priority order.
Add a provider with its own failover
Handled by Goldsky Edge
A provider that fails over across its own upstream nodes keeps answering when one of them drops.
Check what the node needs from each endpoint: some node features need a WebSocket connection, and every endpoint has to serve the finalized and latest block tags the node relies on.
Goldsky’s Edge RPC fails over across several upstream providers and cross-validates their responses. It serves HTTPS only, with no WebSocket endpoint, so add it where the node accepts an HTTP endpoint.
Check Edge RPC transports (opens in a new tab)
Drop endpoints that fall behind
An endpoint that answers with old blocks is worse than one that doesn’t answer at all.
The node polls each endpoint, marks it unreachable after repeated failed polls, and treats one that lags too far behind the best as out of sync. Alert on those changes, because a pool that has quietly shrunk to one endpoint has lost its redundancy.

What you control

Your team: Keep your main provider as the first call
Notice when the main provider falters
Retry failed calls on the backup
Keep serving users through the outage