Multi-Chain Apps & the Importance of Stateless Clients (5 of 9)

Target audience: Intermediate

TL;DR

• Multi-chain is no longer an edge case. Most serious applications — and nearly every wallet — interact with assets on multiple chains simultaneously.
• The standard solution — one trusted RPC provider per chain — multiplies the attack surface with every chain added.
• Stateless clients break this pattern: they verify data locally using cryptographic proofs, regardless of which chain the data comes from.
• colibri.stateless currently supports Ethereum (production), Gnosis, Optimism, and Base — with one client, one verification model, no persistent state.
• vRPC is the natural evolution of RPC — delivering data and proofs together from a single endpoint. It should become the new standard.

1. Introduction

In Part 3 of this series, we introduced stateless clients: what they are, why they don’t need to store block headers, and how cryptographic proofs replace trust. In Part 4, we looked at Layer-2 solutions and the specific challenges they introduce for client verification.

This article takes a step back and asks a broader question: what happens when an application doesn’t live on one chain — but on many?

That question is no longer hypothetical. Today, your wallet holds ETH on Ethereum mainnet, USDC bridged to Base, and a small position on Gnosis Chain. A DeFi protocol splits liquidity across Optimism and Arbitrum. An NFT platform tracks provenance on Ethereum while handling payments on a cheaper L2. The multi-chain reality is here.

The infrastructure responding to it, however, is largely still built around a single-chain assumption — and that mismatch creates problems that go beyond inconvenience.

2. The Multi-Chain Reality

Consider a simple scenario: a wallet application that shows a user their complete portfolio across chains.

Example:To display an accurate balance, the wallet needs to:

1. Query the user’s token balances on Ethereum mainnet
2. Query the same on Base
3. Query the same on Gnosis Chain
4. Query any pending or bridged assets on Optimism

Each of these queries goes to a data source. In today’s standard architecture, that means one or more RPC providers — typically the same large infrastructure providers (Infura, Alchemy, QuickNode) offering endpoints for multiple chains, or a mix of specialized providers.

The user sees a unified interface. Behind the scenes, their wallet is making four separate trust decisions, often without their knowledge.

This is the structural problem: multi-chain applications require multi-chain data access, and today that access is almost universally unverified.

3. Why Trusted RPC Doesn’t Scale Across Chains

In a single-chain context, the RPC trust problem is already significant. As we covered in earlier articles, a compromised or malicious RPC provider can serve fake balances, wrong nonces, tampered contract results, or phantom events — and the application has no way to detect it.

In a multi-chain context, this problem doesn’t just persist — it compounds.

Trust multiplies with every chain

Each additional chain adds at least one more trusted party to the application’s dependency graph. With four chains, a wallet is exposed to four independent failure points. A single compromised provider — whether through a supply-chain attack, social engineering, or deliberate infrastructure poisoning — is enough to corrupt the data the user acts on.

Two recent incidents show what this looks like in practice.

The NPM supply-chain attack (September 2025). Attackers phished an NPM maintainer, gained access to popular JavaScript packages, and injected code that hooked window.ethereum.request — silently replacing the to address in outgoing transactions. The UI showed the correct recipient. The wallet signed tampered calldata. The user's funds were drained.

“You don’t need to break the protocol. You only need to control what the user believes is true.”

Where would colibri.stateless have intervened? The client's colibri_simulateTransaction method executes the signed transaction locally against verified on-chain state before it is broadcast. The simulation runs against Merkle-proven account and storage data — data no injected frontend code can tamper with. The result of the simulation would have shown a transfer to an address the user never intended. The discrepancy between what the user approved and what was actually signed would have been detectable — and stoppable — before the transaction hit the network.

The KelpDAO bridge exploit (April 2026). This is an even more direct example. Attackers — later linked to North Korea’s Lazarus Group — compromised two internal RPC nodes used by the LayerZero DVN (Decentralized Verifier Network) to read source-chain state. Simultaneously, they launched a DDoS attack against the external RPC provider, forcing the DVN to rely entirely on the poisoned infrastructure. The compromised nodes returned forged data selectively: truthful responses to monitoring systems, fraudulent responses to the verifier. The verifier, seeing no anomaly, signed a cross-chain message attesting to a token burn that never occurred. The result: $292 million in rsETH was released on Ethereum against a fabricated event on the source chain.

No smart contract was exploited. No protocol logic was broken. The attack was entirely at the RPC layer — precisely the layer that colibri.stateless is designed to make trustless — the RPC infrastructure remains as a data transport, but the trust requirement is eliminated.

With local proof verification, the DVN would not have been in the position of trusting RPC responses. Every piece of source-chain state — including whether the burn transaction was included in a finalized block — would have been verified against a cryptographic proof anchored to the canonical chain. A forged RPC response cannot produce a valid execution proof. The attack vector simply doesn’t exist in a verified architecture.

KelpDAO illustrates a principle that must be non-negotiable for any multi-chain architecture: cross-chain messages must be based exclusively on verified data. A bridge, a DVN, a cross-chain oracle — any component that reads state from one chain and acts on another based on that state — is only as trustworthy as its data source. Accepting unverified data in this context is not a calculated risk. It is gross negligence. The KelpDAO exploit was not an edge case; it was the predictable outcome of a system that trusted its data instead of verifying it.

The core issue doesn’t change with scale

Adding more chains doesn’t introduce a qualitatively new problem — it amplifies an existing one. The root cause is always the same: the application receives data from an external source and has no mechanism to verify it. Whether that’s one chain or ten, the architecture is trusting rather than verifying.

4. What a Stateless Client Changes

A stateless client, as introduced in Part 3, verifies blockchain data locally using cryptographic proofs — without storing any persistent state, without syncing, and without requiring a full node.

Two proofs work in combination:

• The consensus proof establishes that a given block is part of the canonical chain — signed by the active sync committee.
• The execution proof proves that a specific piece of data (an account balance, a storage slot, a contract call result) is part of that block’s state.

Together, they allow any application to receive data from any source — trusted or untrusted — and verify it locally, on-device, before acting on it.

This shifts how multi-chain data access works at a fundamental level:

Verification becomes chain-agnostic. The same proof model applies whether the data comes from Ethereum mainnet, Base, or Gnosis Chain. What changes are the specific chain parameters and consensus mechanisms — not the verification principle.

The number of trusted parties stops growing. Adding a new chain to an application no longer means adding a new trusted dependency. The application verifies proof data locally; the source of that data doesn’t matter.

Attacks that manipulate data become detectable. A compromised RPC that serves a fake balance will produce data that doesn’t match a valid proof. The local verifier rejects it. The attack fails at the verification layer, not through luck.

5. colibri.stateless in a Multi-Chain Context

colibri.stateless implements this model as a single, portable client, supporting Ethereum, Gnosis, Optimism, Base, and testnets like Sepolia, Chiado, …

The verification model is consistent across all supported chains. For Ethereum mainnet, verification uses BLS aggregate signatures from the sync committee and Merkle Patricia Trie proofs for execution data. For OP-Stack chains (Optimism, Base), the verification stack extends to anchor L2 state to L1 — the same L1 consensus proof forms the root of trust for L2 data.

L2 finality and pre-proofs

For L2 chains, a cryptographically final proof is only possible once the relevant state has been anchored on L1 — the moment the rollup’s state root is posted and confirmed on Ethereum. Depending on the chain and network conditions, this can take minutes to hours.

In practice, however, many applications don’t wait for L1 finality. They accept sequencer confirmations as a working assumption: the transaction is included, the state is known, and the risk of a reorg is considered low. This is a pragmatic tradeoff, not a security guarantee.

colibri.stateless supports both modes. For applications that require full cryptographic finality, verification waits for L1 anchoring. For applications where sequencer-level confirmation is sufficient — a balance display, a UI state update, a low-value operation — the client can verify against witness data: the sequencer's confirmation of state, before it is posted to L1. These witnesses are verifiable through colibri.stateless and provide meaningful integrity guarantees even without full L1 anchoring. Each application can choose the tradeoff that fits its risk profile.

For the wallet scenario above: a single instance of colibri.stateless can verify balance data across all four chains. The wallet no longer makes four independent trust decisions — it makes four independent verification checks, all locally, all against cryptographic proofs.

Three modes, one trust model

colibri.stateless can be integrated in three deployment modes — all equally trustless, differing only in where proofs are generated:

• Local proof — the client fetches raw data from a standard RPC endpoint and generates proofs locally. This requires pulling additional data from both the execution layer and the beacon chain, but keeps everything self-contained.
• Remote proof — the client fetches data from an RPC endpoint as usual, but proof generation is handled by a dedicated proof provider service. Significantly more performant, since the prover can operate with greater efficiency than an embedded client.
• vRPC — data and proofs arrive together from a single endpoint. The RPC provider delivers proof-augmented responses directly, making this the simplest integration and the most performant option.

In all three cases, the local colibri.stateless verifier checks every proof independently. The source of the proof — local, remote, or bundled via vRPC — has no bearing on the trust model. A compromised prover or provider cannot produce a valid proof for manipulated data.

For a multi-chain wallet, this means one colibri.stateless client instance, configured per chain with whichever mode fits the deployment context. The verification guarantee is identical across all of them.

The three modes — and especially vRPC — deserve a closer look. A dedicated article will cover them in depth: how each is configured, what the performance tradeoffs look like in practice, and what vRPC means for existing wallet and dApp infrastructure.

6. Implications for Developers Building Multi-Chain Applications

For developers, the practical consequences are straightforward.

What gets easier

Unified trust model. Instead of evaluating the reliability and security posture of multiple RPC providers for multiple chains, developers integrate one verification library. The trust question shifts from “do I trust this provider?” to “is this proof valid?” — and the second question has a deterministic answer.

Resilient data access. Because colibri.stateless verifies proofs independently of their source, applications can fetch data from multiple sources and verify each independently. A provider outage on one chain doesn't cascade; switching sources doesn't affect verification integrity.

Smaller attack surface. Provider-level attacks — compromised endpoints, injected responses, BGP hijacking, DNS spoofing — stop being exploitable when every response is locally verified. The attacker can still manipulate data in transit; they just can’t produce a valid proof for it.

The tradeoff: proof delivery

Verification requires proofs, and proofs need to come from somewhere. In the local proof mode, everything is self-contained but requires more data from the RPC. The remote prover and vRPC modes offload that work — at the cost of an additional dependency. That dependency is untrusted by design: a compromised prover cannot produce valid proofs for manipulated data. The local verifier will always catch it.

7. Conclusion

Multi-chain applications are not a future scenario — they are the current reality for anyone building serious infrastructure in Web3. A wallet tracking assets on four chains, a bridge protocol verifying state across L1 and L2, a DeFi application sourcing liquidity from multiple networks: all of them face the same structural problem at the data access layer.

Trusted RPC doesn’t solve this problem. It defers it, multiplies it, and makes it harder to reason about as complexity grows.

Stateless clients offer a different architecture: verify locally, trust nothing, accept data from any source. The number of chains in scope stops being a security variable.

colibri.stateless makes this architecture practical today — not as a research prototype, but as a production-ready client library across Ethereum and several EVM-compatible chains, with a footprint small enough to run on mobile, browser, and embedded targets.

Follow Corpus.Core Insights for the next article in the series. If you believe trustless infrastructure matters, sign the Trustless Manifesto . colibri.stateless is open source:github.com/corpus-core/colibri-stateless

For more information, visit our website or follow us on social media (x, telegram, LinkedIn).

---

Multi-Chain Apps & the Importance of Stateless Clients (5 of 9) was originally published in Corpus.Core Insights on Medium, where people are continuing the conversation by highlighting and responding to this story.