Stateless Client

What Is a Stateless Client?

A stateless client is a blockchain node that trustlessly verifies new blocks without maintaining a local copy of the chain's full state. In Ethereum's context, state includes every account balance, nonce, contract code, and storage slot. In Bitcoin's context, state refers to the UTXO set: the collection of all unspent transaction outputs.

Rather than looking up this data in its own database, a stateless client receives a "witness" with each block. The witness contains the specific state values that the block's transactions access, along with a cryptographic proof that those values are correct. The node verifies the proof, executes the transactions, and updates only a single 32-byte state root hash.

The name is slightly misleading: the client is not truly stateless, since it still tracks the latest state root. The key insight is that it does not need the full state database to validate blocks. This distinction is what separates a stateless client from a full node, which must store the entire current state.

How It Works

In a traditional full node, block validation works by reading state values from a local database, executing transactions against those values, and writing back the updated state. The node must store every piece of state that any transaction might access.

A stateless client replaces this local database lookup with proof verification:

1. A block proposer (who does maintain full state) produces a new block along with a witness
2. The witness contains every state value the block's transactions read or write, plus a cryptographic proof linking those values to the state root in the previous block header
3. The stateless client verifies the proof against the known state root
4. If valid, it executes the transactions using the witnessed values
5. It computes the new state root from the resulting state changes and advances to the next block

The stateless client never stores the underlying state. It only stores the state root: a single hash that commits to the entire state tree.

The Witness Size Problem

The practical challenge is witness size. Under Ethereum's current hexary Merkle Patricia Trie, proving a single account access requires all sibling nodes along the path from leaf to root, averaging roughly 3 KB per access. A typical Ethereum block touches up to 6,000 state elements, making worst-case witness sizes reach approximately 18 MB: far too large to propagate within Ethereum's 12-second slot time.

This is why stateless validation has been discussed for years but not yet deployed. The data structure used to organize state must produce compact proofs.

Verkle Trees and Beyond

Verkle trees were originally proposed as the solution. Using polynomial commitment schemes (specifically Pedersen commitments on the Bandersnatch elliptic curve), Verkle trees allow many individual proofs to be aggregated into a single compact multiproof. For approximately 1,000 state accesses, a Verkle witness is roughly 150 KB compared to 3.5 MB under the Merkle Patricia Trie: a 23x reduction.

In early 2026, Ethereum's roadmap shifted further. Vitalik Buterin proposed skipping Verkle trees entirely in favor of binary hash trees with STARK proofs (codified in EIP-7864). Binary trees are simpler (binary branching versus 256-way), quantum-resistant (relying only on hash function security rather than elliptic curves), and can compress witnesses to under 25 KB using recursive STARKs. This approach is now the leading candidate for Ethereum's Hegota upgrade, planned for the second half of 2026.

Weak vs Full Statelessness

Two variants of statelessness exist, and the distinction matters for practical deployment:

• Weak (partial) statelessness: block proposers still maintain the full state and generate witnesses. All other validators verify blocks using witnesses without storing state. This is Ethereum's current target because it does not require transaction senders to provide their own proofs.
• Full statelessness: no node stores the complete state. Transaction senders must include witnesses with their transactions, proving the state their transaction accesses. This is significantly more complex, especially for smart contract interactions, and is not part of Ethereum's near-term roadmap.

Stateless Clients vs Other Node Types

Stateless clients occupy a unique position in the spectrum of node types. They achieve the trustless validation of a full node with the hardware footprint closer to a light client:

A pruned node discards old block data but still stores the full current state, so its storage requirements remain substantial. A light client has low hardware needs but sacrifices trustless validation: it relies on full nodes to provide honest data. A stateless client gets the best of both: trustless validation on minimal hardware.

Stateless Validation on Bitcoin

Bitcoin's approach to stateless validation differs from Ethereum's because Bitcoin uses the UTXO model rather than an account model. The primary proposal is Utreexo, created by Tadge Dryja (co-inventor of the Lightning Network) at MIT's Digital Currency Initiative.

Utreexo replaces Bitcoin's UTXO set with a cryptographic accumulator: a forest of perfect binary Merkle trees. Instead of storing all unspent outputs (roughly 11 GB for approximately 173 million UTXOs), a Utreexo node stores only the tree roots: approximately 456 bytes. This represents a compression ratio of roughly 25 million to one.

When a Utreexo node needs to verify a transaction, it receives a Merkle inclusion proof showing that the spent UTXOs exist in the accumulator. Bridge nodes maintain the full Merkle forest and generate these proofs. Because the proofs are cryptographically self-authenticating, the system remains trustless.

// Utreexo storage comparison
Full UTXO set:     ~11 GB  (173M UTXOs)
Utreexo roots:     ~456 bytes (14 roots × 32 bytes + 8-byte counter)

// Per-block proof overhead
Block relay:       ~1.7x original block size
Transaction relay: up to ~4x per transaction (worst case)

Implementations like Floresta (Rust) have demonstrated fully validating Bitcoin nodes running on a Raspberry Pi Zero 2W with only 512 MB of RAM and roughly 800 MB of disk space. Three draft BIPs (181, 182, 183) were submitted in August 2025 to formalize the accumulator structure, validation rules, and P2P protocol extensions. For a deeper exploration, see the Utreexo node scaling research.

Why It Matters

State bloat is one of the most persistent challenges in blockchain design. As blockchains accumulate more accounts, contracts, and storage, the hardware requirements for running a full node grow continuously. Running an Ethereum full node currently requires a 2 TB NVMe SSD with state growing at roughly 14 GB per week. For Bitcoin, the UTXO set has grown past 11 GB with no built-in expiry mechanism.

This growth directly threatens decentralization. Fewer people can afford the hardware, and the network concentrates among those who can. Stateless clients break this dynamic by decoupling validation from storage. If every mobile wallet and browser extension could verify blocks trustlessly, the validator set expands by orders of magnitude.

For Layer 2 protocols and payment networks like Spark, stateless validation on the base layer strengthens the security foundation. Users who can independently verify Layer 1 state do not need to trust intermediaries when entering or exiting Layer 2 systems.

Risks and Considerations

Witness Availability

A stateless client cannot validate a block without its witness. If block proposers fail to include witnesses or the witness data is corrupted, stateless validators cannot proceed. Under weak statelessness, this risk is mitigated because proposers are incentivized to produce valid witnesses, but it introduces a dependency that full nodes do not have.

Increased Bandwidth Requirements

Witnesses add data to every block. Even with compact proof schemes, Utreexo adds roughly 70% to block relay sizes on Bitcoin, and Verkle witnesses add approximately 150 KB per Ethereum block. Nodes trade storage requirements for bandwidth requirements. For resource-constrained devices on slow connections, this tradeoff may not always be favorable.

Proposer Centralization

Under weak statelessness, block proposers must still store the full state. This could concentrate the proposer role among well-resourced operators, even as the validator role becomes more accessible. Ethereum's proposer-builder separation architecture is designed to mitigate this, separating block construction from block validation.

Transition Complexity

Migrating a live network's state tree structure requires careful coordination. For Ethereum, switching from the Merkle Patricia Trie to a new tree format means converting billions of state entries while the network continues operating. The scope of this migration, combined with the recent pivot from Verkle to binary trees, has pushed deployment timelines into late 2026 or beyond.

Limited State Queries

A stateless client can validate blocks but cannot answer arbitrary state queries (such as "what is the balance of address X?") without receiving a witness for that specific query. Applications that need to read state on demand, like block explorers or RPC providers, still require full state storage or access to a stateful node.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.