On-Chain Analytics: The Token Economy

The data source hiding in plain sight

Every chapter so far has been about analytics under scarcity: no prompts, no user-level trails, no cross-device identity (Chapter 02). So it surprises candidates to learn that the company sits on top of one of the most transparent datasets in existence. The prompts are invisible, but the token economy is fully public and permanent.

The platform's staking token ($TOKEN) is an ERC-20 on an Ethereum L2. Everything that touches that contract and the tokenized-compute credit ($CREDIT) / staking contracts is queryable by anyone, forever:

• Every transfer — sender, receiver, amount, block, timestamp
• Every stake / unstake and the resulting staked-token receipt (sTOKEN) positions
• Every mint / burn — including the emissions schedule and the revenue-funded buy-and-burn
• Every holder balance and how concentration shifts over time
• Every treasury flow in and out of known company/foundation addresses
• Every compute-credit lock/mint and burn — the API-credit layer

Tools

You don't build a blockchain indexer as a first hire. You use the ecosystem's ready-made SQL layers and pull what you need into your own warehouse for governed joins (the same consolidate-into-the-warehouse logic from Chapter 03).

For orientation, the community typically already runs public reference dashboards — worth reading before you build, both to avoid reinventing them and to sanity-check your own numbers against a public source. (Treat any third-party dashboard's methodology as unverified until you reproduce it.)

The analyses you'd run

Three families of analysis, each answering a real business question. Note that every one of these is a cohort or aggregate — none requires knowing who a wallet is.

1. Holder segmentation

• Balance buckets — whale vs retail distribution; how many addresses hold >1% of supply
• Concentration / Gini — is ownership decentralizing or consolidating over time? (A treasury partly denominated in $TOKEN matters here.)
• New vs churned holders — first-seen and last-active addresses as a token-holder retention proxy

2. Staking behavior

• Stake / unstake flows — net staking as a demand signal; spikes around emissions changes or price moves
• Lock duration & sTOKEN → $CREDIT conversion — how much staked $TOKEN is being locked to mint the compute credit (recall 1 credit = $1/day of API credit in perpetuity)
• Utilization-driven emissions & compute-credit burn — compute credit burned is a proxy for actual API demand being consumed, distinct from capacity merely reserved

3. Treasury & burn tracking

• Emissions vs buy-and-burn — net supply change; is the revenue-funded burn outpacing inflation yet?
• Treasury flows — movements from known company/foundation addresses, for a public read on runway posture

An illustrative Dune-style query — decoded-table SQL over transfers to build balances and balance-bucket segmentation. (Exact table/column names differ by decode; treat this as the shape, not a copy-paste.)

-- Illustrative Dune-style query on decoded $TOKEN transfers (an Ethereum L2).
-- Reconstructs current balances, then segments by balance bucket.
-- Cohorts only -- no attempt to identify who any wallet belongs to.
with transfers as (
    select "to"   as wallet,  value as amt from erc20_l2.evt_Transfer
      where contract_address = {{token_contract}}
    union all
    select "from" as wallet, -value as amt from erc20_l2.evt_Transfer
      where contract_address = {{token_contract}}
),
balances as (
    select wallet, sum(amt) / 1e18 as token_balance   -- 18 decimals
    from transfers
    group by wallet
    having sum(amt) / 1e18 > 0                         -- current holders only
),
segmented as (
    select
        case
            when token_balance >= 1000000 then '1_whale_1M+'
            when token_balance >=  100000 then '2_large_100k+'
            when token_balance >=   10000 then '3_mid_10k+'
            when token_balance >=    1000 then '4_retail_1k+'
            else                              '5_dust_<1k'
        end as holder_segment,
        token_balance
    from balances
)
select
    holder_segment,
    count(*)                                       as wallets,
    round(sum(token_balance))                      as token_held,
    round(100.0 * sum(token_balance)
          / sum(sum(token_balance)) over (), 2)    as pct_of_circulating
from segmented
group by holder_segment
order by holder_segment;

Tying tokens to the business — the consented-linkage rule

This is the nuanced, senior part, and it's where a thoughtful candidate separates from a clever one. On-chain data is pseudonymous, not anonymous — a wallet is a stable identifier, and the entire chain-analysis industry exists to cluster wallets back to real people. The whole point of the company is to not do that. So the rule has to be explicit.

Concretely, that gives you two lanes:

• Consented lane. Users who connected a wallet to redeem staked-API access have opted into a wallet↔account mapping. You can join that mapping to billing/usage the way you'd join any first-party identifier — with purpose limits and the usual controls.
• Cohort lane (default). For everyone else, stay at the aggregate: "wallets that stake ≥ X consume Y% more compute credit in aggregate than non-stakers," never "wallet 0xabc… is user 12345."

What token metrics tell the business

On-chain metrics aren't a crypto sideshow — mapped correctly, they're leading indicators for the core business (this extends the token-metrics section of Chapter 04).

Why this makes you stand out

Here's the honest competitive read. Most data-science candidates walking into this loop will treat the company like any other freemium SaaS: they'll talk Stripe funnels, PostHog events, and A/B tests. Strong ones will nail the privacy reframe from Chapter 02. But very few will walk in already thinking of the token economy as a first-party analytics asset — a public, permanent, individual-grain dataset that the company itself generates and that speaks directly to committed demand, retention, and unit economics.

Demonstrating that you can mine it — and, in the same breath, that you'd refuse to de-anonymize wallets even though you technically could — hits both halves of what this company screens for at once: technical range and genuine alignment with the privacy-first thesis. For a crypto-native, privacy-first company making its first serious data hire, that combination is close to the exact profile they're hoping walks through the door.