The industry spent the last five years solving a problem it already solved. Billions of dollars poured into cross-chain messaging protocols. IBC, LayerZero, Wormhole, Axelar, Hyperlane. Engineers built sophisticated systems for passing messages between chains, verifying state across trust boundaries, and enabling assets to flow freely through a multi-chain ecosystem.

And it worked.

Cross-chain communication is a solved problem. Maybe not perfectly, and the security models vary widely, but the fundamental capability exists. You can send a message from Ethereum to BNB Chain. You can bridge assets from Solana to Avalanche. You can trigger contract execution on one chain based on state changes on another.

So why does building a multi-chain application still feel like stitching together five different products from five different decades?

The answer is embarrassingly simple: blockchains learned to talk to each other, but the infrastructure we use to read blockchain data never bothered trying.

The Asymmetry Nobody Talks About

Consider what happens when you want to write data across chains. LayerZero routes your message through decentralized verifier networks. IBC uses light client proofs to cryptographically verify state transitions. Hyperlane lets you deploy your own security model. These protocols share a common architecture: they don't trust intermediaries. They verify everything cryptographically, or they make trust assumptions explicit and accountable.

Now consider what happens when you want to read data across chains.

You call a different API for each chain. Maybe you're using a hosted subgraph for Ethereum, a different indexer's REST API for Solana, and something proprietary for BNB Chain. Each one has its own data format. Each one has its own query language. Each one has its own rate limits, uptime guarantees, and failure modes. And critically, each one requires you to trust that the data you're receiving is accurate.

There's no verification. No cryptographic proofs. No cross-chain composability. Just a collection of siloed services that happen to index different blockchains.

This asymmetry is architecturally absurd. We built trustless bridges for the write side and trusted APIs for the read side. We created permissionless infrastructure for moving value and gatekept infrastructure for accessing information.

How Cross-Chain Actually Works

Before examining what's broken, it's worth understanding what's working.

IBC (Inter-Blockchain Communication) started as the protocol connecting Cosmos chains, but it's grown far beyond that origin. IBC Eureka (v2), launched in March 2025, brought native Ethereum support. Solana is now connected via Picasso Network's implementation. Polkadot and Kusama have IBC bridges through Composable Finance. The Interchain Foundation is actively building connections to Base, Arbitrum, and other L2s.

The architecture is elegant: chains run light clients of other chains they want to communicate with. Relayers watch for packets on one chain and submit them to the destination along with cryptographic proofs. The destination chain verifies the proof against its light client and processes the message. No trusted third party required. The Ethereum Foundation has supported this work, recognizing IBC's potential as the TCP/IP for blockchains.

Avalanche Interchain Messaging (ICM), built on Avalanche Warp Messaging (AWM), takes a different approach optimized for the Avalanche ecosystem. Every validator on Avalanche holds a BLS key pair. When messages need to pass between Avalanche L1s (formerly called Subnets), validators collectively sign with BLS multi-signatures that can be verified by any other L1. Because all validators must validate the P-Chain, they can access stake weights and public keys of any other L1 at any time. No periodic syncing of validator sets required. Teleporter abstracts this complexity for EVM developers, making cross-L1 contract calls as simple as single-chain interactions.

LayerZero takes a modular approach. Instead of light clients on every chain, it uses configurable combinations of oracles and relayers that must independently agree on message validity. Applications can choose their own security parameters based on their trust assumptions.

Hyperlane makes interoperability pluggable. Chains deploy Hyperlane contracts, validators attest to messages, and applications select from different security modules. Want optimistic verification with fraud proofs? Available. Prefer a staked validator set? Also available.

These protocols have different security models and tradeoffs. But they share something important: they treat cross-chain communication as a solved problem at the protocol layer. IBC alone now connects 115+ chains across Cosmos, Ethereum, Solana, and Polkadot ecosystems.

The Verification Gap

IBC deserves closer attention because it demonstrates what proper cross-chain infrastructure looks like. When you send an IBC packet from one chain to another, here's what actually happens:

The sending chain commits the packet to its state. A relayer observes this commitment and generates a Merkle proof of inclusion. The receiving chain's light client verifies this proof against the sending chain's consensus state. Only after cryptographic verification does the receiving chain process the packet.

At no point does either chain trust the relayer. The relayer is just a messenger. It cannot forge packets because it cannot forge proofs. It cannot censor packets because anyone can run a relayer. The security model derives entirely from the underlying chains' consensus mechanisms.

LayerZero achieves something similar with a different architecture. Avalanche ICM uses BLS multi-signatures against validator sets recorded on the P-Chain. The implementations differ, but they share a commitment to explicit security models and verifiable state transitions.

Now ask yourself: which indexer verifies the data it serves you?

Not "validates" in the sense of checking format. Verifies. Cryptographically proves that the data accurately reflects blockchain state. Provides Merkle proofs you can check. Gives you any mechanism whatsoever to confirm you're not receiving garbage.

The answer, for virtually every indexer in production today, is none of them.

The Developer Experience Nobody Deserves

Let's make this concrete. You're building a DeFi dashboard that aggregates user positions across Ethereum, Solana, BNB Chain, and an Avalanche L1. Reasonable scope. Different ecosystems, but that's the point of cross-chain. Should be manageable.

Here's your reality:

Different providers for different chains. Your Ethereum data comes from one indexer. Solana requires a completely different provider with a different data model. BNB Chain has its own indexing ecosystem. Avalanche L1s might not have reliable indexing at all. Each chain is a separate relationship, separate billing, separate documentation, and often entirely separate technology stacks.

Incompatible data formats. A token transfer on Ethereum looks nothing like a token transfer on Solana, which looks nothing like a token transfer on BNB Chain. You're not just normalizing field names. You're translating between fundamentally different data models, account structures, and transaction formats.

No unified query interface. Want to ask "show me all positions for this address across these four chains"? That's four separate API calls to four different providers with four different query languages, four separate response handlers, four separate error states to manage. You're building the aggregation layer yourself because no one else has.

Different latency and reliability characteristics. Your Ethereum indexer updates every 12 seconds with high reliability. Your Solana indexer might be faster but structured completely differently. When one provider has an outage, that portion of your dashboard breaks silently.

You spend engineering cycles handling these differences. Normalizing token decimal representations. Reconciling timestamp formats. Mapping similar concepts that got different names in different schemas. None of this work adds value to your product. It's pure integration overhead.

"Multi-Chain Support" Is Marketing

Indexer providers know this is a problem. Their response has been to add "multi-chain support" to their feature lists. Look closer at what that means.

Most multi-chain offerings are just multiple single-chain products bundled together. You get access to Ethereum indexing and Solana indexing and BNB Chain indexing through one account and one billing relationship. That's operationally convenient. It doesn't solve the underlying fragmentation.

The APIs are still chain-specific. The data formats are still inconsistent. The infrastructure is still separate backends stitched together at the sales layer, not the technical layer. You're not getting a unified view of cross-chain state. You're getting a bundle discount on fragmented infrastructure.

Some providers offer "unified APIs" that abstract chain differences. These help with the normalization problem but create new ones. The abstraction is opinionated. It might not expose chain-specific features you need. When something breaks, you're debugging through an abstraction layer that hides what's actually happening. And you still can't verify that the unified response accurately reflects state across all the chains it claims to represent.

The honest version of "multi-chain support" is: we run indexers on multiple chains and you can query them through one account. The marketed version implies a level of integration and unification that doesn't exist.

The Decentralization Theater

Some projects claim to have solved this with decentralized indexing. The pitch is appealing: instead of trusting a single indexer, you trust a network of indexers with economic incentives to provide accurate data.

Look closer and the problems become obvious.

These networks still operate chain by chain. Want Ethereum data? Query the Ethereum indexers. Want Solana data? Query the Solana indexers. There's no unified data layer. There's no cross-chain composability. There's no way to atomically query data across chains. You've decentralized the individual silos without addressing the siloing itself.

The trust model deserves scrutiny too. Economic security is not cryptographic security. Slashing conditions punish indexers who get caught providing bad data, but catching them requires comparing against a source of truth. If all indexers in a network agree on incorrect data, the slashing mechanism does nothing. You're trusting that at least one honest indexer exists and that someone bothers to check.

Compare this to how cross-chain bridges work. You don't need to trust that bridge operators are honest. You verify their claims cryptographically. The security derives from mathematics, not game theory layered on top of assumptions about rational economic actors.

This isn't to say economic security is worthless. It's a meaningful improvement over pure trust. But calling it "decentralized" while the fundamental architecture remains siloed chains with siloed indexers is overstating the solution.

The Open Web Gets Walled

Blockchains were supposed to create open, permissionless infrastructure. The data is public. Anyone can run a node. Anyone can read any transaction ever made on the network. This openness is the foundation of everything we're trying to build.

But openness at the protocol layer doesn't mean much if the practical infrastructure for accessing that data is fragmented, siloed, and gatekept. An API that can be rate-limited is not permissionless. A data format that requires specialized integration is not composable. A service that can go offline is not reliable.

When data access is fragmented across chain-specific providers, developers build chain-specific applications. The cognitive and operational overhead of true cross-chain development pushes teams toward picking one chain and staying there. Users end up siloed on whatever chain their applications chose. The network effects that were supposed to span the entire ecosystem get locked into individual chains.

The indexer oligopoly doesn't just extract rent from developers. It shapes what gets built. It constrains what's architecturally feasible. It turns the open web into a collection of loosely connected walled gardens, each with its own data gatekeepers.

Blockchains built the roads between cities. Indexers put up toll booths at every exit.

The Path Forward

The architecture exists to solve this problem. Validators already process every transaction. They already maintain complete state. Embedding indexing directly within validator infrastructure eliminates the need for external parties to reconstruct what validators already know.

Content-addressable storage enables cryptographic verification of indexed data. Merkle proofs can demonstrate that indexed state accurately reflects blockchain state without requiring trust in the indexer. Recursive proofs can verify entire histories of state transitions in constant time.

Peer-to-peer distribution removes central points of control. Data flows through networks, not gatekeepers. No single party can restrict access, impose rate limits, or decide which data is worth serving.

And critically, a unified data model across chains eliminates integration overhead. Same queries. Same formats. Same verification mechanisms. Whether the underlying data comes from Ethereum or Solana or BNB Chain, the access patterns remain consistent.

This isn't theoretical. At Shinzo, we're building exactly this infrastructure. Validator-native indexing with DefraDB for verifiable, peer-to-peer data distribution. LensVM for flexible data transformations that maintain cryptographic integrity. A unified read layer that treats all blockchain data as a single, queryable, trustless dataset.

The write side figured this out years ago. It's time the read side caught up.

Shinzo is building unified data infrastructure for the multi-chain future. If you're tired of stitching together chain-specific indexers, come build with us: X · Telegram · Discord · GitHub