Corpus.CoreEthereum Infrastructure
Ethereum Stateless Client
Verify Ethereum data locally without running a full node or trusting an RPC provider.
A stateless client requests only the data and cryptographic proofs required for a specific operation. It verifies the result on the user’s device without storing Ethereum’s complete state or continuously synchronizing the chain.
What is an Ethereum stateless client?
An Ethereum stateless client verifies requested blockchain data without maintaining a complete local copy of Ethereum’s execution state.
Instead of accepting an RPC response as trusted information, it receives the requested data together with cryptographic proofs and verifies them locally.
For Ethereum, this requires two verification layers:
- Execution verification proves that data belongs to a specific execution block.
- Consensus verification proves that this block belongs to the valid Ethereum chain.
How stateless verification works
The verification flow is simple:
The provider transports data and proofs, but the device decides whether they are valid.
- Request — The application requests account data, storage, a transaction, a receipt, logs, or a contract call.
- Data and proofs — An RPC endpoint, local prover, remote prover, or verifiable RPC service returns the requested data and the required proof material.
- Local verification — The client verifies execution proofs against authenticated block roots and verifies the block against Ethereum consensus.
- Verified result — Only successfully verified data is returned to the application.
Execution verification
Execution proofs connect Ethereum data to authenticated roots in an execution block.
Depending on the request, this can include:
For account and storage data, Ethereum Merkle Patricia Trie proofs connect the returned values to the block’s state root.
Contract bytecode can be verified against the code hash stored in the proven account.
- account proofs
- storage proofs
- contract code verification
- transaction inclusion proofs
- receipt inclusion proofs
- verified event logs
Consensus verification
An execution proof shows that data belongs to a particular execution block. Consensus verification establishes that this block is part of Ethereum’s valid chain.
Colibri verifies Ethereum light-client data based on:
Verification starts from a configured weak-subjectivity checkpoint and validates the required consensus path to the target block.
- beacon block commitments
- sync committees
- SSZ Merkle proofs
- aggregated BLS signatures
Trustless eth_call and transaction simulation
The result of eth_call is computed and is not stored directly in Ethereum’s state trie. It therefore cannot be verified with a simple inclusion proof.
A stateless client:
The result is derived from verified state and deterministic local execution rather than from a trusted remote simulation service.
- retrieves the required contract code and state
- verifies those inputs against the block’s authenticated state root
- executes the call locally in an EVM
- returns the locally computed result
Colibri Stateless
Colibri is an embeddable Ethereum stateless client that verifies execution and consensus proofs locally.
It provides:
The RPC or prover service supplies data and proofs. Colibri verifies them locally before the application accepts the result.
- verified account and storage access
- contract code, transaction, and receipt verification
- local EVM execution on verified state
- trustless transaction simulation
- no continuous chain synchronization
- integration for web, mobile, desktop, and constrained devices
Stateless client vs. light client
Both approaches reduce the resources required compared with a full node, but they use different verification models.
| Conventional light client | Stateless client | |
|---|---|---|
| Verification model | Continuously follows Ethereum consensus updates | Verifies requested data on demand |
| Local state | Maintains synchronized light-client state | Requires no continuous header synchronization |
| Best suited for | Applications that require continuous chain awareness | Wallets, dApps, browsers, mobile apps, IoT devices, and AI agents |
Frequently asked questions
What does “stateless” mean in a stateless client?
It means the client does not store Ethereum’s complete global execution state and does not need to continuously synchronize the chain before verifying an individual request. Temporary request data, proofs, checkpoints, and caches may still be used.
Does a stateless client still need an RPC provider?
It still needs a source for data and proofs, but that source no longer needs to be trusted for correctness. The source can be a conventional RPC endpoint, a local node, a prover service, or a verifiable RPC endpoint.
How is eth_call verified?
The client verifies the contract code, account data, storage values, and block context used by the call, then executes the EVM locally. The result is trusted because the inputs are verified and the execution is deterministic.
Is a stateless client the same as a light client?
No. A conventional light client continuously follows consensus updates and maintains synchronized light-client state. A stateless client verifies requested data on demand and does not require continuous header synchronization.
Can a malicious prover create a valid proof for false data?
A malicious prover can refuse to answer or return invalid proof material. It cannot make false data pass verification without breaking the underlying cryptographic assumptions or Ethereum consensus.
Does proof verification also provide privacy?
No. Proof verification protects correctness, but the provider may still observe IP addresses, queried accounts, contracts, storage keys, and transaction parameters. Privacy requires additional transport and content-protection mechanisms.
Verify Ethereum at the application edge
Use Colibri to replace trusted RPC responses with locally verified Ethereum data.