Who uses onchain data for index and benchmark calculations?

Index and benchmark providers, crypto data vendors and research firms that calculate indexes from onchain activity.

Goldsky

Onchain data for index and benchmark calculations

Talk to our team

What is onchain data for index and benchmark calculations?

Onchain data for index and benchmark calculations is the protocol activity, such as volume, fees and token supply, that an index methodology turns into a published level; index firms often call it onchain fundamentals or onchain metrics.

Index and benchmark providers need the full history to backtest a methodology before launch, then current, complete figures at every calculation, because licensees and products track the level they publish.

Goldsky loads and decodes the history and keeps delivering new rows to your warehouse; the totals, the methodology, the calculation and the published level stay with you.

How onchain data feeds an index calculation

The diagram follows one index from the metrics its methodology names to the level you publish, and shows who does each step. Your setup may differ.

Define the indexYour methodology names protocols and metrics

TurboLoad the historyEvery past event decoded, for backtests

Total the fundamentalsVolume and supply, summed in your warehouse

TurboDeliver to your warehouseFresh rows land where you calculate

Calculate the indexYour methodology runs on the totals

Publish the levelLicensees and products track it

Goldsky

Define the index methodology
The methodology decides which protocols and metrics count, so it sets what data you need.
It names the protocols, the contracts behind them, the metrics (such as volume or supply) and how often the level is calculated. A metric nobody can trace to a contract can’t be checked by the people who license the index.
Load the history for backtests
Handled by Goldsky Turbo
A methodology is tested on years of past data before anyone tracks it.
Every past event for the named contracts is loaded and decoded the same way the live data will be. A backfill decoded differently from the live data produces a backtest the live index can’t reproduce.
Turbo Pipelines can load a fixed historical range as a one-time job that exits once its last block is written, using the same SQL transform as the live pipeline.
Run one-time backfills (opens in a new tab)
Deliver fresh rows to your warehouse
Handled by Goldsky Turbo
Each calculation reads the latest data, so new events have to arrive before it runs.
Rows have to land complete for the period being calculated, with corrections when a reorg (the chain replacing its newest blocks) undoes an event. A calculation run on missing or reversed rows publishes a wrong level.
Goldsky’s Turbo Pipelines keeps streaming new blocks to your warehouse tables or bucket, and tables keyed on a primary_key take reorg corrections as updates and deletes.
How corrections reach your tables (opens in a new tab)
Total the fundamentals
An index works from per-period figures, such as daily volume per protocol, not from single events.
Your warehouse sums the decoded rows per protocol and period. Set a cutoff for each period and handle later corrections under your restatement policy, or the same period can produce two levels.
Calculate the index level
The methodology turns the totals into one number.
Your calculation applies the weights, caps and rebalancing rules to the totals. Keep each run’s inputs, so you can show how a published level was reached.
Publish the level
Licensees, funds and products track the level, so it has to go out on schedule.
You publish through your usual channels, and some providers also write the level to a chain. A late or restated level affects every product that tracks it, so corrections follow your published policy.