Question 1

What is Colibri?

Accepted Answer

Colibri is a stateless, fully verifying client for Ethereum and EVM-compatible chains. It enables applications to access and validate blockchain data locally using cryptographic proofs, without relying on trusted RPC providers.

Question 2

Why is this important?

Accepted Answer

Most blockchain applications rely on RPC endpoints for data access. These endpoints typically return unverified data, introducing trust assumptions and potential attack vectors. Colibri removes this dependency by making all data verifiable.

Question 3

What does stateless mean?

Accepted Answer

Colibri does not store or sync the full blockchain state. Instead, it verifies only the data it needs using cryptographic proofs. This enables operation in environments with limited bandwidth, storage, or compute.

Question 4

How is this different from light clients?

Accepted Answer

Traditional light clients verify consensus but typically require ongoing sync or maintain partial state. They also rely on weak subjectivity assumptions (trusted checkpoints). Colibri is proof-driven and does not sync or maintain state: it verifies both consensus and execution data on demand using cryptographic proofs, anchored to a trusted checkpoint, enabling stateless operation.

Question 5

How does Colibri verify data?

Accepted Answer

Colibri combines consensus proofs (e.g., sync committee verification) to verify that a block belongs to the canonical chain and execution proofs (Patricia Merkle proofs) to validate accounts and storage. All verification happens locally within the application.

Question 6

What are execution proofs and consensus proofs?

Accepted Answer

An execution proof (e.g., a Patricia Merkle proof) shows that a specific value, account, or transaction belongs to a given block's state. A consensus proof (e.g., sync committee verification, a zk-proof, or a chain of Merkle proofs) shows that the block is on the canonical chain when traced from a known checkpoint, including correct validator and committee transitions. Colibri verifies both locally before the application uses the data.

Question 7

What trust remains if Colibri is trustless?

Accepted Answer

Colibri removes trust in RPC and prover endpoints for data correctness, but verification is anchored to a trusted checkpoint (a weak-subjectivity assumption, as with light clients). Social consensus and checkpoint updates define where that anchor comes from; everything after the checkpoint is proven cryptographically.

Question 8

What if my trusted checkpoint is wrong or outdated?

Accepted Answer

An incorrect or stale checkpoint can anchor verification to the wrong chain fork. Checkpoints must come from a reliable source and be updated according to your chain's weak-subjectivity guidance. This is separate from stale proofs at a valid height, which freshness policies address.

Question 9

What is the difference between an RPC endpoint and a prover?

Accepted Answer

An RPC endpoint returns unverified JSON-RPC data. A prover generates the cryptographic proofs Colibri needs to verify that data locally. Colibri may still use RPC or beacon APIs as data sources, but it does not trust their answers without proofs.

Question 10

What can a compromised RPC or prover server still do?

Accepted Answer

A malicious endpoint cannot make Colibri accept false on-chain data if proofs are verified locally. It can still return incorrect values (verification fails because proofs will not match), return invalid or incomplete proofs (verification fails), return old but cryptographically valid data (addressed by freshness policy), or observe, delay, or censor requests (a privacy and availability concern, not a data-integrity issue when policies are enforced).

Question 11

Can a malicious server provide matching proofs for false data?

Accepted Answer

No. Colibri follows a request → proof → verify → use flow: data is not trusted from the server alone. Execution proofs tie values to a specific block; consensus proofs tie that block to the canonical chain from a trusted checkpoint. A compromised server cannot produce proofs that validate locally while contradicting the claimed state.

Question 12

Does Colibri trust the server if responses are signed?

Accepted Answer

No. Signatures from an RPC or prover do not replace cryptographic verification. Trust is placed in the proof system and checkpoint policy, not in the endpoint that delivered the response.

Question 13

Why isn't using multiple RPC providers enough?

Accepted Answer

Multiple RPCs can improve availability and reduce single-provider bias, but they still return unverified data. Without cryptographic proofs, there is no way to detect when all or a majority of endpoints lie or serve stale state. Colibri verifies each response locally instead of voting on unauthenticated answers.

Question 14

How does Colibri handle stale but valid proofs?

Accepted Answer

Proofs can be valid yet refer to an old block. Applications should enforce a freshness policy, for example minimum block height, maximum block age (e.g., maxAgeSeconds), comparison against multiple sources where appropriate, and checkpoint or finality rules. For transactions, simulations on outdated state should not be accepted for signing decisions.

Question 15

How do reorgs and finality relate to freshness?

Accepted Answer

Freshness limits how old a block may be; finality limits how likely it is to be reorged. Prefer block tags such as safe or finalized over latest when you need stable state. A proof can be fresh at the latest head and still be reorged seconds later if finality rules are not applied.

Question 16

Can Colibri verify historical data?

Accepted Answer

Yes. Data for which valid execution proofs exist and that can be anchored to a verified block can be validated, including historical state and logs.

Question 17

What happens if the data is invalid?

Accepted Answer

Invalid data is rejected locally. The application never operates on unverified or manipulated state.

Question 18

What happens when verification fails?

Accepted Answer

Invalid or incomplete proofs are rejected locally. Depending on configuration, the application should stop the affected operation and report an error or at least a warning. The app does not proceed on unverified or manipulated state.

Question 19

How does this improve wallet security?

Accepted Answer

Transactions can be simulated against verified state before signing. This prevents signing malicious or misleading transactions.

Question 20

How does verification work on Layer 2 chains like Optimism?

Accepted Answer

On some L2s, full trustless verification may only be possible after data is anchored on L1, which can take 30+ minutes. For earlier reads, Colibri can use pre-proofs via a witness protocol: the user relies on the sequencer's signature for interim assurance. That is not fully trustless but removes trust in the RPC provider alone. Pre-proofs can also bridge chains that do not yet support full Colibri verification.

Question 21

When should I use ZK consensus proofs vs classical committee replay?

Accepted Answer

Both approaches prove that a block belongs to the canonical chain from a checkpoint. Classical replay verifies each sync committee transition step by step. A recursive ZK consensus proof compresses those transitions into one succinct proof with constant-time verification and the same security goal, which helps on resource-constrained devices or long spans since the last checkpoint.

Question 22

Which chains support full verification vs pre-proofs only?

Accepted Answer

Ethereum mainnet supports full verification for features covered by Colibri. Other EVM chains depend on available consensus and execution proof implementations. Some L2s use pre-proofs until L1 anchoring is available; chains without full support may rely on pre-proofs or witness-based assurance until proof coverage is complete.

Question 23

What is vRPC and how does it fit Colibri?

Accepted Answer

vRPC is a drop-in style interface that returns blockchain data together with cryptographic proofs. It removes the need to trust a traditional RPC provider for correctness while remaining compatible with workflows that expect RPC-shaped responses. Applications can verify responses locally with Colibri or consume proof-bound data from vRPC directly.

Question 24

What is PAP (Pragmatic Adaptive Privacy)?

Accepted Answer

PAP is a privacy model used with Colibri that minimizes data leakage. It adapts how data is requested and exposed depending on context, reducing the visibility of user behavior. Learn more at /pap.

Question 25

Why is privacy relevant for blockchain reads?

Accepted Answer

Even read requests can leak sensitive information such as balances, behavior, or intent. PAP reduces this exposure while maintaining functionality.

Question 26

Is privacy optional?

Accepted Answer

Yes. Applications can configure how strictly PAP is applied depending on their requirements.

Question 27

Can a compromised server see what I query even if data is verified?

Accepted Answer

Yes. Even when all responses are verified, the server may see metadata such as addresses, contracts, and storage slots requested. That is a privacy and availability risk, not a data-integrity risk. Mitigations include PAP, multiple provers or vRPCs, Tor or mixnets, query broadening, or running a local prover where feasible.

Question 28

Where can Colibri run?

Accepted Answer

Colibri can run in mobile applications, web applications, IoT devices, and backend services.

Question 29

Do I need to run infrastructure?

Accepted Answer

No mandatory infrastructure is required. Colibri runs directly inside applications; optional prover services can be used to improve performance and latency.

Question 30

Can I run without trusting any third-party server?

Accepted Answer

Colibri always verifies locally, so you do not need to trust a remote endpoint for data correctness. In practice, proofs and chain data are usually fetched over the network; running your own prover (and RPC or beacon access you control) reduces reliance on third parties for availability and metadata exposure.

Question 31

Should I use multiple provers or RPCs?

Accepted Answer

Using more than one source improves availability, helps detect censorship or delays, and supports freshness checks by comparing block heights and ages. Verification still happens locally on each response; multiple endpoints do not replace proofs, but they reduce dependence on a single operator.

Question 32

What are the resource requirements?

Accepted Answer

Colibri is optimized for low bandwidth and constrained environments (e.g., sub-MB binaries and low memory usage). It avoids the overhead of full node synchronization.

Question 33

Does this increase latency?

Accepted Answer

Verification introduces computational overhead (local CPU), while network access remains required. With precomputed proofs, round trips can be reduced and latency becomes predictable.

Question 34

Who should use Colibri?

Accepted Answer

Wallets, dApps, IoT systems, AI agents, and multi-chain applications should use Colibri.

Question 35

Why does this matter now?

Accepted Answer

As Web3 adoption grows, relying on trusted infrastructure becomes a critical limitation. Applications require verifiable data to ensure correctness and security.

Question 36

How is Colibri different from other solutions?

Accepted Answer

Colibri combines stateless architecture, full verification (consensus + execution), and a privacy model (PAP). Other solutions typically address subsets of these aspects or do not combine them in a single client.

Question 37

Is this production-ready?

Accepted Answer

Yes for Ethereum mainnet features covered by Colibri. Trustless data access is already achievable without protocol changes; support for additional chains depends on available proof implementations.

Core Tech for aTrustless Web3 Stack

Our Products

Colibri Stateless Client

vRPC

Transaction Security Agent

IoT/Embedded Framework

AI Agentic Framework

Pragmatic Adaptive Privacy

Built with Colibri

ColiCam

Our Services

Our Team

Jork Leonhardt

Steffen Kux

Simon Jentzsch

Our Advisors

Christoph Jentzsch

Our Blog

Blockchain Clients for IoT — Overcoming Resource Constraints (6 of 9)

colibri.stateless v2.0.0: New Prover, PAP Reaches MVP

The Code Was Fine. That's the Problem.

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

Pragmatic Adaptive Privacy (PAP)

Understanding Blockchain Clients and Their Role in Decentralized Networks (1 of 9)

Full Nodes vs. Light Clients — Trade-offs in Security and Efficiency (2 of 9)

Daily Memes

Frequently Asked Questions