I just wanted to check whether a DeFi project had quietly rug‑pulled its liquidity.
I opened one of the big on‑chain analytics platforms. The answer was technically there… but behind a paywall: pay hundreds of dollars per month for “serious” access, or stay blind.
Paying enterprise prices just to ask a simple question like “did this pool lose liquidity last week?” felt wrong.
So I did what developers do when the tools don’t fit:
I built a $0 alternative.
What started as a script turned into a question that keeps bothering me:
if writing to a public blockchain is cheap and permissionless, why is reading it properly expensive and gated?
The Hidden Centralization of “Reading” Blockchains
On paper, blockchains are open: every transaction, every event, every state transition is public.
In practice, most people never touch that raw data. They rent visibility from a small set of data platforms.
Today, “reading the chain” usually means one of three things:
- You query a centralized RPC provider
- You rely on an analytics platform dashboard
- You consume someone else’s indexed data/API
If those providers go down, change their pricing, throttle your keys, or simply decide you’re not a “priority customer”, your ability to see the chain degrades overnight.
The base layer may be decentralized, but your window into it is not.
When Reading Costs Hundreds per Month
Serious access to blockchain data is not cheap.
If you want:
- High‑rate historical queries
- Rich decoded traces and logs
- Advanced analytics and labels
…you quickly run into Pro and Enterprise pricing tiers from analytics providers and data platforms, often in the hundreds of dollars per month.
Even RPC providers, while offering generous free tiers, start to meter you the moment you try to do anything non‑trivial at scale: indexing events, scanning long histories, or powering products for many users.
For a solo researcher, an independent dev, or a small community trying to hold projects accountable, that cost is not a rounding error.
It’s a hard wall between “I can verify this myself” and “I guess I’ll just trust someone’s screenshot.”
This is upside‑down.
We built trustless consensus for writing blocks, then recreated paywalled middlemen for reading them.
The Trust Gap: Dashboards vs Verification
There’s also a deeper issue than cost: trust.
When you ask:
- “Did this protocol’s TVL collapse last week?”
- “Did this address really dump all its tokens?”
- “Did this pool stop receiving deposits?”
…you typically don’t verify the answer yourself.
You trust a dashboard, a chart, or a tweet with a chart embedded in it.
This breaks the original blockchain promise:
Don’t trust. Verify.
Today, reading the chain often means:
“Don’t verify. Subscribe.”
We decentralized block production, then built a highly centralized, subscription‑based layer for interpretation.
This isn’t just a UX smell; it’s a governance and power problem.
Reframing the Problem: From Data Fetching to Behavior Verification
The root assumption behind most data tooling is:
“To understand what happened, fetch lots of raw data, then analyze it.”
That leads naturally to:
- Full nodes
- Heavy indexers
- Complex pipelines and warehouses
But what if “reading the blockchain” didn’t mean fetching everything?
What if it meant something tighter: verifying that a specific behavior happened (or didn’t) in a given block range?
Instead of asking:
“Give me all events and traces for this block and I’ll figure it out.”
You ask:
“Can you prove that this specific behavior occurred in this block?”
This is the mental shift behind SODS.
SODS: Reading as Verifying Behaviors
SODS (the model I’m experimenting with) treats behaviors as first‑class citizens.
It doesn’t try to be an indexer, a data warehouse, or a dashboard engine.
In SODS, the flow is:
-
You define a behavior you care about
- “A WETH deposit occurred in this block”
- “An ERC‑20 Transfer from X to Y happened”
- “Liquidity in this pool decreased by more than N between two blocks”
-
A proving component scans the raw chain data and produces a tiny proof for that behavior
- The proof is not a CSV, not a JSON blob, not a screenshot
- It is a short, verifiable object linked to the underlying block data
-
You (or your app) verify that proof locally
- No heavy full node
- No massive index
- No monthly subscription
Reading becomes equivalent to verifying a small proof instead of renting access to a data firehose.
It is closer in spirit to SPV (Simple Payment Verification) than to analytics dashboards: lightweight, focused, and verifiable by end users.
A Concrete PoC: 3 Behaviors, 202‑Byte Proofs, $0
To test this idea, I built a proof‑of‑concept on a testnet block.
The experiment:
- Take a single Ethereum‑style block on Sepolia
- Look only at 23 on‑chain events in that block
- From those events, extract 3 behavior types:
- Tf = ERC‑20 Transfer
- Dep = WETH Deposit
- Wdw = WETH Withdraw
Instead of treating all 23 events as equal, I compress them into a Behavioral Merkle Tree (BMT):
- Leaves represent behaviors (Tf, Dep, Wdw) anchored to the underlying events
- The tree commits to which behaviors occurred in that block
- The root becomes a compact behavioral commitment for the entire block
From there, for each behavior, I generate a proof:
- Each proof is 202 bytes in size
- Each proof can be verified locally in under a millisecond
- The block’s raw data still lives on the chain / node, but consumers don’t need to download it
On the cost side:
- Building the tree and proofs takes roughly a second on a normal laptop
- Verifying a proof is effectively instant for a user
- The entire process uses a small number of RPC calls, easily fitting free tiers from standard providers — i.e. $0 in practice for this scale.
The important part is not the exact numbers, but the shape of the trade‑off:
- Instead of paying hundreds of dollars monthly for broad analytics access,
- You can produce and verify tiny, behavior‑specific proofs on demand.
What you get is not a pretty chart, but a primitive:
a way to say “this behavior did happen in this block” and independently check that statement.
Why This Matters Beyond One Script
On the surface, this PoC is just another “dev built a cool script.”
But the principle scales.
If behaviors can be:
- Clearly specified
- Efficiently committed to
- Cheaply proven
- Locally verified
…then a whole ecosystem of tools can emerge that:
- Let users verify claims about on‑chain behavior without trusting dashboards
- Let communities audit protocols cheaply
- Let wallets and frontends provide “verified behavior” badges without running massive indexers
You don’t have to own a data center or sign a huge SaaS contract to meaningfully read the chain.
You just need access to proofs and a verifier.
This restores symmetry:
- Writing: anyone can send a transaction with a small fee
- Reading: anyone can verify behaviors with small proofs
From Engineering Detail to Ethical Question
Zoom out for a moment.
If block production is decentralized, but meaningful block reading is reserved for:
- Funds that can pay for top‑tier analytics
- Teams that can afford large indexers
- Platforms that monetize visibility
…then the transparency story is weaker than it looks.
We have, in effect, created a private market for public data.
The chain is “open”, but the practical ability to interpret it at scale belongs to whoever can pay.
Models like SODS are one attempt to push back: to make verification cheap and accessible, not only storage and consensus.
So here’s the question this project forced me to ask — and the one I want to leave you with:
If block production is decentralized, but meaningful block reading is gated behind expensive platforms and metered APIs,
did we really build a public blockchain — or just a private data market on top of it?Should reading the blockchain be a privilege for the rich — or a right for everyone?
If you work on light clients, data tooling, or care about on‑chain accountability, feedback on this model — and on turning this PoC into something reusable — is very welcome.
*"If this resonates:
Try the PoC on GitHub: https://github.com/logiccrafterdz/SODS-Protocol
Comment below: What’s the first behavior you’d want to verify?
Top comments (0)