
How to Build a Crypto Data Team

Key takeaways
Hire by funding stage: no dedicated hire before launch (a founder plus tools), a first analyst after the token generation event (TGE) or Series A, and a data engineer with a warehouse at Series B and later.
Write a tracking plan before launch. It is cheaper than any hire, and it decides what you can answer later.
Buy product analytics, decoded chain data, and wallet intelligence. Build only the metrics and models that are specific to your protocol.
Give every dashboard one named owner. A dashboard without an owner goes stale within one quarter.
Report active wallets, retained liquidity, and incentive cost per retained wallet next to TVL (total value locked). TVL alone hides mercenary capital and sybil farming.
To build a crypto data team, hire in stages that follow your funding. At pre-launch and seed, you hire no one: a founder owns a tracking plan and a few bought tools. After TGE or a Series A, hire your first analyst to own KPIs and incentive reporting. From Series B, hire a data engineer to add a warehouse, an indexer pipeline, and governance-grade reporting.
What does a crypto data team do?
A crypto data team turns onchain and offchain activity into decisions. It defines the KPIs, keeps one source of truth for them, measures incentive programs, and produces the reports that token holders, grant committees, and investors expect. At a small DeFi protocol this is one person. At a large protocol it is a team.
The work falls into four jobs:
Measurement. Define what an active user, a retained wallet, and protocol revenue mean for your protocol.
Growth support. Answer which channels, campaigns, and integrations bring wallets that stay.
Incentive and token analysis. Measure emissions, points, and airdrops against the behavior they buy.
External reporting. Produce governance, grant, and investor reports that other people can check.
Job | Main consumers | Typical output |
|---|---|---|
Measurement | Founders, product | KPI dashboard, metric definitions |
Growth support | Growth, BD, marketing | Funnel and attribution reports, cohort tables |
Incentive analysis | Tokenomics, governance | Emissions ROI, retention after rewards end |
External reporting | DAO, grant programs, investors | Monthly governance report, investor update |
How should a crypto data team be structured at each stage?
A crypto data team's structure follows funding and complexity. Pre-launch teams need a founder who owns metrics and a tracking plan. Post-TGE or Series A teams need one analyst who can write SQL on decoded tables. Series B and later teams need a data engineer, a warehouse, and formal ownership of each report and metric.
Stage | Who owns data | Headcount | Main deliverables |
|---|---|---|---|
Pre-launch / seed | A founder or technical PM | 0 dedicated | Tracking plan, launch dashboard, testnet funnel |
Post-TGE / Series A | First data analyst (or fractional lead) | 1 | KPI dashboard, incentive reports, investor update data |
Series B+ | Head of data, data engineer, analysts | 3 to 8 | Warehouse, indexer pipeline, governance and token-holder reports |
Headcounts are editorial guidance from typical team setups, not survey data. Scale them to your product count and chain count.
Pre-launch and seed: who owns data before the first hire?
At this stage a founder owns data. The goal is not dashboards. The goal is a tracking plan that names every event you will need later: page views, wallet connects, signature requests, transactions, and the decoded contract events (logs) that prove a deposit or a swap happened. Instrument the app and the contracts before mainnet, not after.
Keep the stack small. A product analytics tool with wallet and contract event support, plus a public query platform such as Dune for contract-level views, covers most questions. Formo is one option here: its SDK records wallet events such as connect, signature, and transaction, and it can decode events from contracts you register on supported EVM chains.
Post-TGE and Series A: when should you hire the first data analyst?
Hire the first analyst when two things are true: you run incentives or a token, and founders spend more than a few hours each week answering metric questions. This often happens in the months after TGE, when emissions, points, and governance reporting create questions that nobody owns.
The first analyst should own:
The KPI dashboard and the written definition of each metric.
Incentive and token reports: who received rewards, and who stayed after.
The data for investor updates and governance posts.
Ad hoc analysis for growth and BD, such as integration performance and campaign quality.
If a full-time hire is too early, consider a fractional head of data: a senior lead who works part time on strategy, KPIs, and stack design. Ask any provider who owns the work after the engagement ends.
Series B and later: when do you need a data engineer and a warehouse?
You need a data engineer when the analyst spends more time fixing pipelines than answering questions. Typical triggers are multiple chains, several deployments of the same contracts, offchain data from the app and CRM, and token-holder reports that must reconcile to the cent.
At this stage the team adds:
A data engineer who owns ingestion, the indexer pipeline, and data quality tests.
A warehouse where onchain, app, and finance data meet, modeled with a tool such as dbt.
Governance over metrics: one definitions document, version control for SQL, and a review step for anything published to token holders.
What data stack does a DeFi protocol need at each stage?
A DeFi data stack has five layers: product analytics, an indexer or pipeline, a warehouse with SQL, a BI layer, and wallet intelligence. Early teams buy most layers as hosted tools. Later teams keep the bought tools for speed and add their own warehouse and models for the metrics that are unique to the protocol.
Layer | Pre-launch / seed | Post-TGE / Series A | Series B+ |
|---|---|---|---|
Product analytics and attribution | Hosted tool (for example Formo) | Same, plus funnels and cohorts | Same, with exports to the warehouse |
Indexer / pipeline | None, or a hosted subgraph | Hosted indexer (for example Goldsky Subgraphs) | Streaming pipeline (for example Goldsky Turbo) or own ingestion |
Warehouse / SQL | Public query platform (Dune) | Dune or Allium, plus the analytics tool's SQL | Own warehouse (Snowflake, BigQuery, ClickHouse) with dbt |
BI | Built-in dashboards | Built-in dashboards plus one BI tool | BI tool connected to the warehouse |
Wallet intelligence | Built into the analytics tool | Labels for segments and sybil checks | Labels joined into warehouse models |
Notes on the tools in the table:
Goldsky offers Subgraphs (hosted GraphQL APIs) and Turbo, a streaming pipeline that writes chain data to your own database (for example PostgreSQL or ClickHouse), or to Amazon S3 for loading into a warehouse (docs checked November 8, 2026).
Allium offers an Explorer with custom SQL and Datashares into Snowflake, Databricks, BigQuery, or cloud storage (docs checked November 8, 2026).
Formo offers the Explorer (a SQL editor in ClickHouse SQL) and a read-only SQL query API (
POST /v0/query, oneSELECTorWITHstatement per call) on your own analytics data, and a read-only BI connection over a ClickHouse-compatible HTTP interface for tools such as Grafana and Metabase. Scheduled exports to Google Cloud Storage or Amazon S3 are in development and available on request. Formo does not replace your warehouse: CRM and finance data still need their own pipeline.
Should a DeFi protocol build or buy its analytics?
Buy the layers that are the same for every protocol: decoded chain data, product analytics, attribution, and wallet labels. Build the layers that are unique to you: your metric definitions, your revenue model, and your incentive analysis. Building a decoder or an attribution system from scratch rarely pays off before Series B.
Use these criteria to decide:
Buy if many protocols need the same thing, if the vendor keeps it current across chains, and if you can export the raw data.
Build if the logic encodes how your protocol makes money, if a mistake would change a governance vote, or if no vendor models your contracts correctly.
Check exit costs before you buy. Confirm SQL access or scheduled exports, so the data can move to your warehouse later.
Component | Default | Reason |
|---|---|---|
Event decoding and raw chain data | Buy | Commodity work; vendors maintain ABIs and chain coverage |
Web and wallet product analytics | Buy | SDKs, sessions, and attribution are hard to rebuild |
Wallet labels and enrichment | Buy | Needs data from many protocols and attestations |
KPI definitions and revenue model | Build | Specific to your protocol and your token |
Incentive and airdrop analysis | Build on bought data | The questions are yours; the inputs are not |
For a longer comparison, see build vs buy analytics for DeFi.
What should a first data hire do in the first 90 days?
A first data hire should spend the first 30 days on an audit and on metric definitions, the next 30 on one trusted KPI dashboard, and the last 30 on incentive and external reporting. The output at day 90 is a set of definitions, one owned dashboard, and a reporting schedule that the team trusts.
Days 1 to 10: interview the consumers. Meet founders, growth, BD, and governance leads. List the ten questions they ask most often and the decisions behind them.
Days 10 to 20: audit the data. Check the tracking plan against the app and the contracts. List missing events, chains, and deployments.
Days 20 to 30: write metric definitions. Define active wallet, retained wallet, protocol revenue, and incentive cost. Get sign-off from a founder.
Days 30 to 45: fix instrumentation gaps. Work with engineering to add missing events and contract registrations.
Days 45 to 60: ship one KPI dashboard. Use the agreed definitions. Name an owner and a review cadence.
Days 60 to 75: run the first incentive report. Measure how many rewarded wallets stayed active after rewards ended, and the cost per retained wallet. In Formo, set the retention chart's entry event to the reward claim and the retention event to your core action, such as a deposit.
Days 75 to 90: set up external reporting. Create templates for the monthly governance report and the investor update. Document every query behind them.
What reports should a crypto data team deliver?
A crypto data team delivers four recurring reports: an internal KPI dashboard, token and incentive reports, grant and governance reports, and investor updates. Each report needs a named owner, a fixed cadence, and queries that another analyst can rerun. External reports need the strictest review, because token holders can check onchain numbers themselves.
Deliverable | Audience | Cadence | Core metrics |
|---|---|---|---|
KPI dashboard | Team | Daily or weekly | Active wallets, new vs returning, volume, revenue, retention |
Token and incentive report | Tokenomics, DAO | Per epoch or monthly | Emissions, rewarded wallets, retention after rewards, sybil share |
Grant and governance report | Grant committee, delegates | Monthly or per milestone | Milestone metrics, usage from grant-funded features, spend |
Investor update | Investors, board | Monthly or quarterly | Growth, revenue, retention cohorts, runway context |
Use wallet labels for sybil checks in incentive reports. Formo wallet labels include published airdrop sybil lists (LayerZero, Hop, Optimism) and Human Passport scores, which you can use in segments and as a cohort label filter in retention. Published sybil lists are historical snapshots, so treat them as one signal, not a full filter.
What mistakes do crypto data teams make most often?
The most common mistakes are reporting TVL as the headline metric, building dashboards that nobody owns, and paying incentives to unlabeled sybil wallets. Other frequent errors are skipping the tracking plan and writing metric definitions only in SQL, where nobody outside the data team can read them.
Vanity TVL. TVL moves with token prices and with a few large depositors. Report active wallets and retained liquidity next to it. See TVL vs active users.
Dashboards nobody owns. Every dashboard needs an owner and a review date. Delete dashboards that nobody opened last quarter.
Unlabeled sybil wallets. Farmers inflate user counts and drain incentives. Label suspected sybil clusters before you report campaign results. See what are sybil attacks.
No tracking plan. Contract events can be reindexed later. Web sessions that were never recorded cannot.
Careless handling of wallet data. Under the EDPB's Guidelines 02/2025 on blockchain (final version, July 7, 2026), a public key or wallet address is personal data when it can identify a natural person by means reasonably likely to be used. Apply access controls and retention rules to wallet-level tables.
Frequently asked questions
How big should a crypto data team be?
Before launch, a crypto data team is usually zero dedicated people: a founder owns the tracking plan. After TGE or a Series A, one analyst or a fractional lead is typical. From Series B, teams often have a head of data, one or two data engineers, and two to four analysts.
What does a head of data do at a crypto company?
A head of data in crypto owns metric definitions, the data stack, and the reports that leave the company. The role sets priorities for analysts and engineers, decides what to build and what to buy, and signs off on governance, grant, and investor numbers before publication.
Should the first data hire be an analyst or an engineer?
For most DeFi protocols, make your first hire an analyst. Hosted tools cover ingestion and decoding at the early stages. An engineer becomes the right hire when pipelines across chains, deployments, and offchain sources take more time than analysis.
What is a fractional head of data?
A fractional head of data is a senior data lead who works part time for several companies. The role sets strategy, KPIs, and stack design, and often builds the first pipelines and dashboards. It suits protocols that need senior judgment before they can fund a full-time hire.
Which tools does a DeFi data stack need?
A DeFi data stack needs product analytics and attribution, an indexer or pipeline, a warehouse with SQL, a BI layer, and wallet intelligence. Common choices include Dune or Allium for chain data, Goldsky for indexing, dbt for modeling, and a product analytics tool such as Formo for app, wallet, and attribution data.
Why is TVL a vanity metric?
TVL is a vanity metric when it is the only metric. It rises and falls with token prices, and a few large wallets can dominate it. Active wallets, retained liquidity, and revenue per wallet show whether the protocol keeps users after incentives end.
What reports do DAOs and token holders expect?
DAOs and token holders expect regular reports on usage, revenue, treasury spend, and incentive results. Grant committees expect milestone metrics tied to funded work. Publish the queries or the method with each report, because readers can verify onchain figures themselves.


