Goldsky

• Name: Goldsky
• URL: https://goldsky.com/
• Category: blockchain data infrastructure company / managed indexing-and-streaming vendor / RPC infrastructure operator
• Tags: ethereum-ecosystem
• Summary: Goldsky belongs as an entity note more than a protocol note. The useful cut is that a named company operates a managed blockchain-data backend spanning Graph-compatible indexing, chain-data streaming into external databases, and performance-marketed RPC access. The practical leverage comes from ingest, backfill, reorg, caching, failover, and chain-support policy that customers inherit by depending on Goldsky’s hosted stack.
• What it does:
  • Provides Subgraphs for GraphQL-based indexing and query endpoints with historical and realtime support
  • Offers Mirror for streaming onchain data into external databases with backfills, reorg handling, and configuration-driven pipelines
  • Markets Turbo as a newer streaming-pipeline product with TypeScript transforms, snapshots, dynamic tables, and cross-chain aggregation
  • Runs Edge RPC for EVM-network access with caching, failover, hedging, and indexer-oriented behavior
  • Publishes a broad docs surface, including product intros and an llms.txt index, which makes the operator surface unusually legible for this kind of vendor
• Key claims:
  • The homepage calls Goldsky the modern back-end for crypto-enabled products and presents it as infrastructure for teams that need production-grade crypto data systems
  • Official materials claim 150+ chains at the site level, while Mirror docs mention 130+ chains; those numbers appear product-scope dependent and should not be treated as one clean metric
  • The site advertises scale claims such as $12B+ TVL powered, 4 PB+ of crypto data stored, and 500 TB+ of on-demand datasets; useful signals, still vendor claims
  • Edge RPC docs emphasize low latency, automatic failover, data cross-validation, and pricing aligned to production app and indexer workloads rather than hobbyist RPC use
  • The product mix makes the main point clear: Goldsky is selling an easier way to consume chain data without owning ingestion, normalization, replay, and serving yourself
• Whitepaper: No classic whitepaper or litepaper was found during this pass. The strongest primary materials were Goldsky’s official site and docs portal; see ../whitepapers/goldsky-primary-sources-2026-04-23.md.
• Sources:
  • https://goldsky.com/
  • https://docs.goldsky.com/introduction.md
  • https://docs.goldsky.com/llms.txt
  • https://docs.goldsky.com/mirror/introduction
  • https://docs.goldsky.com/edge-rpc/introduction

Internal linkages

• Alias / prior project-layer entry: goldsky.
• Best upward comparison points: the-graph, sqd, and firehose.
• Useful adjacent company contrast: alchemy.

Protocol / company boundary

• goldsky is intentionally only an alias because there is not a very useful standalone Goldsky protocol boundary doing separate analytical work here.
• The important surface is the company-run operator shell: managed indexing, replay and backfill behavior, reorg handling, pipeline transforms, RPC routing, supported-chain coverage, and the dashboard and API workflow customers inherit.
• That is why the canonical note lives in companies/: the durable dependency is on Goldsky as a named operator, not on a neutral lower-layer primitive.

Control surface

• Practical leverage sits in ingest and normalization choices, replay and backfill policy, reorg handling, cache and failover behavior, supported-chain coverage, and how much of a team’s data path hardens around Goldsky-managed infrastructure.

• Read it as managed blockchain-data middleware with real room to turn product defaults into operator power.

• Last reviewed: 2026-08-09 UTC