Chapter 23 · Using On-Chain Data to Observe Reality

A Real-World Problem

You have three reports about one protocol.

Its quarterly report claims $24 million in revenue. An independent researcher reports $9 million for the same quarter. A social-media spreadsheet reports an $18 million net loss.

Same protocol and period, dramatically different numbers and signs.

You suspect dishonesty. But investigation reveals every figure can be matched to actual on-chain transactions.

They answer different questions:

• Total fees paid by users.
• The share retained by the protocol.
• Net income after token incentives.

All can be correct because nobody defined revenue.

Data is public; definitions are private.

Public transactions are a powerful advantage, but raw facts are not conclusions. Which transactions you include determines the result.

Reports often omit that choice.

This chapter teaches how to start from raw facts and produce a number you can defend.

It is among Part A's most practical chapters and central to capstone research.

Thought Experiment

Consider a coffee shop rather than a blockchain.

It sells through a delivery platform. Last month's accounts:

• Customers paid one million.
• The platform retained 20%, or 200,000.
• The shop issued 150,000 in vouchers for acquisition.
• It printed vouchers at almost no cost.

What was its revenue?

Five defensible answers:

A  1,000,000  Total customer payments
B    800,000  Receipts after platform fees
C    650,000  Less voucher face value
D    800,000  Self-printed vouchers involved no cash outflow
E    650,000  Future coffee redemption creates real costs

Do vouchers count as a cost?

Cash accounting this month might exclude them; longer-term obligations include them.

Protocol-token incentives pose the same question. No cash leaves immediately, but issuance dilutes holders. Inclusion depends on the question.

Two more distinctions.

Money held is not money earned.

A safe contains five million, of which 4.8 million is prepaid customer balances, withdrawable anytime. The impressive balance belongs mostly to customers.

An on-chain metric measures this safe, often cited as protocol scale despite representing others' deposits.

Visitor counts also need definition.

There were 6,000 visits, including 4,500 voucher collections without full-price purchases. The remaining 1,500 visits came from 300 people visiting five times.

The headline might mean 6,000 visits, 1,800 unique people, 300 repeat customers, or 1,500 genuine purchases. All describe different things.

Replace customers with addresses and the same issues appear. On-chain records let you count directly.

Your Decision

You want last month's protocol earnings. Where do you begin?

What Happens

The options agree:

Definition is harder than extraction.

A correct query can retrieve 90 days in seconds. Six choices require the real work:

Any changed answer changes the number, yet many reports disclose none.

One protocol can legitimately produce:

Assign every number to a row before using it.

Also identify circulating capitalization versus FDV whenever citing valuation. Chapter 19 showed they can differ tenfold; unidentified defaults invalidate comparisons.

Build a Model

Six steps, each with a deliverable:

The steps in detail:

Cross-checking means explaining disagreement, beyond finding agreement.

A 3% gap may reflect boundaries; 40% likely reflects scope. Finding that difference reveals protocol structure. Discrepancies are information.

Honest uncertainty might include missing chains, price-sensitive incentive valuation, or unresolved address ownership. This separates research from promotion.

Analysis that states its blind spots is more credible than apparently flawless analysis.

Keep this metric table for capstone work:

What It Is Called

Hands-on

Addresses: main contract 0x… verified on-chain, mainnet only;
           missing other chains appears in the uncertainty list
Events: Swap / Borrow / …; failed transactions excluded
Gross/net: protocol share = total fees × protocol allocation ratio
           cite parameter name and current value
Incentives: excluded from revenue here, plotted separately as spending
Time: UTC calendar days, most recent 90 complete days
Deduplication: from address; no person-level merging, stated as a limitation

select
  date_trunc('day', block_time) as day,
  sum(fee_amount_usd)           as fees_usd,
  count(*)                      as tx_count
from <platform_event_table>
where contract_address = <verified_contract_address>
  and block_time >= now() - interval '90' day
group by 1
order by 1

select
  date_trunc('day', block_time)  as day,
  count(distinct tx_from)        as active_addresses
from <platform_event_table>
where contract_address = <contract_address>
  and block_time >= now() - interval '90' day
group by 1
order by 1

AI Lab

I need protocol revenue and daily active addresses over 90 days.

First define scope, before writing SQL:
1. Contracts by chain
2. Events and failed-transaction handling
3. Gross user fees or protocol net share, and allocation parameters
4. Incentive costs and conversion price
5. Time boundaries
6. Address deduplication and aggregators

Then write a query with actual table and field names.
Finally list uncovered activity and possible under/overestimates.

Cite every address, parameter, and event.
Mark uncertainty "requires manual verification" rather than invent values.

Real-World Case

Change One Variable

Takeaway Questions

Chapter Check