Skip to main content
Query chains of historical blockchain data with SQL. Query execution is asynchronous: you queue a run, get a run_id back, then fetch results with get_query_run_results.
Call get_skill(name="sql-optimization") once at the start of a SQL session. Allium’s Snowflake tables are large; the skill covers the partition and clustering rules that keep a query from scanning a full chain. See Skills.

Available tools

The execution model

Every query runs through the same two-step flow.
1

Queue the run

run_sql_query and run_explorer_query return immediately with a run_id and status: "queued". create_explorer_query(run_on_creation=true) returns status: "created" and puts the run’s ID in initial_run_id. None of them return rows.
2

Fetch the results

Call get_query_run_results with the run_id. Pass poll_timeout_seconds to block until the run finishes; omit it for a single non-blocking status check.
The response carries the SQL, the column metadata, the rows, the run status, and the run’s cost in Explorer Units.
Two separate caps apply, and the query-side one depends on which tool you used:
  • run_sql_query caps the run at 1,000 rows.
  • Saved queries (create_explorer_query / run_explorer_query) cap at the query’s own row limit — 10,000 by default, and your organization can be configured higher.
  • Either way, the tool response truncates to row_limit (50 by default) so a large result doesn’t flood your agent’s context.
Raise row_limit deliberately. See Billing & limits.

Choosing a tool

run_sql_query

Throwaway. Sample rows, check distinct values, answer one ad-hoc question. The run isn’t saved and can’t back a chart.

create_explorer_query

Reusable. Anything that feeds a visual or dashboard, needs a permalink, or is expensive enough to re-run later.
Don’t run SQL with run_sql_query and then save the same SQL with create_explorer_query — that bills the compute twice. If the result might be reused, start with create_explorer_query(run_on_creation=true).

Run ad-hoc SQL

Returns: { "run_id": "...", "status": "queued", "sql": "..." }

Save and run Explorer queries

Create

Returns: a query_id, the query’s Explorer URL, and — when run_on_creation is true — a run_id.

Run

Template parameters use {{parameter_name}} syntax in the saved SQL.

Update, list, delete

update_explorer_query takes a query_id plus only the fields you want to change — everything else is preserved. list_explorer_queries accepts search (title match), tags (returns queries carrying at least one), and limit (default 50). delete_explorer_query is permanent.
Tag queries that belong to the same dashboard or topic, then use the tags filter to find them again in a later session.

Compute profiles

Each compute profile maps to a dedicated Snowflake warehouse sized as a speed multiplier — 1x, 2x, 4x, 8x, 16x — with its own queue, shared org-wide but isolated from other profiles.
Each entry returns an identifier, is_default, and live queue state: Pass a profile’s identifier as the compute_profile argument to run_sql_query, run_explorer_query, or create_explorer_query. Prefer a profile with a low queued count — a bigger warehouse that’s busy can start later than a smaller idle one. Omit compute_profile to use the profile where is_default is true.

Find the right tables

Search schemas, docs, and Terminal dashboards first

Chart the results

Turn a saved query into visuals and dashboards

Billing & limits

Explorer Units, row caps, and timeouts

Data Catalog

Browse every schema available to SQL