Your smart contracts are trustless. Your consensus is trustless. Your data access routes through three companies, and if any of them have a bad day, your application goes down.

This is the state of Web3 infrastructure. Developers build on blockchains specifically to remove trusted intermediaries, then plug their entire data stack into services that require complete trust. When Alchemy has an outage, half the ecosystem feels it. When Infura rate limits you, your users see loading spinners. When any of these providers decides to change their terms, deprecate an endpoint, or exit a market, you scramble to migrate.

The base layer solved trustlessness years ago. The data layer still hasn't caught up.

Centralized infrastructure with decentralized branding

Most developers don't think of their indexer as a single point of failure. It's just an API. You call it, it returns data, everything works. The dependency feels lightweight until it isn't.

But trace the actual architecture. Your frontend calls an indexer. That indexer runs its own nodes, maintains its own databases, operates its own caching layer. Every query flows through infrastructure controlled by a single entity. If their systems go down, your application stops working. If they serve bad data, your application serves bad data. If they decide they don't want your traffic, you're gone.

This isn't a distributed system. It's a client-server architecture where the server happens to read from a blockchain. The trustlessness of the underlying chain doesn't propagate up to your application. It terminates at the RPC layer and everything above it runs on trust.

The "decentralized" indexers haven't fixed this. They've added a marketplace layer on top, coordinated by a blockchain, where indexers stake tokens and developers choose who to query. But the actual indexing isn't distributed. Each indexer still runs their own infrastructure, serves their own data, and requires your trust individually. The blockchain coordinates economics and disputes. It doesn't make the data itself trustless.

So how do you pick an indexer? Social signals. Reputation. Token stake as a proxy for reliability. You're reading tea leaves to decide who to trust with your data pipeline. That's not trustlessness. That's trust with extra steps and a token attached.

Censorship resistance has a gap

Blockchains are built so that no single party can prevent valid activity. A miner or validator can refuse to include your transaction, but another one will. The network routes around obstruction. Censorship resistance is a design property, not a promise from any operator.

Data access has no equivalent guarantee.

An indexer can refuse to serve your queries. They can omit specific data from their indexes. They can throttle your access, deprioritize certain query patterns, or block entire applications. You might not even notice if the censorship is subtle. Missing data looks the same as data that never existed.

There's no protocol-level guarantee that you can access indexed blockchain data. There's no mechanism to route around an uncooperative provider. If your indexer doesn't want to serve you, your options are to find another indexer and hope you can trust them, or run your own infrastructure. Neither option preserves trustlessness. You've just moved the trust somewhere else, or moved the operational burden onto yourself.

This gap matters more than most developers acknowledge. Censorship at the data layer is quieter than censorship at the consensus layer. There's no public mempool where blocked queries are visible. There's no block explorer showing which data requests got denied. An indexer can shape what applications see without anyone outside the company knowing.

What trustlessness actually requires

Trustlessness isn't about finding a provider you trust more. It's about removing the need for trust entirely.

A trustless data layer means no query depends on any single operator's cooperation. If one provider goes down, others serve the same data. If one provider censors, alternatives exist that can't be pressured the same way. The system continues functioning correctly not because operators are honest, but because the architecture doesn't give any operator enough power to break it.

This requires a few things that current infrastructure doesn't provide.

No single point of failure for queries. Data has to be available from multiple independent sources, and your application needs to be able to reach any of them. Redundancy at the node level isn't enough if queries still route through a single gateway.

No privileged access. Every participant should be able to access the same data. If some operators have access that others lack, trust concentrates with those operators. Trustlessness means the data layer is as open as the blockchain itself.

Availability guarantees that don't depend on business relationships. Your access to indexed data shouldn't be contingent on a contract, a pricing tier, or staying in good standing with a provider. The blockchain doesn't care who you are when you submit a transaction. The data layer shouldn't care who you are when you query state.

Resistance to coordinated failure. If the major indexing providers all go down simultaneously, whether through technical failure, regulatory pressure, or coordinated attack, applications should still function. This is only possible if the indexing layer is genuinely distributed across independent, diverse operators who don't share common chokepoints.

The technical foundation for trustless data access

Removing trust assumptions requires architectural choices that most indexing infrastructure never made. Trustlessness has to be designed in from the start, not retrofitted.

Peer-to-peer networking where every node is equivalent. No server/client hierarchy, no privileged coordinators, no gateways that all queries must pass through. Any node that has the data can serve it. When nodes are equivalent, there's no chokepoint to attack and no single operator whose cooperation you require.

Content-addressable data that can be requested by what it is, not where it lives. You ask the network for data matching a specific identifier, and any node that has it can respond. This decouples data availability from any particular operator's infrastructure. If one node goes offline, others serve the same content. The network routes around failure by design.

Collaborative databases where multiple independent parties maintain shared datasets without any single party having control. Not a consortium with a membership list. An open system where participants who don't know or trust each other can contribute to and query from a common data layer. Cryptographic mechanisms enforce integrity so you don't have to trust that other participants are behaving honestly.

Access control through cryptography, not business relationships. Public key identity and decentralized identifiers replace API keys and account tiers. Your ability to query data depends on cryptographic credentials, not whether you've signed a terms of service or paid an invoice. The protocol doesn't know or care who you are. It verifies your keys.

Schema flexibility without central coordination. In a trustless system, you can't require all participants to update their schemas simultaneously or route changes through a central registry. Nodes running different software versions need to communicate and sync without tight coordination. Bidirectional data transformation at the edge lets heterogeneous nodes interoperate, removing another potential point of central control.

These aren't hypothetical capabilities. They're established patterns from systems designed for adversarial environments where you can't assume participants will cooperate or stay online. The blockchain ecosystem already runs on these primitives at the consensus layer. The gap is applying them to data access.

The cost of trust dependencies

Every trust dependency in your stack is a liability. Most developers don't inventory them until something breaks.

Operational risk concentrates in ways that aren't obvious. Your application might use three different services, but if they all depend on the same underlying indexing provider, you have one point of failure, not three. The supply chain for blockchain data is more consolidated than it appears.

Business risk follows the same pattern. Pricing changes, terms of service updates, API deprecations. Any provider can alter the economics or availability of their service whenever they want. If your application can't function without them, you're exposed to decisions made in their boardroom.

Regulatory risk hits the data layer harder than the base layer. Indexing providers are companies with offices, employees, and legal obligations. They can be pressured in ways that pseudonymous validators cannot. If a regulator wants to restrict access to certain blockchain data, the indexing layer is the obvious chokepoint. Trustless infrastructure doesn't have a throat to choke.

Reputational risk transfers to your application. When your indexer fails, your users don't blame the indexer. They blame you. Your application's reliability is capped by the reliability of your least reliable trust dependency.

Trust isn't a spectrum

It's tempting to think about trust as a dial you can turn. Trust one big company, or trust a smaller consortium, or trust a larger network. Each step feels like progress toward trustlessness.

But trustlessness isn't incremental. Either your system works correctly without requiring trust in any specific party, or it doesn't. A system that requires trusting five companies instead of one is more resilient, but it's not trustless. The threshold is binary: can a colluding minority, or any single point of coordination, break your data access?

Current indexing infrastructure fails that test. It fails at a small number of chokepoints. The question isn't whether those chokepoints are reliable today. It's whether your application should have chokepoints at all.

What changes

Trustless data access changes what applications can credibly promise.

Uptime becomes a function of the network, not any provider. If your data layer genuinely has no single point of failure, your application inherits the availability properties of a distributed system. Individual operators can fail without users noticing.

Censorship resistance extends through the full stack. If no party can selectively deny data access, applications can make the same guarantees to users that blockchains make to transaction submitters. You can't be silenced by pressuring a service provider.

Vendor lock-in disappears. If any conforming node can serve your queries, switching costs drop to zero. You're not dependent on any provider's continued existence or goodwill. Competition becomes real because users can leave without friction.

Applications become auditable end-to-end. When your data layer is trustless, you can demonstrate to users exactly what trust assumptions remain. For many applications, the honest answer today is "you have to trust our indexer." Trustless infrastructure lets that answer become "none."

The gap is closable

The base layer proved that trustless infrastructure works. Blockchains operate with thousands of independent validators, no central coordination, and no single party that can halt the network or corrupt its state. This isn't theoretical. It runs in production, at scale, handling billions in value.

The data layer can work the same way. Indexing can be distributed across independent operators with no coordination point. Query routing can be resilient to individual failures. Data availability can be guaranteed by protocol design, not provider promises.

The primitives exist. The question is whether developers start demanding infrastructure that uses them, or keep accepting trust dependencies as the cost of convenience.

Convenience is nice. But if you wanted convenience over trustlessness, you wouldn't be building on blockchains in the first place.

Join the community building the read layer that eliminates trust assumptions.
X · Telegram · Discord · GitHub ·  shinzo.network