Skip to content
OnchainQueries

OQ — L∙ · Product · 2026-07-08

Every OnchainQueries result ships a manifest with per-part checksums, the physical tables read, a catalog hash and the slot it was planned at. Here is why all four matter.

Placeholder post — replace before launch

Most analytics platforms give you a number. OnchainQueries gives you a number and the means to prove where it came from.

Every completed query writes numbered Parquet or Arrow parts plus a manifest.json. The manifest records the output schema, the row count, a SHA-256 for every part, the physical source tables the query actually read, the catalog hash, the high-watermark slot the query was planned at, and the expiration time.

The checksums mean a downloaded part is verifiable — the CLI writes each part as .partial, checks size and checksum, and only then renames it. The source coverage means you can answer 'what is this number based on' without guessing. The catalog hash and watermark slot mean you can tell whether two results are comparable.

There is one more guarantee that is easy to miss. OnchainQueries fingerprints source partitions before and after execution. If the catalog or the relevant partitions change while a query is running, it retries the affected work rather than publishing a result that spans two versions of the source. A OnchainQueries result is always internally consistent.

Results expire server-side after 24 hours. Files you have already downloaded do not — and because they carry their own manifest, they stay verifiable long after the query that produced them is gone.