# Motivation colibri.stateless – A Stateless and Trustless Client for Ethereum and (any) other blockchain ## Decentralization as a Trustless Alternative Blockchain technology has become a foundational pillar for distributed systems, enabling secure, trustless interactions without relying on centralized intermediaries. While initially associated with cryptocurrencies, its applications extend across financial services, supply chain management, identity verification, gaming, art, digitized assets, governance and voting, internet-of-things, and many more, where verifiable data integrity and fault tolerance are critical. ## The Problem of Trust in Centralized Systems Most digital infrastructures today rely on **centralized architectures**, where service providers maintain complete control over data and operations. While centralized systems offer advantages such as convenience, ease of use, fast transaction processing, simplified governance, and compliance with regulatory frameworks, they introduce systemic vulnerabilities: * **Centralized Control:** Operators possess unilateral authority over data and services, allowing for **censorship, access revocation, and opaque policy changes**. * **Single Points of Failure:** Centralized infrastructures create **attack surfaces** prone to **security breaches, outages, and manipulation**. * **Limited Transparency:** Users depend on providers to act in good faith, often without **cryptographic guarantees** ensuring the correctness or integrity of stored and transmitted data. * **Encryption Limitations:** While encryption is widely employed to secure data in transit, centralized systems do not inherently guarantee the integrity or verifiability of the data source itself. ## The Need for Efficient Blockchain Access Blockchains provide **robust security guarantees, resistance to censorship and manipulation, and trustless operation.** However, **direct and efficient access remains a challenge. In principle, users of** decentralized applications can run their own full nodes to interact with the decentralized ecosystem. Often, this is impractical due to high storage, bandwidth, and computational requirements, making alternative access mechanisms necessary. Many decentralized applications (dApps) and smart contract platforms rely on **centralized RPC infrastructure** to interact with blockchain networks, reintroducing trust dependencies and potential points of failure. To fully leverage blockchain’s decentralization, access mechanisms must be: 1. **Independent**—Verification of blockchain state should be possible **without reliance on third-party services**. 2. **Efficient**—Resource-constrained environments (e.g., web, mobile, IoT) require **low-bandwidth, low-storage solutions**. 3. **Trustless**—All retrieved data should be **cryptographically verifiable** without intermediary validation. The **colibri.stateless client** addresses these challenges by providing a **stateless, trustless, and efficient** blockchain verification framework. Colibri.stateless eliminates trust dependency on RPC endpoints and enables secure, direct blockchain interaction, making it particularly suited for web, mobile, IoT, and other constrained environments. # Challenges of Current Blockchain Access ## Centralization in Blockchain Access While blockchain networks are inherently decentralized, the way users and applications access blockchain data is often highly centralized. Many decentralized applications (dApps), wallets, and services depend on centralized RPC providers to retrieve the blockchain state. This reliance introduces several critical challenges: * **Single Points of Failure**—A centralized RPC provider represents a bottleneck; users lose access to blockchain data if the provider becomes unavailable. * **Censorship Risks**—Centralized providers can filter or restrict access to particular transactions or accounts. * **Data Integrity and Manipulation Risks**—Users must trust that the RPC provider delivers correct, untampered blockchain data without being able to independently verify that data. ### Resource Constraints for Running a Full Node Running a full node is the most direct way to interact with a blockchain network without relying on third-party services. Full nodes independently validate transactions, maintain blockchain state, and provide verifiable data. However, this approach comes with significant challenges: * **High Storage Requirements**—A full node must store all relevant blockchain data, including the current state and, depending on the node type, historical data. This requires substantial disk space and ongoing storage expansion. * **Significant Bandwidth Consumption**—Full nodes continuously download, validate, and propagate new blocks and transactions, consuming considerable bandwidth. * **Computational Overhead**—Every full node executes all transactions to recompute the latest blockchain state, requiring substantial processing power. Despite these challenges, running a full node remains essential for specific use cases. Applications requiring frequent access to historical blockchain data, on-chain analytics, or complete transaction traceability benefit from self-hosted infrastructure, which ensures long-term data availability and verifiability. In such cases, storage, bandwidth, and computation trade-offs are justified by the need for complete control over blockchain data. ### Limitations of Existing Light Clients Light clients provide an alternative to full nodes by reducing the resource requirements associated with blockchain interaction. Instead of processing and storing the entire blockchain, light clients synchronize block headers and request specific data when needed. While this significantly reduces storage and computation overhead, it introduces several limitations: * **Continuous Synchronization Requirement**—Light clients must frequently synchronize block headers to stay updated with the network. If a light client has been offline for an extended period, it must resynchronize before use, leading to potential delays and increased bandwidth consumption. * **High Communication Overhead**—Light clients frequently interact with full nodes to fetch necessary data, resulting in significant network traffic. This makes them impractical for constrained environments such as IoT devices (e.g., microcontrollers) and web applications where persistent connectivity is not guaranteed. * **Resource Constraints in Mobile and IoT Applications**—Light clients require fewer resources than full nodes but consume considerable bandwidth and computational power. On most mobile devices, frequent synchronization can lead to excessive battery drain, and on IoT hardware, resource limitations often make the deployment of existing light clients infeasible. * **Dependency on Trusted Checkpoints for Fast Sync**—To optimize synchronization speed, many light clients begin syncing from a known trusted checkpoint rather than validating the entire blockchain history. While this improves efficiency, it introduces a trust assumption that may reduce the overall security guarantees if the checkpoint provider is compromised. Due to these constraints, light clients are not a universal solution for all use cases. While they offer a viable alternative to full nodes in some scenarios, they remain unsuitable for highly resource-constrained environments where minimal bandwidth, low power consumption, and fast, on-demand verification are required.

Comparison of blockchain client types

### Need for a More Efficient, Trustless Approach To address these limitations, a **Trustless Ultra-Light Client (Trustless Ultra-Light Client)** architecture is introduced. It is designed to achieve network consensus verification through cryptographic proofs instead of complete blockchain execution, thereby eliminating the need for persistent storage and trust in third-party data providers. #### Stateless Clients: A New Class of Verification Clients A **Stateless Client** (sometimes also named trustless client) operates without storing the blockchain state or participating in the peer-to-peer network. Instead, it retrieves only cryptographic proofs from untrusted sources and verifies them using cryptographic primitives. This eliminates the need for trusted intermediaries while maintaining strong security guarantees. Importantly, Stateless Clients are primarily **not designed to replace RPC providers**. Instead, they complement existing infrastructure by enabling decentralized, trustless blockchain data verification, ensuring users are no longer forced to trust RPC endpoints blindly. #### Key Properties of Trustless Stateless Clients * **Stateless Operation**—No persistent storage of blockchain data, minimizing resource requirements and reducing attack surfaces. * **Cryptographic Verification**—This method ensures the correctness of retrieved data using proof-based validation, eliminating the need to trust RPC providers or centralized intermediaries. * **No Synchronization Overhead**—Unlike traditional light clients, they do not require tracking blockchain history or continuous state updates, enabling immediate verification upon request. * **Minimal Resource Consumption**—They are Optimized for low-bandwidth and low-power environments, making them suitable for IoT, mobile, and embedded applications. * **Multi-Chain Verification**—Can concurrently verify proofs from multiple blockchain networks without additional infrastructure or network participation. * **Enhanced Decentralization**—This eliminates reliance on centralized RPC endpoints by enabling users to verify all received data independently through cryptographic means. Furthermore, this approach does not require deploying a new network infrastructure but can leverage existing data sources, such as RPC providers, while mitigating their inherent trust dependencies and centralization risks. ### Trade-offs and Use Case Considerations While **stateless clients** significantly improve decentralization and trustless verification, they are not the optimal solution for every use case. Some applications, such as block producers, validators, or high-frequency trading systems, may still require full nodes or other high-performance solutions. However, stateless clients provide a superior alternative to using an RPC provider without verification for many real-world applications. They allow users to access blockchain data efficiently, securely, and trustlessly without the overhead of full-node operations or the synchronization requirements of traditional light clients. This model ensures decentralized, secure, and efficient blockchain access without the scalability limitations of full nodes or traditional light clients. By leveraging cryptographic proofs instead of network-trusted responses, stateless clients enable a more resilient and censorship-resistant way to interact with blockchain networks. # Trustless Manifesto The [Trustless Manifesto](https://trustlessness.eth.limo/general/2025/11/11/the-trustless-manifesto.html) articulates a clear position: blockchain systems should minimize trust assumptions wherever possible and must not rely on opaque intermediaries, unverifiable services, or implicit guarantees. Trust should be replaced by verifiability, and verification should be feasible for end users, not only for specialized infrastructure providers. Core principles of the manifesto include: * Do not trust remote services when verification is possible. * Do not replace cryptographic guarantees with social or institutional trust. * Verification must be accessible, efficient, and practical for real users and devices. * Trust assumptions must be explicit, minimal, and auditable. * Systems should degrade gracefully toward trust, not depend on it by default. The manifesto highlights a fundamental problem in today’s blockchain ecosystem: while blockchains themselves are designed to be trustless, most applications consume blockchain data through trusted RPC endpoints. This reintroduces centralized trust and undermines the original security model. ### Relation to Colibri **Colibri.stateless** fully aligns with and strongly supports the Trustless Manifesto. The client architecture is explicitly designed to eliminate implicit trust in remote infrastructure and to replace it with local, cryptographic verification. Colibri addresses several of the manifesto’s core concerns directly: * **RPC Trust:** Colibri does not accept unverified RPC responses. All execution data and consensus information is verified locally using cryptographic proofs. * **Verifiability for End Devices:** Colibri enables verification on resource-constrained devices, including mobile, web, and embedded systems. Trustless verification is not limited to full nodes or specialized servers. * **Explicit Trust Boundaries:** Where trust cannot be eliminated entirely, such as in pre-final or non-provable data, Colibri makes trust explicit through mechanisms like the Witness Protocol. Trust is never implicit or hidden. * **Graceful Degradation:** Colibri degrades toward reduced trust only when proofs are unavailable, and provides a clear upgrade path toward full trustlessness as proof support becomes available. ### Statement of Support Colibri explicitly endorses the [Trustless Manifesto](https://trustlessness.eth.limo/general/2025/11/11/the-trustless-manifesto.html). The principles articulated in the manifesto are not treated as aspirational goals but as concrete engineering requirements. For many of the challenges identified in the manifesto—trusted RPC usage, unverifiable reads, exclusion of low-resource clients—Colibri provides a concrete and deployable solution. Stateless verification, execution and consensus proofs, witness-based fallback mechanisms, and a layered approach to privacy collectively form a practical answer to the call for trustless blockchain interaction. > Colibri is built to operationalize the Trustless Manifesto. # The Future of Stateless Clients The development of stateless clients is crucial in making blockchain interactions more efficient, decentralized, and trustless. Leading blockchain researchers and developers, including Vitalik Buterin, have highlighted the necessity of eliminating reliance on centralized RPC endpoints and moving towards cryptographic verification of blockchain data on lightweight clients. ## Industry Perspectives on Stateless Clients ### **Vitalik Buterin on Stateless Ethereum** Vitalik Buterin has repeatedly emphasized the importance of stateless clients for the scalability and accessibility of Ethereum: * The Ethereum roadmap includes "The Verge," which aims to reduce the cost of complete verification so that it can be executed on lightweight devices such as mobile wallets and browsers. * Stateless verification enables nodes to validate blocks without maintaining the entire state, instead relying on cryptographic proofs. * Verkle Trees are being explored to optimize state storage and facilitate efficient stateless verification. * In the long term, Ethereum should support fully verifiable nodes on consumer hardware, strengthening decentralization and security. #### **Technological Challenges and Opportunities** While stateless clients provide a robust solution for blockchain verification, implementing them requires significant protocol upgrades: * The current Ethereum State Tree structure needs modifications to accommodate proof-based validation. * Zk-Proofs are expected to enhance consensus verification and execution state validation, reducing computational overhead. * The ability to fetch and verify blockchain state independently will make applications more secure and reduce trust dependencies on third-party services. ## Implications for Blockchain Adoption Stateless clients are positioned to become the standard for blockchain access across various applications: * **Web and Mobile Applications**—Users can verify transactions without relying on centralized services. * **IoT and Embedded Systems**—Stateless verification will allow resource-constrained devices to interact securely with blockchain networks. * **AI Agents and Automation**—Future autonomous applications will require trustless and verifiable AI-driven interactions with blockchain assets. By establishing stateless clients as a fundamental component of blockchain infrastructure, the ecosystem moves closer to a fully decentralized and trustless architecture. The ultimate goal is to integrate these mechanisms at the protocol level, ensuring all blockchain interactions are cryptographically secure by default. # Stateless Verification and Efficient Data Retrieval ## Overview of the Architecture Corpus Core's **colibri.stateless** Client (C4) is a trustless, stateless client designed for secure and efficient blockchain verification. It operates without maintaining a blockchain state or participating in the peer-to-peer network, instead relying solely on cryptographic proofs for verification. * **Stateless Design**—This design does not store blockchain history but verifies state transitions, account information, and transaction information using cryptographic proofs. * **Proof-Based Verification**—This method authenticates blockchain data using sync committee signatures, Merkle proofs, and zk-proofs. Additionally, in Layer-2 usage, it verifies rollup proofs, including zero-knowledge and fraud proofs, ensuring the correctness of Layer-2 state transitions. * **Multi-Chain Compatibility**—Supports multiple Layer-1 and Layer-2 networks for interoperability. # Execution Layer Data Retrieval and Verification ## EVM-Compatible Chains Since Corpus Core's **colibri.stateless** Client (C4) is not part of the peer-to-peer network, it retrieves blockchain data from external providers, such as centralized or decentralized RPC services. To ensure trustless verification, all retrieved data is accompanied by cryptographic proofs, precisely Merkle proofs obtained via EIP-1186 (`eth_getProof`). Colibri.stateless enables verification of execution layer data through: * **Account and Storage Validation**—Uses Merkle proofs to verify balances, nonce values, and smart contract storage against blockchain state. * **Transaction Inclusion Verification**—This process ensures that a transaction is part of a specific block by validating Merkle proofs against the block header. * **Receipt and Event Log Verification**—Authenticates transaction receipts, gas usage, and emitted events. * **Block Header Validation**—Confirms the correctness of block hashes, state roots, and receipts roots. * **Smart Contract Execution Validation**—Runs smart contracts within the embedded EVM and verifies state changes and execution results using Merkle proofs. Colibri.stateless ensures interoperability and trustless validation without requiring network synchronization by applying the same verification approach across all EVM-compatible chains. However, at this stage, only the integrity of the retrieved information is guaranteed, meaning that the data belongs to a specific block. The correctness of the block itself (that this block is part of the canonical chain) is only established through the consensus verification process, which ensures that the block was legitimately produced and signed by the correct validators. ## Non-EVM Chains While colibri.stateless is initially designed for EVM chains, it can extend its functionality to other Layer-1 and Layer-2 blockchains that provide verifiable proof mechanisms. For non-EVM chains, the verification approach depends on: * **Availability of State Proofs**—The blockchain must support cryptographic proofs that validate the correctness of state data. * **Block Inclusion Proofs**—Proofs must exist to verify that specific data belongs to a given block. * **Smart Contract Execution Proofs**—If applicable, the blockchain must provide a way to prove the correct execution of smart contract logic, such as zk-proofs or fraud proofs in optimistic rollups. By adapting its verification model to different proof structures, colibri.stateless can extend its trustless verification approach beyond EVM-based networks to support a broader range of blockchain ecosystems. # Consensus Verification The correctness of the block itself and that the block is part of the canonical chain must be verified to ensure that retrieved execution layer data originates from a valid blockchain state. Execution layer proofs confirm that specific data, such as transactions, events, or account states, are part of a given block. However, this does not guarantee that legitimate validators correctly produced and signed the block. ## Ethereum Ethereum's current consensus mechanism relies on a sync committee system, which is integral to the protocol and ensures efficient block verification. While this approach benefits light clients by reducing synchronization overhead, it is a fundamental part of Ethereum's consensus design. Every 256 epochs (8192 slots), a new sync committee of 512 validators is selected to sign beacon chain headers. A stateless client must verify that the current sync committee is valid by proving the continuous transition of committee membership from a trusted checkpoint. This requires: * Sync Committee Proofs—Verifying that the validators signing the block are part of the active sync committee. * Light Client Updates—Ensuring correct transitions between sync committees by checking the signatures of the previous committee. * Finality Verification—Confirming that the beacon chain finalization process was executed correctly. This process requires verifying the entire sequence of validator committee transitions from the checkpoint to the required block. If the client has not stored any additional verified information beyond the initial checkpoint, it must retrieve and validate the entire transition history. Optimizations can be applied to improve efficiency: * **Caching Verified Transitions**—The client can store previously verified committee transitions, reducing redundant verification steps when validating future blocks. * **Zero-Knowledge Proofs**—Instead of directly verifying each committee transition, ZK-proofs can aggregate multiple transitions into a single proof, significantly improving efficiency (see later explanation). To overcome these limitations, an advanced solution involves using zero-knowledge proofs (ZK-proofs). ZK-proofs enable efficient validation of multiple transitions in a single proof, eliminating the need to store intermediate checkpoints while maintaining full verification capabilities (see later explanation). ## Layer-2 Rollups on Ethereum For Ethereum-based Layer-2 solutions, an additional two-step verification process is required: * **Rollup Proof Validation**—The first step involves verifying that the rollup proof correctly represents the rollup's state transition. Depending on the rollup type, this proof can be either a zero-knowledge proof (ZK-rollups) or a fraud-proof-based system (Optimistic rollups). The proof ensures that the rollup state transition was executed correctly and is included in an Ethereum Layer-1 transaction. * **Consensus Verification of the Rollup Proof**—Once the rollup proof is verified, the next step is to ensure it was correctly published on Ethereum Layer-1. This requires verifying that the Ethereum block containing the rollup proof is valid by following the same sync committee transition verification process used for Layer-1 Ethereum blocks. For **optimistic rollups**, finality depends on the fraud-proof challenge period defined by the rollup protocol. Transactions can only be considered final once the challenge window has passed without valid fraud-proof being submitted. In contrast, **ZK-rollups** achieve immediate finality upon proof submission, as the validity proof guarantees the correctness of the state transition without requiring a dispute period. Before L1 finality is reached and the fraud-proof challenge period is finished, many Optimistic Rollups rely on block proposals produced by a trusted sequencer. These proposals are signed and can be verified by the client, providing an intermediate security guarantee prior to Ethereum finality. While this does not replace L1 consensus verification or the fraud-proof window, it enables clients to distinguish authentic sequencer outputs from arbitrary data during the pre-finality phase. Colibri.stateless can verify these signed sequencer block proposals and treat them as *pre-final* inputs with elevated trust compared to unsigned RPC responses, while still requiring full L1 finality proofs for final state acceptance. ## Other EVM-Compatible Layer-1 Chains For EVM-compatible Layer-1 blockchains, execution layer validation follows the same principles as Ethereum. However, consensus verification differs based on the chain’s consensus mechanism. These chains may employ: * **Proof-of-Stake Validator Sets**—A rotating set of validators signing blocks requiring validator set verification. * **Byzantine Fault Tolerance (BFT) Mechanisms**—Checking quorum signatures to confirm block validity. * **Custom Consensus Models**—Adapting verification logic to specific consensus rules defined by the blockchain. ## Non-EVM Layer-1 Chains For non-EVM Layer-1 blockchains, both execution and consensus verification mechanisms vary. Stateless clients must validate consensus using blockchain-specific proofs, which may involve: * **Threshold Signatures or Multi-Signature Schemes** – Used in networks with committee-based finalization. * **Quorum-Based Verification** – Ensuring that a majority of validators signed off on a block. * **Zero-Knowledge Proofs for Consensus** – Some newer blockchains utilize zk-proofs to verify block production without disclosing validator details. By generalizing the verification process across different consensus mechanisms, **colibri.stateless** can operate in diverse blockchain environments while maintaining a trustless and stateless architecture. Additionally, alternative approaches such as Directed Acyclic Graph (DAG) structures, Byzantine Fault Tolerance (BFT), Proof-of-Authority (PoA), and other consensus algorithms can be integrated, provided that a proof mechanism exists to verify the correctness of block production and validation. # Local Prover vs. Remote Prover Service Stateless verification requires the generation and verification of cryptographic proofs for execution and consensus data. \ **Colibri.stateless** supports two alternative models for proof generation: * a Local Prover embedded in the client and * a Remote Prover Service. Both variants are fully trustless. In all cases, the client accepts only cryptographically verifiable proofs. A prover cannot convince the client of incorrect data; either a valid proof exists or verification fails. ### Local Prover With the Local Prover, all proof generation is performed directly inside the **colibri.stateless** client. The client operates autonomously and generates all required execution and consensus proofs itself. Execution proofs are obtained using standard Ethereum mechanisms such as `eth_getProof` and are verified locally. Consensus proofs are constructed starting from a trusted checkpoint by verifying successive validator and sync committee transitions of the Beacon Chain. A **colibri.stateless** client using the ***Local Prover*** can independently read blockchain data and generate the necessary proofs without relying on external services. **Advantages** * No dependency on external infrastructure * Maximum autonomy and self-sovereignty * Suitable as a fallback mechanism **Limitations** * Lower performance due to the cost of collecting and assembling proof inputs * Historical proofs cannot be generated if the target state predates the chosen checkpoint * High computational overhead when many validator transitions must be verified * zk-proof generation is impractical and not intended for this mode (as it doesn't make sense to create such a proof locally. ### Remote Prover Service With the ***Remote Prover Service***, proof generation is delegated to an external system. The client receives completed proofs and verifies them locally. This model enables significantly improved performance through: * Caching of previously generated proofs and data * Precompiled or aggregated proofs * Efficient consensus verification using zk-proofs * Batch generation of proofs for multiple queries or state elements The Remote Prover Service does not introduce additional trust assumptions. It is not a trusted third party; proofs are either cryptographically valid or rejected by the client. ### Trust Model and Security Assumptions Both the Local Prover and the Remote Prover Service operate under the same trustless security model. The location of proof generation does not affect correctness guarantees. Security derives exclusively from cryptographic verification performed by the client. ### Performance and Resource Considerations Using a Local Prover shifts all proof generation costs to the client, increasing CPU usage, memory consumption, and network bandwidth requirements. In particular, assembling proof inputs and verifying long sequences of validator transitions can be resource-intensive. The Remote Prover Service significantly reduces client-side requirements. The client verifies compact proofs, while computationally expensive tasks are executed externally. This model is well suited for mobile applications, embedded systems, and environments with strict latency constraints. ### Offline Proving **Colibri.stateless** enables verification even when the client has no direct internet connectivity. Required data and corresponding proofs can be transferred to the client via alternative channels, after which verification is performed locally without restrictions. This capability extends blockchain security to environments that are otherwise excluded. Full nodes and classical light clients require continuous network access. RPC-based architectures depend on online connectivity as well and use unverifiable responses. **Colibri.stateless** uniquely decouples data transport from verification and enables trustless blockchain interaction on fully offline systems, including air-gapped cold wallets and smart IoT devices using short-range communication such as Bluetooth. # Optimization Techniques for Efficient Verification ## Caching Checkpoints for Faster Proof Verification Verifying every committee transition from a trusted checkpoint to a required block is computationally expensive. To optimize this process, **colibri.stateless** can cache intermediate checkpoints, reducing the length of proof chains. This allows: * **Reduced Verification Overhead**—Instead of revalidating all sync committee transitions, the client can jump between cached checkpoints. * **Adaptive Checkpoint Selection**—The caching strategy dynamically adjusts based on the frequency of requested data. * **Application-Specific Checkpointing**—Trusted checkpoints can be provided by an external application or selected based on prior validation history. To overcome these limitations, an advanced solution involves using zero-knowledge proofs (ZK-proofs). ZK-proofs enable efficient validation of multiple transitions in a single proof, eliminating the need to store intermediate checkpoints while maintaining full verification capabilities. # zk-Proofs to compress Consensus Proofs ## zk-Proofs for Sync Committee Aggregation **Colibri.stateless** can integrate zk-proofs to validate multiple sync committee transitions in a single proof to optimize verification further. This enables: * **Aggregated Proofs**—A single proof covering multiple transitions from the trusted checkpoint to the required block. * **Compact Verification**—Instead of verifying individual committee changes, zk-proofs compress multiple verification steps into a succinct proof. * **Scalability Improvements**—Aggregated zk-proofs reduce computational complexity and bandwidth requirements as the blockchain grows. By combining caching mechanisms with zk-proof aggregation, **colibri.stateless** significantly enhances the efficiency of blockchain verification while maintaining trustless and decentralized operations. # Precompiled Proofs Precompiled proofs are cryptographic proofs generated in advance by a Remote Prover Service for queries that are expected to recur frequently. This mechanism is exclusive to the Remote Prover Service and is not applicable to the Local Prover model. Proofs are created proactively, independent of individual client requests, and stored for later use. Compared to on-demand proofs, precompiled proofs may cover larger data sets or multiple verification steps and are designed for reuse across clients. At request time, a precompiled proof can be delivered immediately. No additional state retrieval from execution nodes or RPC endpoints is required, and no proof generation is performed synchronously. Precompiled proofs may also consist of partial proofs. These represent reusable proof fragments that can be composed or extended to derive a final proof, substantially reducing construction time for complex or aggregated proofs. ### Scope Precompiled proofs rely on persistent storage, background computation, and the ability to observe recurring demand patterns. These properties are inherent to a Remote Prover Service and are not available in a client-side Local Prover. ### Security Model Precompiled proofs do not modify the trust model. As with all **colibri** proofs, verification is performed locally by the client using cryptographic checks. A proof is either valid or rejected; incorrect data cannot be proven. ### Performance Implications By moving proof generation out of the request path, precompiled proofs minimize latency and avoid redundant computation. They enable caching, amortize expensive verification steps, and support efficient handling of repeated queries, batch requests, and complex consensus proofs. Precompiled proofs can also be used to optimize specific application scenarios in which low latency and smooth user interaction are critical. By serving proofs immediately, applications can operate with predictable response times and improved responsiveness. In all cases, correctness and availability are unaffected. If a precompiled proof is not available, the proof request can still be fulfilled through on-demand proof generation. The only difference is increased latency. This allows Remote Prover Service operators to decide whether and which precompiled proofs to maintain, without impacting the functional correctness of client verification. # Witness Protocol The Witness Protocol is not intended to replace cryptographic proofs. Its purpose is to reduce trust assumptions in situations where execution or consensus proofs are unavailable, incomplete, or not yet applicable. Instead of blindly trusting a single data provider, a client can obtain independent confirmation of specific information from one or more witnesses. Witnesses attest to the correctness of information by issuing signed statements. This introduces an additional verification layer and reduces reliance on a single unverified source. The Witness Protocol is designed as an intermediate security mechanism. It provides immediate trust reduction while preserving a clear upgrade path toward fully proof-based verification once native execution and consensus proofs become available. For certain scenarios, witnesses are the only viable verification mechanism at a given point in time. A prominent example are Layer-2 rollups where a sequencer can attest that transactions or data have been accepted, while the corresponding state is not yet anchored on Layer 1 and therefore not provable. In such cases, witnesses—such as the sequencer itself—provide the only form of verifiable confirmation prior to L1 finality. ### Application Scenarios The Witness Protocol applies to situations in which proof-based verification cannot be performed or cannot yet be performed. The following scenarios illustrate typical use cases. #### Unsupported Chains For Layer-1 or Layer-2 chains that are not yet integrated into **colibri.stateless**, execution and consensus proofs are unavailable. Witnesses enable clients to obtain signed attestations about specific chain data, providing a reduced-trust verification model until native proof support is implemented. #### Non-Proveable Data Some information cannot be verified using execution or consensus proofs. This includes off-chain metadata, application-level aggregates, or protocol data that is not part of a verifiable state transition. Witnesses provide a mechanism to attest to such data while avoiding blind trust in a single provider. #### Pre-Finality and Sequencer Data In rollup systems, there is a phase in which data has been accepted by the sequencer but is not yet finalized or anchored on Layer 1. During this phase, no cryptographic proof exists. Signed witness statements are the only mechanism to confirm inclusion before final settlement. #### Non-Final Data The Witness Protocol can also be applied to inherently non-final data, such as recent blocks, pending states, or intermediate protocol states. Witnesses allow clients to reason about such data with reduced trust assumptions while explicitly acknowledging the lack of finality. ### Limitations and Role The Witness Protocol cannot replace execution or consensus proofs and must not be treated as equivalent. It introduces explicit trust and, in crypto-economic variants, additional system complexity. At the same time, witnesses enable **colibri.stateless** to scale rapidly in its initial deployment phase. Chains, data sources, and information types for which no proofs exist yet can be integrated immediately using witness-based verification. This includes information for which cryptographic proofs are fundamentally unavailable. As native proof support becomes available over time, witness-based verification can be incrementally replaced. The Witness Protocol is therefore essential for the rapid and broad adoption of stateless clients and serves as a practical bridge on the path toward fully trustless verification. # Witness Model ### Architecture A witness is a service provider that issues cryptographic signatures over well-defined data objects. Witness statements may cover block identifiers, state roots, transaction inclusion claims, or application-specific data hashes. Witnesses do not provide cryptographic proofs of correctness. Instead, they provide signed attestations that can be verified by the client using the witness’s public key. The client validates the signature, the witness identity, and the structure of the attested data. Clients may query one or multiple witnesses for the same information. Trust assumptions can be reduced by requiring matching attestations from multiple independent witnesses or by enforcing threshold rules. Witness identities are explicit and enumerable. Clients decide which witnesses are acceptable and how many attestations are required. Trust decisions are therefore explicit and configurable at the client level. The Witness Protocol specifies the structure and verification of witness statements but does not define how witnesses obtain their information. Responsibility for correctness is bound to the witness identity and its signature. # Trust Enhancement ### Trust Model and Security Properties The Witness Protocol provides trust reduction, not trustlessness. A witness signature guarantees authenticity and integrity of the statement, but not objective correctness. Incorrect information can be signed; accountability is therefore tied to the witness identity. Trust can be further reduced by combining attestations from multiple witnesses and by applying quorum or threshold requirements. This limits the impact of faulty or malicious witnesses but does not eliminate trust assumptions entirely. The protocol makes trust explicit and auditable. Clients can always distinguish witness-based verification from proof-based verification and reason about the associated risk. ### Crypto-economic Extensions The Witness Protocol can be extended with crypto-economic mechanisms to further reduce trust assumptions. In such models, witnesses are required to post collateral in the form of a stake. If a witness is proven to have signed incorrect or conflicting statements, its stake can be partially or fully slashed. This introduces a strong economic disincentive against dishonest behavior. To make such systems viable, witnesses must also be compensated for correct behavior. Rewards may be paid per attestation or through aggregated mechanisms. Fees can be provided by clients or subsidized by applications relying on witness-based verification. Crypto-economic witnesses transform trust from a purely organizational assumption into an economically enforced guarantee. While this does not achieve trustlessness, it significantly increases the cost of misbehavior. # Multi-Chain Interaction Modern applications require interaction with multiple blockchains for different functionalities, such as payments, identity management, and data storage. This trend is accelerating with the increasing adoption of Layer-1 and Layer-2 solutions. Traditional synchronized and even light clients are impractical for multi-chain interaction due to their resource-intensive nature. Trusted RPC endpoints are also not a viable solution, as they require users to blindly trust responses without cryptographic verification, introducing centralization risks and potential attack vectors. Stateless and trustless clients offer a scalable and trustless alternative. As long as cryptographic proofs are available, these clients can efficiently retrieve and verify data from multiple blockchains without relying on trusted intermediaries. This approach is particularly beneficial for IoT applications, mobile applications, and web-based platforms, where devices operate under strict resource constraints but still require secure blockchain interaction. By leveraging stateless verification, blockchain-based applications can seamlessly integrate with multiple chains, ensuring efficiency, scalability, and security without unnecessary synchronization overhead. # Stateless Clients in Practice Stateless clients provide a trustless and efficient way to interact with blockchain networks, eliminating applications needing to depend on centralized or trusted endpoints for blockchain data. Instead of querying unverified data from an RPC provider, applications should always validate the correctness of blockchain information using cryptographic proofs. This shift ensures that all retrieved information is independently verifiable and prevents potential manipulation or censorship by centralized service providers. As blockchain adoption grows, applications must transition from trusted endpoints to fully trustless verification mechanisms, ensuring security and integrity across all blockchain interactions. Stateless clients are particularly well-suited for various real-world use cases where lightweight and secure blockchain verification is essential. The following sections explore their application in * web and mobile applications, * IoT, and * AI-driven asset and access management. By leveraging stateless clients, applications across multiple industries can interact with blockchain networks trustless, lightweight, and securely. As blockchain technology matures, ensuring that no application depends on trusted intermediaries will be fundamental to maintaining the integrity and decentralization of Web3 ecosystems. # Web and Mobile Applications Modern decentralized applications (dApps) frequently rely on RPC endpoints to retrieve blockchain state and transaction data. While this approach simplifies development, it introduces a trust assumption that contradicts the principles of decentralization. A stateless client provides a trustless alternative by enabling applications to fetch blockchain data from any provider while independently verifying its authenticity. * **Trustless Data Access**—Applications no longer need to trust centralized RPC services; they can verify blockchain state cryptographically. * **Efficient Verification**—Stateless clients reduce the need for heavy computation or storage on mobile devices and web browsers. * **Immediate Usability**—Unlike full nodes or traditional light clients, stateless clients do not require lengthy synchronization before providing verifiable blockchain data. This approach is particularly relevant for financial dApps, on-chain identity verification, and Web3-based authentication mechanisms, where security and trustlessness are crucial. # Internet of Things (IoT) IoT devices typically operate under severe resource constraints, including limited processing power, memory, and network bandwidth. Traditional blockchain clients require continuous synchronization and data storage, making them impractical for IoT applications. Stateless clients solve these issues by enabling IoT devices to interact with blockchain networks efficiently and trustlessly. * **Minimal Resource Consumption**—No need for IoT devices to store blockchain state or participate in network synchronization. * **Secure and Autonomous**—IoT devices can independently verify sensor data, transactions, or device access permissions without relying on centralized gateways. * **Resilience in Offline Environments**—Devices can retrieve and verify blockchain data asynchronously, making them well-suited for environments with intermittent connectivity. Use cases include supply chain management, automated smart home control, and secure machine-to-machine (M2M) transactions, where trusted interactions between decentralized devices are required. # AI Agents and Asset Management AI agents increasingly manage digital assets, control access to digital services, and even operate IoT devices. These agents may hold permission to execute financial transactions, authenticate users, or regulate access to physical devices and digital infrastructures. It is crucial to ensure that AI agents act securely within their authorized boundaries and that their permissions can be dynamically modified. Blockchain provides a trustless and decentralized method for managing these permissions. Still, for AI agents to interact securely with blockchain-based systems, they must verify data without relying on centralized intermediaries. Stateless clients enable AI-driven automation while maintaining security and accountability. * **Trustless Asset Control**—AI agents managing digital assets, such as cryptocurrency wallets, can independently validate transactions and smart contract interactions. * **Autonomous IoT Management**—AI-driven IoT controllers can verify blockchain-based policies before executing actions like unlocking devices, regulating energy usage, or managing industrial processes. * **Dynamic and Revocable Access**—Blockchain-based access management allows permissions to be assigned or revoked in real-time without relying on a central authority. * **Ensuring Compliance and Security**—AI agents operating in financial services, digital identity verification, or automated decision-making processes must adhere to predefined blockchain-enforced rules. Adopting stateless clients ensures that AI agents and IoT devices function securely and verifiably without introducing additional trust assumptions. This is essential as AI-driven automation expands into financial, industrial, and consumer applications. # Eliminating Security Risks: Attack Scenarios and Stateless Client Solutions Interacting with blockchain networks through trusted RPC providers introduces significant security risks. When applications, IoT devices, or other systems rely on centralized RPC endpoints without verifying the received data, they become vulnerable to various attack vectors. The following sections outline security risks associated with unverified blockchain data, the role of trustless stateless clients in mitigating these threats, and real-world scenarios demonstrating the impact of these risks. Stateless clients enhance security by ensuring blockchain data integrity, preventing manipulation, and eliminating trust dependencies. Replacing trusted RPC endpoints with cryptographically verifiable blockchain interactions strengthens application security and resilience against attacks. # Security Risks of Trusted RPC Endpoints Applications and devices that fetch blockchain data from a trusted RPC provider without independent verification face several threats: * **Data Manipulation Attacks**—A compromised or malicious RPC provider can return falsified blockchain state data, leading applications to act on incorrect or misleading information. * **Censorship and Selective Withholding**—An RPC provider can selectively withhold transactions, blocks, or account state data, preventing applications from accessing critical information. * **Replaying Outdated Data**—Attackers or compromised nodes can serve outdated or invalid state data, leading to incorrect balances, failed contract interactions, or security breaches. * **Sybil and Routing Attacks**—Adversaries can control multiple RPC endpoints and serve coordinated false data to deceive applications relying on centralized providers. * **Denial-of-Service (DoS) Attacks**—Targeting centralized RPC endpoints can disrupt blockchain data access for all dependent applications. * **Privacy and Data Leakage**—Unencrypted or improperly managed RPC queries can expose user addresses, transaction details, and behavior patterns to adversaries. The reliance on trusted intermediaries for blockchain interactions contradicts the fundamental principles of blockchain security, which require trustless verification mechanisms. # Trustless Stateless Clients as a Security Solution Trustless stateless clients eliminate reliance on centralized RPC providers by enabling applications to validate blockchain data independently. This enhances security in multiple ways: * **Cryptographic Data Verification**—Every retrieved data point is verified using a combination of cryptographic proofs, including Merkle proofs for execution layer data, zk-proofs for zero-knowledge validation, and consensus proofs, which ensure that the network’s consensus mechanism correctly validates the block. For Layer-2 solutions, rollup proofs are also verified to ensure data correctness. * **Censorship Resistance**—Applications can fetch data from multiple sources and verify its integrity, preventing any single provider from controlling or censoring access. * **Tamper-Proof State Retrieval**—Stateless clients ensure that received data belongs to a valid block and is signed by the correct consensus validators. * **Resistance to Data Manipulation**—A stateless client will detect inconsistencies and reject manipulated data even if an RPC provider returns incorrect information. * **Elimination of Trust Assumptions**—No entity needs to be trusted for blockchain state retrieval, ensuring true decentralization and security without reliance on third-party intermediaries. Proof-based validation ensures that applications only act on provably correct blockchain data, mitigating the risks associated with centralized RPC endpoints. It is important to note that while stateless clients address the security risks of trusted RPC endpoints, they do not solve all centralization-related issues, such as privacy concerns. However, they represent a crucial step toward building decentralized and trustless applications. # Real-World Attack Scenarios and Stateless Client Solutions The following scenarios illustrate practical attack vectors and how they are mitigated through stateless verification: #### Malicious Data Manipulation in a Financial dApp * **Attack**: A DeFi lending application queries an RPC provider for account balances. A malicious RPC server returns an inflated balance, allowing unauthorized loans. * **Mitigation**: A stateless client verifies the balance against the actual blockchain state before executing any transaction. #### IoT Device Targeted by Censorship Attack * **Attack**: A smart energy meter interacts with a blockchain-based pricing system. An RPC provider selectively withholds pricing updates to influence energy costs. * **Mitigation**: A stateless client verifies all blockchain data against cryptographic proofs, ensuring access to unaltered pricing information. #### AI Agent Exploited via Replayed Data * **Attack**: An AI-driven asset manager executes trades based on the blockchain state. An attacker intercepts and replays old transaction data to manipulate trade execution. * **Mitigation**: Stateless verification ensures the AI agent only processes transactions confirmed within the latest valid block. #### Data Privacy Breach in a Web3 Application * **Attack**: A blockchain-based identity verification service queries an RPC provider, which logs user addresses and transaction history, exposing sensitive data. * **Mitigation**: Stateless clients fetch and verify blockchain data without exposing queries to a centralized entity, maintaining privacy. #### Wallet App with Falsified Balance Data * **Attack:** A crypto wallet queries an RPC endpoint to check for incoming payments. A malicious RPC server reports a payment received that never occurred, leading the user to assume incorrectly that they have funds. * **Mitigation**: A stateless client verifies the transaction inclusion within a valid block before displaying the balance. #### Unauthorized Access to IoT-Based Digital Locks * **Attack**: A smart lock system grants access based on blockchain-based permission data. A compromised RPC provider falsely reports that an unauthorized user holds access rights. * **Mitigation**: A stateless client verifies on-chain permission states before granting access, preventing unauthorized entry. #### AI Agent Executing Unauthorized Actions * **Attack**: An AI-driven automation system has permission to control an IoT device. A manipulated RPC provider falsely indicates that the AI still has authorization, allowing it to execute commands even after revoking access. * **Mitigation**: Stateless verification ensures that permission checks are validated against the latest blockchain state, preventing unauthorized actions. #### Denial-of-Service Attack on an RPC Endpoint * **Attack**: A widespread DoS attack targets a primary RPC provider, preventing applications from accessing blockchain data. * **Mitigation**: Stateless clients can use multiple providers or direct blockchain state verification, avoiding single points of failure. #### Identity Theft in Web3 Identity Services * **Attack**: A blockchain-based identity system verifies credentials through an RPC endpoint. A malicious RPC provider falsifies identity data to allow unauthorized access. * **Mitigation**: Stateless clients ensure that identity proofs are checked directly against the blockchain without relying on a centralized RPC. #### Fraud in Web3 Gaming Platforms * **Attack**: A blockchain-based game verifies asset ownership via an RPC. A compromised provider falsely reports that a player owns rare in-game assets, allowing fraudulent transactions. * **Mitigation**: Stateless verification ensures that in-game assets are validated against the actual blockchain state before processing transactions. # Privacy Privacy is a critical concern for blockchain clients. At the same time, privacy and trustlessness are often in direct tension. Techniques that aim to hide queries, access patterns, or user intent significantly complicate proof generation and verification. In many cases, strong privacy mechanisms undermine trustlessness by reintroducing trusted intermediaries or by requiring cryptographic constructions that are currently impractical at scale. Proof-based verification requires explicit disclosure of the data being verified and its dependencies. Fully privatizing read access or execution paths while preserving verifiable correctness remains an open and costly problem. ### Privacy Dimensions Privacy concerns in blockchain client architectures can be separated into distinct dimensions, each with different threat models and mitigation strategies. #### Client–Server Privacy The service a client connects to can observe connection metadata such as IP addresses, timing information, and access patterns. This information may allow identification of users or correlation of otherwise unrelated activities. For example, repeated access from the same network location to different wallet addresses can reveal implicit relationships between those addresses. #### Read Privacy An RPC provider can observe all read requests issued by a client. From these requests, it may be possible to infer user intent. In decentralized finance workflows, preparatory reads often reveal which transactions a user is planning to submit next, enabling adversarial behavior such as frontrunning or targeted manipulation. #### Write Privacy Transaction submission leaks information as well. An RPC provider can associate outgoing transactions with a specific client or network identity before they are finalized on-chain, allowing off-chain linkage of on-chain activity. ### Risk Assessment * **Client–Server Privacy:** Users may be monitored, profiled, or linked to specific blockchain data based on network metadata. * **Read Privacy:** Observed read patterns can leak strategy, intent, or future transactions. * **Write Privacy:** Transactions can be correlated with users prior to on-chain finality. ### Existing Privacy Approaches * **Network-Level Privacy:** Onion routing networks such as Tor or mixnets such as HOPR decouple network identity from access patterns. * **Private Information Retrieval (PIR):** PIR techniques allow clients to retrieve data without revealing which item was accessed. This comes at the cost of substantial server-side computation, increased bandwidth usage, and higher latency. * **Private Transactions:** Specialized protocols enable confidential transaction submission and execution, typically by modifying transaction formats or execution semantics. ### Colibri Approach Within Colibri, privacy is not treated as a purely theoretical objective. Instead, it is evaluated from the perspective of practical deployability and operational viability. The goal is to derive privacy mechanisms that can be applied in real-world systems, across heterogeneous devices and environments, rather than relying on constructions that are theoretically sound but impractical in production. This pragmatic perspective allows Colibri to identify concrete and meaningful privacy use cases, while avoiding approaches that introduce excessive complexity, unrealistic resource requirements, or hidden trust assumptions. #### Client–Server Privacy Network-level privacy mechanisms operate at the transport layer. Onion routing or mixnets can be used transparently on top of Colibri without affecting proof generation or verification. #### Read Privacy PIR-based approaches generally require servers to process large data sets cryptographically in order to obscure which item is accessed. When combined with proof-based verification, this implies constructing and verifying proofs over large data groups, leading to prohibitive computational and latency overhead. A pragmatic approach supported by Colibri is to query provable groups of data instead of individual values. By requesting and verifying a larger, structured data set, the specific item of interest is obscured from the data provider. The final selection and interpretation are performed locally by the client. This preserves verifiability while providing partial read privacy. #### Write Privacy Colibri does not currently address transaction-level privacy. Such mechanisms operate at the protocol or application layer and are orthogonal to stateless verification. ### Privacy as a Layered Model Privacy is inherently costly. Stronger privacy guarantees require increased bandwidth, higher latency, additional computation, or explicit economic cost. Not all applications have the same privacy requirements. Colibri therefore follows a layered privacy model. Trustless verification forms the base layer. Privacy-enhancing techniques can be applied selectively on top, depending on the application’s threat model and requirements. Trustlessness is not traded for privacy; privacy is treated as an optional and explicit extension. ### Additional Privacy Techniques Several privacy techniques are frequently discussed in the context of blockchain clients. These approaches are relevant to the broader ecosystem but must be evaluated carefully with respect to trustlessness, deployability, and resource constraints. #### Trusted Execution Environments (TEE) Trusted Execution Environments can be used as an optional add-on to protect query processing and data handling on the server side. However, they introduce strong trust assumptions in hardware vendors and specific CPU architectures and are vulnerable to side-channel attacks. Colibri is designed as a general, trustless client architecture that must operate across a wide range of devices and environments. Privacy mechanisms must therefore not depend on specialized hardware or platform-specific guarantees. #### Oblivious RAM (ORAM) ORAM techniques aim to hide access patterns by continuously reshuffling data and issuing dummy accesses. While theoretically attractive, ORAM is extremely costly when applied to dynamic state machines such as Ethereum. The continuously changing global state, frequent updates, and large data volume make ORAM-based approaches impractical. In addition, ORAM requires the client to maintain and update complex position mappings, resulting in prohibitive memory, bandwidth, and computation requirements for realistic blockchain deployments. #### Private Mempools and Transaction Relays Private transaction relays and mempool-level privacy mechanisms address transaction submission and ordering. They are relevant for write privacy but do not address read privacy or state verification. These approaches are orthogonal to Colibri’s stateless verification model and are therefore not considered part of the client architecture. # Summary and Outlook ### Stateless Access as the Future of Blockchain Interaction The evolution of blockchain technology has highlighted fundamental challenges in how applications, IoT devices, and other systems access decentralized networks. This whitepaper has outlined the limitations of existing approaches, the security risks of centralized RPC endpoints, and the necessity of trustless, stateless clients for genuinely decentralized and trustless applications. #### Recap of Key Findings 1. **Challenges of Existing Blockchain Access** * Full nodes ensure complete verification but require substantial resources, making them impractical for most applications. * Light clients reduce resource requirements but still require synchronization and cannot function effectively in constrained environments such as IoT, embedded systems, or mobile and web applications. * Most applications today rely on centralized RPC providers, introducing security risks, single points of failure, and trust dependencies. 2. **The Stateless Client Model** * Stateless clients eliminate synchronization requirements and do not maintain a local copy of the blockchain state. * All retrieved data is independently verified using cryptographic proofs, including proofs for execution layer data, consensus verification, and rollup proofs for Layer-2 solutions. * This model significantly enhances security by removing the need to trust any centralized entity, ensuring censorship resistance and data integrity. 3. **Security and Attack Mitigation** * Applications relying on unverified blockchain data are vulnerable to manipulation, censorship, replay attacks, and data leaks. * Stateless clients prevent these attack vectors by ensuring all blockchain data is cryptographically validated before use. * Real-world scenarios demonstrated how trustless verification benefits financial applications, IoT devices, AI agents, and Web3 services. #### Establishing Stateless and Trustless Access as the Standard For blockchain ecosystems to fully embrace decentralization, stateless and trustless access must become a standard infrastructure component. Future developments should focus on: * **Standardization of Proof Availability** * Ensuring blockchain networks, including Ethereum and Layer-2 solutions, provide necessary proofs by default. * Expanding standards like EIP-1186 to include full-state verification mechanisms accessible to all clients. * **Integration with RPC Providers** * Transitioning RPC endpoints from centralized data sources to proof-serving nodes. * Enabling applications to request raw data and the cryptographic proofs required for validation. * **Adoption Across Multi-Chain Environments** * Stateless clients must adapt to different blockchain architectures, supporting EVM and non-EVM chains. * Expanding the capability to verify diverse consensus mechanisms and transaction models beyond Ethereum. * **Enhancing Performance and Scalability** * Implementing zk-proofs for efficient aggregation of validation steps. * Optimizing proof verification for low-resource environments, including mobile applications and IoT devices. #### The Path Forward The shift towards stateless and trustless access represents a fundamental improvement in blockchain security, usability, and decentralization. As adoption grows, it will pave the way for: * Secure and efficient IoT interactions with blockchain networks * AI-driven agents that can trustlessly verify on-chain data before executing actions * DApps that eliminate reliance on trusted RPC providers and centralized intermediaries * A fully decentralized Web3 ecosystem where all blockchain interactions are verifiable and trustless This whitepaper presents a vision for the future of blockchain access—one that ensures security, scalability, and decentralization without compromise. The industry can move beyond centralized data dependencies and achieve true blockchain sovereignty by establishing trustless stateless clients as a standard. # References ## Resources ### Technical References * [Ethereum Whitepaper](https://ethereum.org/de/whitepaper/) * [Ethereum Yellowpaper](https://ethereum.github.io/yellowpaper/paper.pdf) * EIP-1186: eth\_getProof Specification: [Ethereum Improvement Proposals](https://eips.ethereum.org/EIPS/eip-1186) * Verkle Trees and Stateless Validation: [CCN](https://www.ccn.com/news/crypto/ethereum-staking-disk-space-stateless-validators/) * Ethereum Consensus Layer Specifications: [Ethereum GitHub](https://github.com/ethereum/consensus-specs) ### Related Research Papers * Feist, D. (2021). "Why It’s So Important to Go Stateless." [Dankrad Feist Blog](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html) * Modeling Stateless Ethereum: [Consensys Research](https://consensys.io/blog/modelling-stateless-ethereum-a-journey-into-the-unknown) * L2 Scaling and Stateless Clients: [StarkNet Blog](https://www.starknet.io/blog/l2-peace-scaling-ethereum-with-vitalik-buterin-and-l2-leaders-video) ### Key Figures and Discussions * Vitalik Buterin on Stateless Clients: [Ethereum’s Future](https://m.theblockbeats.info/en/news/55469) * [The Trustless Manifesto](https://trustlessness.eth.limo/general/2025/11/11/the-trustless-manifesto.html) ### Implementation Repositories * Corpus Core Colibri Client (C4): [GitHub Repository](https://github.com/corpus-core/c4) * Ethereum Light Clients: [Ethereum GitHub](https://github.com/ethereum) * ZK-Proofs in Stateless Clients: [ZK-Rollup Implementations](https://github.com/matter-labs) * OpenVM zkVM: [GitHub Repository](https://github.com/openvm-org/openvm) * Succint SP1 zkVM: [Github Repository](https://github.com/succinctlabs/sp1) For further reading, refer to the Ethereum Foundation’s official documentation and ongoing research papers in cryptographic validation and blockchain consensus mechanisms.