The Problem Nobody Explains

You've deployed a smart contract. It works. Users can interact with it. But how does your frontend know what's in that contract?

This sounds like a basic question. It's not. The answer reveals infrastructure that most blockchain developers use daily but rarely think about critically.

When your wallet shows a token balance, when your DeFi dashboard displays positions, when your NFT marketplace renders a collection, none of that data comes directly from the blockchain. It can't. Blockchains don't work that way.

Between your application and the blockchain sits an entire infrastructure layer responsible for transforming raw chain state into something your app can actually use. This is the read layer. It's invisible until it breaks, expensive even when it works, and almost universally misunderstood.

Why Blockchains Are Terrible at Answering Questions

Blockchains are optimized for one thing: maintaining consensus about state transitions. They're append-only ledgers designed to record what happened, not to answer questions about what exists.

Here's what that means in practice.

The blockchain doesn't store "balances." It stores every transaction that ever happened. Getting your ETH balance means replaying every transaction that ever touched your address, computing the net effect, and arriving at a number. For ERC-20 tokens, you need to scan the entire history of that token contract, filter for events involving your address, and calculate the current state.

The same problem applies everywhere. Want to know who holds a particular NFT collection? There's no table of "who owns what." You have to process every Transfer event the contract ever emitted, track ownership changes, and build the current state from scratch. Need historical prices? The blockchain records swaps, not prices. To get a price at a specific block, you need to find the relevant liquidity pool contract, pull the reserve states at that block, and calculate the implied price. Multiply this across dozens of DEXs and thousands of pairs.

None of these queries are impossible. They're just computationally brutal. Running them on demand, for every user, for every page load, is a non-starter. Even with a dedicated archive node, query latencies would destroy any reasonable user experience.

This is why indexers exist. They pre-process blockchain data, transform it into queryable structures, and serve it through APIs. The work happens once. Applications benefit forever.

The problem isn't that indexing is necessary. The problem is how the industry built it.

The Read Layer Architecture

Every application that reads blockchain data goes through some version of this pipeline.

First, someone runs a full node or archive node. This node syncs the complete blockchain history, storing every block, every transaction, every log. For Ethereum, this means terabytes of data and growing. For most applications, running your own node is impractical.

Second, someone processes that raw data into structured indices. This means parsing transaction calldata, decoding event logs, tracking token balances and ownership, and organizing everything into queryable tables. This is what indexers do.

Third, applications query those indices through APIs. GraphQL, REST, WebSockets. The format varies, but the dependency doesn't.

At every stage, you're trusting someone else's infrastructure. The node operator. The indexer. The API provider. If any of them goes down, misconfigures, or acts maliciously, your application breaks or worse, serves incorrect data.

Most developers understand this dependency exists. Few have examined who actually provides it.

Who Runs Your Read Layer

For most applications, the answer is a handful of companies. Alchemy. Infura. QuickNode. These centralized providers run the nodes and serve the data. If you're using ethers, viem, or wagmi without specifying your own RPC, you're probably hitting one of these services right now.

For more sophisticated data needs, developers turn to indexing services. Here's where it gets interesting.

A wave of "decentralized" indexing protocols emerged to address the obvious problems with centralized providers. The Graph, SubQuery, Subsquid, and others built networks of independent indexers who stake tokens and earn fees for serving queries. In theory, this eliminates single points of failure and aligns incentives with accuracy.

In practice, these protocols demonstrate everything wrong with how we think about decentralization in blockchain infrastructure.

Economic security is not cryptographic security. When you query a "decentralized" indexer, you're trusting that operators processed data correctly because they have economic incentive to do so. If they cheat, they might get slashed. Maybe. Eventually. After someone notices, proves malfeasance, and executes a governance action. Meanwhile, your application served incorrect data to users.

Anyone who's waited hours for a subgraph to sync, only to discover a mapping error buried in logs, understands that "decentralized" didn't mean "better."

This is the same trust model as centralized finance with extra steps. You're still trusting intermediaries. You just have more of them, and a token to coordinate their behavior.

Compare this to how blockchains themselves work. When a light client verifies a transaction inclusion proof, it doesn't trust that validators behaved honestly. It verifies cryptographically. The proof either validates or it doesn't. There's no economic game theory required.

The read layer should work the same way. It doesn't.

The Trust Gap

Blockchain developers have internalized an uncomfortable trade-off: the write layer is trustless, the read layer requires trust. We've accepted this as a fact of life, like transaction fees or confirmation times. It's just how things work.

But it's not a fundamental constraint. It's an artifact of how the ecosystem developed. Blockchains came first. Applications needed data. Infrastructure providers filled the gap. Nobody stopped to ask whether the gap should exist in the first place.

The consequences of this trust gap compound over time.

When an indexer returns data, there's no way to verify it cryptographically. You can run the same query against multiple providers and compare results, but that only catches inconsistencies. It doesn't prove correctness. The indexer could be consistently wrong, and you'd never know.

Availability compounds the problem. Centralized providers go down. Sometimes for minutes, sometimes for hours. When they do, applications fail. The "decentralized" alternatives fare better on average but still experience outages. More importantly, their economic model creates availability based on profitability. Unpopular chains or datasets get less indexing coverage, regardless of application need.

Access is gatekept in ways that contradict everything blockchains stand for. Want a custom index for your specific use case? Either convince a provider to build it, pay enterprise rates, or run your own infrastructure. The permissionless innovation that blockchains enable for smart contracts doesn't extend to data access. New applications are constrained to the queries that existing infrastructure supports.

And sovereignty? It doesn't exist. Your application's relationship with its data is mediated entirely by third parties. You don't control the infrastructure. You can't verify the output. You're renting access to data that blockchain architecture says should be a public good.

What the Read Layer Should Be

Strip away the implementation details and ask a simpler question: what properties should the read layer have?

Four properties. Verifiability. Trustlessness. Permissionlessness. Sovereignty. Here's why they matter.

Applications should be able to prove that the data they receive accurately reflects blockchain state. Not "trust that it's probably right." Prove it. Cryptographically. This is verifiability, and it's table stakes for any infrastructure that claims to serve blockchain data.

Users shouldn't have to trust that indexers processed data correctly. They should be able to verify it themselves. Economic security through slashing is not trustlessness. It's trust with extra steps. Real trustlessness means cryptographic proofs, not token incentives.

Anyone should be able to access blockchain data without approval from gatekeepers. Public data should be publicly accessible. Custom indices should be deployable by anyone, not just infrastructure providers with enterprise contracts. Permissionlessness isn't optional for infrastructure that serves permissionless networks.

Applications should be able to run their own infrastructure if they choose, without depending on external parties for availability. The option to self-host should be practical, not theoretical. Data sovereignty means you control your relationship with blockchain data, not some API provider.

These aren't aspirational ideals. They're engineering requirements that blockchains already meet for writes. The read layer should meet them too.

Where This Goes Next

The gap between what blockchains promise and what the read layer delivers isn't permanent. It's a function of how the ecosystem developed: blockchains came first, indexing came after as a patch, and we've been living with the architectural compromise ever since.

But there's no technical reason the read layer has to work this way. Validators already process every transaction. They already maintain state. They're already economically secured and geographically distributed. The infrastructure that produces blockchain data is inherently aligned with the network's interests. The infrastructure that reads it doesn't have to be a toll booth.

The question isn't whether a trustless read layer is possible. It's whether the ecosystem will demand one.

At Shinzo, we believe the answer is obvious. We're building the read layer that blockchains should have had from the start. Verifiable data from validators. Peer-to-peer distribution that doesn't depend on any single provider. Cryptographic proofs that eliminate trust, not tokens that incentivize it.

That's a different article. For now, the point is simpler: you have a read layer. You depend on it for everything. You probably haven't thought critically about who provides it, under what terms, and what happens when it fails.

Maybe you should.

Shinzo is building the read layer blockchains should have had from the start. Verifiable. Trustless. Permissionless. From validators to user devices.

Check out our DevNet or join the community.
X · Telegram · Discord · GitHub ·  shinzo.network