On-Chain Data Analyst: Skills, Portfolio and Jobs

An on-chain data analyst turns blockchain records into a defensible answer to a business or research question. The useful output is not just a dashboard. It is a clear definition of the metric, reproducible logic, an explanation of what the data misses and a conclusion someone can act on.

This guide focuses on a practical portfolio and job-search process. The project and review rubric below are editorial suggestions, not an employer's interview process. We have removed unsupported salary ladders and freelance-income claims from the previous version.

What the Work Can Involve

Protocol analytics might examine usage, retention or fee activity. A research role might compare protocols or investigate changes in a dataset. Data engineering focuses more on ingestion, transformations, reliability and serving data to other teams.

Read the responsibilities closely. "Data analyst," "data scientist" and "data engineer" can describe different jobs. Do not assume an on-chain role is entry-level, remote or open in your country because its data is public.

Start with current data roles, the role guide and the live listings at the end of this article.

A Small, Useful Toolset

SQL and a data catalog: Dune's DuneSQL overview describes its Trino-based query engine. Learn joins, aggregation, window functions, null handling and how to inspect the schema before writing a query.

An explorer and protocol documentation: Use them to inspect individual records and understand which contract interactions your metrics include. A chart is easier to trust when you can trace a surprising point back to its underlying transactions.

A notebook or version-controlled repository: Keep the query, a small exported result, validation checks and a plain-language write-up together. Python can help automate checks, but a clear SQL project is a better first milestone than an unfinished stack of tools.

An indexer when the task needs one: The Graph's subgraph manifest documentation explains how data sources, contract events and mappings define what a subgraph indexes. This is a different layer from querying an existing analytics table.

Portfolio Project: Activity Is Not the Same as Adoption

Use this question: "How did observed DEX activity change during a fixed week, and what would we need to know before calling that user growth?"

Start with one chain and a short, fixed interval. Dune documents dex.trades at the trade-segment level: a multi-hop swap can create more than one row. Count rows and distinct transactions separately.

The following is a starter query, not a completed research result. Check the live schema and run it in Dune before using its output:

SELECT
  block_date,
  COUNT(*) AS trade_segments,
  COUNT(DISTINCT tx_hash) AS transactions,
  COUNT(DISTINCT tx_from) AS transaction_senders,
  COUNT_IF(amount_usd IS NULL) AS unpriced_segments,
  SUM(amount_usd) AS priced_segment_volume_usd
FROM dex.trades
WHERE blockchain = 'ethereum'
  AND block_month = DATE '2026-09-01'
  AND block_date >= DATE '2026-09-01'
  AND block_date < DATE '2026-09-08'
GROUP BY block_date
ORDER BY block_date

Transaction senders are addresses, not identified people. The volume is the sum of priced trade segments, not necessarily end-user swap volume. Missing prices are counted separately, not silently treated as evidence of zero activity. Use the table's documented columns and definitions when explaining those distinctions.

The chain and date restrictions also limit the scan. Dune's query efficiency guide recommends filtering by time and chain and selecting only the columns needed. Record runtime and scope alongside the results; do not claim the sample query has been benchmarked here.

Checks That Make the Project Credible

Before publishing, add a short quality log:

1. Coverage: Name the chains, protocols and dates included. Explain why they answer the question.
2. Grain: State what one row means. Check whether joins multiply rows.
3. Missingness: Count missing values before excluding or filling them.
4. Spot checks: Inspect a few transactions, including a multi-hop example and an unusual day.
5. Boundaries: Use a consistent timezone and exclusive end date. Distinguish an incomplete day from a full one.
6. Reproducibility: Include the query, run date, data-source link and any transformations after export.
7. Interpretation: List alternative explanations for a spike. A chart alone does not establish cause.

For a second version, choose one protocol and investigate a specific anomaly. Keep a record of what changed your initial explanation. That shows analytical judgment more clearly than adding ten more charts.

What to Put in the Portfolio

Ship one concise case study with four artifacts: the question and scope, the query, a readable result, and a limitations note. Your conclusion should separate observed facts from hypotheses.

A useful self-review rubric is:

These are suggested review criteria, not a scoring system used by every employer. A smaller project that survives scrutiny is more useful than a broad dashboard you cannot explain.

Applying and Discussing Compensation

Match the case study to the vacancy. A product analytics team may value a well-defined retention question; a data engineering role may need stronger evidence of pipeline reliability. Use the employer's actual requirements to decide what to emphasize.

For salary research, inspect published data-analyst ranges. Check the sample size, employers, location and seniority. A broad range is not a junior salary estimate, and an hourly contract is not guaranteed annual employment.

Prepare to explain one incorrect assumption you found, how you tested it and what you still do not know. Do not claim investment performance, business impact or production usage that your project has not demonstrated.

A Four-Week Practice Plan

• Week 1: Inspect the data model, write the first query and define every metric.
• Week 2: Validate the results, document missing data and investigate an anomaly.
• Week 3: Publish the case study and ask for feedback on one specific question.
• Week 4: Revise the work and use it in a small set of relevant applications.

This is a practice schedule, not a promise of becoming job-ready in four weeks. Existing SQL experience, the role's requirements and the depth of the project determine what additional work is needed.

For presentation and application structure, see the Web3 portfolio guide and resume guide.