# Ethereum light clients: checking headers without executing every block An Ethereum light client follows authenticated chain information and checks supported proofs instead of independently executing and storing everything a full node does. This can reduce hardware needs and blind trust in a data provider. Its guarantees depend on the light-client protocol, bootstrap information and which responses it actually verifies; using a small wallet app alone does not make it a light client. Evidence: [Ethereum light clients](https://ethereum.org/en/developers/docs/nodes-and-clients/light-clients/); [Proof-of-stake weak subjectivity](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) Canonical: https://degreesofsatoshi.com/encyclopedia/ethereum-light-clients/ Published: 2026-10-02 Substantively modified: 2026-10-02 Independently verified by an automated reviewer: 2026-10-02T19:27:58.939Z Data current through: 2026-10-02 AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied. ## Key facts - **Reduced work:** Light clients obtain selected data instead of maintaining full local execution state. ([Ethereum light clients](https://ethereum.org/en/developers/docs/nodes-and-clients/light-clients/)) - **Authentication:** Consensus light clients use sync-committee information to follow headers. ([Ethereum light clients](https://ethereum.org/en/developers/docs/nodes-and-clients/light-clients/)) - **Scope:** Different implementations verify different execution-layer data. ([Ethereum light clients](https://ethereum.org/en/developers/docs/nodes-and-clients/light-clients/)) ## Ask which answer is checked A provider can supply a balance together with a proof tied to a state root. A suitable light client can check that proof against authenticated chain information, reducing reliance on the provider’s bare assertion. That does not mean every RPC response automatically gains the same verification. The implementation must support the proof and connect it to the intended chain state. Evidence: [Ethereum light clients](https://ethereum.org/en/developers/docs/nodes-and-clients/light-clients/) ## A balance proof and a price quote are different Suppose a wallet verifies an account balance proof against an authenticated block header. That supports a statement about the account’s balance at that state. It does not verify an unrelated website’s exchange-rate quote or the future behavior of an application. Use the light client’s documented verification boundary. A checked blockchain response should not become an endorsement of everything shown beside it. Evidence: [Ethereum light clients](https://ethereum.org/en/developers/docs/nodes-and-clients/light-clients/); [Ethereum JSON-RPC API](https://ethereum.org/en/developers/docs/apis/json-rpc/) ## Less local work introduces other dependencies Light clients still need data providers and a correct way to establish the chain they are following. A provider can fail to respond even when it cannot forge a proof the client accepts. Correctness and availability remain different properties. A full node independently executes more of the chain’s rules and retains more data. Choose based on the actual guarantees and resource needs, not the label alone. Evidence: [Ethereum light clients](https://ethereum.org/en/developers/docs/nodes-and-clients/light-clients/); [Proof-of-stake weak subjectivity](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) ## Questions ### Is any wallet using a remote RPC endpoint a light client? No. A wallet that accepts unverified responses is relying on that provider. A light client must perform the relevant authenticated verification. Evidence: [Ethereum light clients](https://ethereum.org/en/developers/docs/nodes-and-clients/light-clients/) ### Can a light client force a provider to return missing data? No. Verification can reject incorrect supplied data, but availability still depends on obtaining the necessary information from a reachable source. Evidence: [Ethereum light clients](https://ethereum.org/en/developers/docs/nodes-and-clients/light-clients/) ## Claims and scope ### ethereum-light-clients-quick-answer An Ethereum light client follows authenticated chain information and checks supported proofs instead of independently executing and storing everything a full node does. This can reduce hardware needs and blind trust in a data provider. Its guarantees depend on the light-client protocol, bootstrap information and which responses it actually verifies; using a small wallet app alone does not make it a light client. Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null} ### ethereum-light-clients-fact-reduced-work Reduced work: Light clients obtain selected data instead of maintaining full local execution state. Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null} ### ethereum-light-clients-fact-authentication Authentication: Consensus light clients use sync-committee information to follow headers. Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null} ### ethereum-light-clients-fact-scope Scope: Different implementations verify different execution-layer data. Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null} ## Sources - [Ethereum light clients](https://ethereum.org/en/developers/docs/nodes-and-clients/light-clients/) — ethereum.org contributors. Authenticated headers and limited-resource verification differ from full execution. Locator: Light clients; sync committees; data verification. Retrieved: 2026-10-02T18:55:26.812Z. - [Proof-of-stake weak subjectivity](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) — ethereum.org contributors. Recent trusted checkpoints anchor a newly syncing or long-offline node. Locator: Weak subjectivity checkpoints; long-range attacks. Retrieved: 2026-10-02T18:55:26.785Z. - [Ethereum JSON-RPC API](https://ethereum.org/en/developers/docs/apis/json-rpc/) — ethereum.org contributors. RPC requests explicitly identify addresses and block scope; receipts and removed log fields support verification examples. Locator: eth_getBalance; eth_getTransactionReceipt; block parameter; logs. Retrieved: 2026-10-02T18:55:24.990Z. ## Revision history - 2026-10-02: First publication after primary-source research and separate automated verification. ## Cite this entry Degrees of Satoshi editorial project. “Ethereum light clients: checking headers without executing every block.” Published 2026-10-02; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/ethereum-light-clients/