Skip to content
OnchainQueries

OQ — L∙ · Engineering · 2026-08-14

Most analytical engines have a function called filter. They do different things — and that is why OnchainQL rejects it rather than running it.

Placeholder post — replace before launch

There is a category of bug that costs an analyst a week and a company a decision. It is not the query that fails. It is the query that runs, returns a plausible number, and is wrong.

OnchainQueries translates a curated set of OnchainQL forms to their execution forms: date_trunc to dateTrunc, count_if to countIf, approx_percentile to quantileTDigest, the base58 helpers, JSON scalar extraction, varbinary casts, and UNNEST to ARRAY JOIN. Those translations are verified. Everything else passes through untouched.

Passing through is fine when the function does not exist on the other side — you get an error. The dangerous case is when it exists and behaves differently. element_at, filter, reduce, transform and zip_with all have same-named functions underneath, as do map, map_filter, map_transform_keys and map_transform_values. Their semantics do not match the ones an analyst coming from another engine expects.

So OnchainQueries rejects them explicitly. You get an error naming the function and telling you it is not compatibility-safe. That costs you five minutes of rewriting. The alternative costs you the analysis, and you would never know.

The same reasoning drives the coverage disclosures. dex_solana.trades exists, but it covers Pump Fun only, and its token symbol and USD columns are NULL. We could have quietly shipped it as a market-wide view. Instead the docs say exactly what it is, because a convenience view that silently under-reports volume is worse than no view at all.