Schema v0.9: a draft for comment

I own the normalization layer at Finance Data Cloud, which means I spend my days deciding what a trade is. That sounds trivial until you have read the trade messages of a dozen venues side by side. They disagree on what "side" means, on whether a timestamp marks the match or the publication, on how to write a price, and on what to call the same perpetual. The schema is where those disagreements get settled once, so that nobody downstream has to settle them again.

Version 0.9 is published in the schema reference, and the changes from earlier drafts are listed in the changelog. This post covers the decisions that shaped it and the questions we have not closed.

What is in the draft

The draft defines every table we intend to ship: trades, quotes, candles, book_l2, book_l3, book_l4, funding, open_interest, liquidations, mark_index, options_chain, instruments, extended and gaps, plus the two chain intelligence tables. Every table shares the same leading columns: venue, symbol, venue_symbol, ts_exchange, ts_capture, seq and source. A join across venues should never need a lookup table.

Decisions we are fairly sure about

Two timestamps, in nanoseconds

Every row carries the venue's timestamp and our receive timestamp, both int64 nanoseconds since the Unix epoch, UTC. Venues stamp in milliseconds or microseconds today, and nanoseconds leave room for the ones that will not. Priya's timestamp study is the reason we keep both and overwrite neither.

Decimals, never floats

Prices and sizes are decimal128(38,18) in Parquet and strings in JSON. A float64 has about 15 significant digits, and a low-priced token quoted to eight decimals with sizes in the hundreds of millions runs out of them. If you want floats, the conversion is one line in your own code, done at the precision you choose.

One symbology

BTC-USDT is spot, BTC-PERP is the default perpetual, BTC-USDC-PERP and BTC-USD-INV-PERP name the other margin types, BTC-27MAR27 is a dated future and BTC-27MAR27-90000-C an option. The venue's own symbol is always kept in venue_symbol. The rules are in symbology.

Aggressor side, always

In trades, side is "buy" or "sell" and always means the aggressor. Venues that report the maker side are flipped during normalization, and the raw tier keeps the original message for anyone who wants to check.

Depth as event logs

book_l3 records order events with four types: add, modify, cancel and fill. book_l4 is the same table with a participant identifier where the venue publishes one. Lukas and Daniel's L3 queue study uses exactly these events.

Provenance and gaps as data

The source column says whether a row came from our own capture ("fdc_capture") or from a venue's licensed historical archive ("venue_archive"). The second value only appears where the agreement with that venue includes historical data. Missing data is never filled silently. It is recorded in the gaps table, and the data quality page explains how.

What the draft leaves out

Some venue messages carry fields that exist nowhere else, and v0.9 does not try to give each of them a column. Where a value has a clear home in a shared table, it goes there: Hyperliquid's oracle price, for example, sits in mark_index next to mark and index prices from other venues. Where it does not, the value stays in the raw tier, which stores every message untouched before normalization and can be requested alongside the normalized rows. Columns for venue-specific values can be added in a minor version after v1.0 if enough of you ask for them.

Open questions

These are the points where we have a working answer in v0.9 and real doubts about it. Comments on them are the most useful thing you can send.

1. Participant identifiers in book_l4. v0.9 stores the venue's raw identifier in participant_id, which on Hyperliquid is the user address, and fills our cross-venue entity_id only for accounts with chain intelligence. An alternative is a stable identifier of our own on every row, for every plan. Do you want the raw value, ours, or both columns?
2. Absolute or relative L2 deltas. book_l2 deltas in v0.9 carry the new absolute size at a level, which is what most venues send. Some of you have asked for the signed change instead, which is easier to aggregate. We can add it as a column at some storage cost.
3. Wide or long extended table. v0.9 stores extended in long format (one row per field, variant and timestamp), which is easy to extend. It can also be requested in wide format, one column per field and variant, with wide=True in the SDK or layout=wide in REST, which is easier to query. We are unsure which should be the default and would like to hear from anyone who has lived with either.
4. Funding intervals. Each funding row carries the venue's native rate and interval (interval_s) plus an hourly rate, rate_1h, for the reasons in our funding alignment note. v0.9 also includes rate_ann (rate_1h × 8,760), and we are unsure whether an annualized column belongs in the table or in your code.
5. Greeks in options_chain. v0.9 only includes implied volatility and greeks where the venue publishes them. Computing our own for venues that do not would fill gaps, and it would also put a model of ours in your data.

How to comment

Send comments to daniel@financedatacloud.com with "schema v0.9" in the subject line. Pre-registered partners can also reply to their onboarding email and it will reach me. The comment period runs until October 31, 2026. After that we will publish a v0.10 with responses to every substantive point, and we intend to freeze v1.0 before Hyperliquid early access opens in Q1 2027. After the freeze, changes follow the versioning rules in the changelog.

If you only have five minutes, read the trades and book_l3 sections and tell me what would break your code.