> For the complete documentation index, see [llms.txt](https://corpus-core.gitbook.io/specification-colibri-stateless/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://corpus-core.gitbook.io/specification-colibri-stateless/introduction/motivation.md).

# Motivation

#### The Problem

Client-side access to blockchain today primarily relies on Remote Procedure Call (RPC) endpoints. These RPCs act as unverified intermediaries between users and the chain. The resulting data path introduces a single point of failure and a single point of trust. A compromised or manipulated RPC can inject falsified execution results, inconsistent block data, or censored state queries without the client detecting it. This architectural dependency breaks verifiability and undermines decentralization.

#### Technical Goals

Colibri.stateless aims to eliminate unverified RPC dependencies by enabling clients to perform full on-device verification of blockchain state transitions. The design objectives are:

* **Consensus-layer verification**: Validation of finalized checkpoints, sync committee signatures, and validator transitions.
* **Execution-layer verification**: Verification of state data, storage proofs, and execution results using Merkle or Verkle proofs.
* **Stateless operation**: No persistent chain state or continuous block synchronization.
* **Resource efficiency**: Operability under strict CPU, RAM, and bandwidth limits typical of mobile, IoT, and web environments.
* **Proof composability**: Consensus and execution proofs must be independently generatable, transferable, and recursively verifiable.

#### Design Constraints

Target environments impose the following hardware and network limitations:

* Available memory: ≤ 50 MB
* Limited processing power (≤ 2 cores, low clock speed)
* Unreliable or intermittent connectivity
* Startup time < 2 seconds for proof verification

These parameters exclude full or traditional light clients, which rely on continuous synchronization and large state databases. Colibri.stateless must reconstruct trust solely from cryptographic proofs.

#### Resulting Architecture

Colibri.stateless introduces a modular, proof-driven architecture:

1. **Consensus Proofs** represent validator set transitions derived from sync committee aggregates, including BLS signature verification. These proofs establish the trust anchor for the execution layer.
2. **Execution Proofs** provide verifiable inclusion of account, storage, or transaction data via Merkle or Verkle trees rooted in a verified block header.

Both proof systems can be composed recursively to verify arbitrary state or transaction results without network trust assumptions. The client acts as a fully verifying node in a stateless configuration.

#### Intended Scope

Initial implementation focuses on the Ethereum mainnet and EVM-compatible networks. The proof abstraction layer supports extending to heterogeneous chains that expose verifiable consensus and state transition proofs. Colibri.stateless thus defines a general framework for multi-chain verification and trustless cross-chain data access.