Skip to main content

Documentation Index

Fetch the complete documentation index at: https://goldrush.dev/docs/llms.txt

Use this file to discover all available pages before exploring further.

GoldRush JSON-RPC sits in front of multiple independent upstream providers and continuously scores them. Every call is routed to the upstream that currently has the best cost/performance score for that specific (chain, method) combination.

​
How routing works

GoldRush continuously collects analytics on every (provider, chain, method) triple:
  • success rate over rolling windows (1m, 5m, 1h)
  • p50 / p95 / p99 latency
  • error class distribution (timeouts vs. node errors vs. rate limits)
  • cost per successful call
A scoring function combines these into a per-route ranking. Each incoming JSON-RPC call is dispatched to the top-ranked provider for the specific chain and method requested. If that provider returns an error or a timeout, the next-ranked provider takes over (and the failure feeds back into the score). 
                              continuously updated
                              analytics table
                            ┌───────────────────────┐
                            │ provider × chain × ep │  ◀── success rate
                            │   → score             │      latency
                            └────────┬──────────────┘      error class
                                     │                     cost
                                     ▼
Request ──(chain, method)────▶ smart router ──▶ best-scoring provider for this route
If the top provider for a route is degraded, traffic shifts to the next-best provider automatically: scores update in seconds. If every provider for a chain is degraded, GoldRush returns an HTTP 503 with Retry-After.

​
Why route by analytics

Single-vendor RPC dependencies are the most common cause of dApp downtime. Static failover (always try A, fall back to B) wastes the second provider’s better path on calls where it’s actually faster or cheaper. Analytics-driven routing moves each call to whichever provider is winning right now for that exact chain and method, giving lower p99 latency and lower per-call cost than any single upstream.

​
Latency targets

PercentileEdge target
p50< 100ms
p95< 250ms
p99< 500ms
Targets are measured at the closest edge POP and exclude client-to-edge round-trip. Measured monthly across all supported chains.

​
Edge POPs

Edge POPs are deployed in:
  • us-east (Virginia)
  • us-west (Oregon)
  • eu-west (Ireland)
  • ap-southeast (Singapore)
  • ap-northeast (Tokyo)
Requests are routed to the nearest healthy POP automatically, with no client-side region selection.

​
Production SLA

GoldRush JSON-RPC ships with a 99.9% monthly uptime SLA for production accounts. Outage credits are issued automatically against your next invoice.
Monthly uptimeCredit
< 99.9%10% of monthly fee
< 99.0%25%
< 95.0%50%

​
What counts as “down”

For SLA purposes, a chain is considered down if every upstream provider for that chain fails to return a valid response for more than 60 seconds. Single-upstream outages, individual method failures, and chain-side reorgs do not count toward the SLA budget.

​
Status page and incidents

Live status: status.goldrush.dev. Incident notifications can be subscribed to via email or webhook.

Edge tier

What’s included on the production tier.

Pricing

Per-method credit rates.