Goldsky

Power a blockchain data product

Talk to our team

What it is

Powering a blockchain data product means supplying the decoded, multi-chain history that a data provider models, packages and sells, whether as dashboards, an API or data files.

Blockchain data providers and research firms need it each time a client asks for a new chain, because the product can’t cover a chain until its full history is loaded and kept current.

Goldsky backfills and decodes each chain’s history and keeps delivering new blocks into storage you own; the metrics, the methodology and the client relationship stay with you.

How a new chain gets into a blockchain data product

The diagram follows one new chain from a client’s request to that chain appearing in your product, and shows who does each step. Your setup may differ.

Add a chainA client asks for a new chain

TurboBackfill the historyEvery past event decoded, then kept live

Compute the metricsVolume, supply and balances, summed in your warehouse

TurboDeliver to your warehouseTables land in storage you own

Serve your clientsClients get the new chain in your product

Goldsky

Scope the new chain
A client request names a chain, and your team decides which of its datasets and contracts the product needs.
List the datasets, protocols and history the product needs, and map the chain’s columns to your existing tables. A chain loaded in a different shape can’t be summed with the others without rework.
Backfill the chain’s history
Handled by Goldsky Turbo
Clients compare a chain’s metrics over time, so the product needs its history from the first block.
The backfill has to finish before the chain goes into the product, then hand over to new blocks with no gap. Every new chain repeats this step, so a slow backfill holds up each client request.
Turbo Pipelines can run a backfill in job mode, as a one-time pipeline that exits once its block range is written, while a long-running pipeline keeps the chain current from there.
Run backfills in job mode (opens in a new tab)
Decode the events the same way on every chain
Handled by Goldsky Turbo
Your metrics are built from named fields, such as amounts and addresses, not from raw logs.
Decoding has to give every chain the same column names and types, so one query covers them all. Each chain decoded its own way turns every metric into a set of per-chain queries.
Turbo Pipelines dataset sources share one schema per dataset type across chains, and SQL transforms decode contract logs with _gs_log_decode(), so a transform written for one chain carries over to the next.
See the pipeline sources (opens in a new tab)
Deliver the tables to your warehouse
Handled by Goldsky Turbo
Your product reads from your own warehouse, so each chain’s tables have to land there.
Delivery repeats a batch after a crash and sends corrections after a reorg (the chain replacing its newest blocks), so tables need a key per row or a dedupe step on load. Without one, a metric counts the same transfer twice.
Goldsky’s Turbo Pipelines writes Parquet to a bucket, publishes to a queue, or writes rows into database tables keyed on a primary_key, where reorg corrections arrive as updates and deletes.
See the supported sinks (opens in a new tab)
Compute the metrics
Volume, supply and balances are what clients buy, and they’re sums over the raw rows.
Your warehouse computes each metric per period and per chain from the decoded rows. A metric computed before the backfill finished understates the history, so check row counts against the chain before publishing.
Serve the new chain to your clients
The work pays off when the chain appears in your product next to the others.
Your dashboards, API or data files pick up the new chain’s metrics. Publish when coverage starts and how each metric is defined, so clients know what each figure includes.