{
  "$schema": "https://degreesofsatoshi.com/encyclopedia/schemas/article-v1.json",
  "schemaVersion": "1.0.0",
  "id": "ethereum-light-clients",
  "canonical": "https://degreesofsatoshi.com/encyclopedia/ethereum-light-clients/",
  "collection": "ethereum",
  "title": "Ethereum light clients: checking headers without executing every block",
  "description": "Understand how Ethereum light clients verify selected data with authenticated headers while doing less work than a full node.",
  "aliases": [
    "Ethereum light client",
    "Ethereum sync committee"
  ],
  "dates": {
    "published": "2026-10-02",
    "modified": "2026-10-02",
    "verified": "2026-10-02T19:27:58.939Z",
    "dataAsOf": "2026-10-02"
  },
  "authorship": {
    "publisher": "Degrees of Satoshi editorial project",
    "process": "AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied."
  },
  "quickAnswer": {
    "text": "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.",
    "claimId": "ethereum-light-clients-quick-answer",
    "sourceIds": [
      "x425-eth-eth-light",
      "x425-eth-eth-weak"
    ]
  },
  "keyFacts": [
    {
      "label": "Reduced work",
      "value": "Light clients obtain selected data instead of maintaining full local execution state.",
      "sourceIds": [
        "x425-eth-eth-light"
      ],
      "id": "reduced-work",
      "claimId": "ethereum-light-clients-fact-reduced-work"
    },
    {
      "label": "Authentication",
      "value": "Consensus light clients use sync-committee information to follow headers.",
      "sourceIds": [
        "x425-eth-eth-light"
      ],
      "id": "authentication",
      "claimId": "ethereum-light-clients-fact-authentication"
    },
    {
      "label": "Scope",
      "value": "Different implementations verify different execution-layer data.",
      "sourceIds": [
        "x425-eth-eth-light"
      ],
      "id": "scope",
      "claimId": "ethereum-light-clients-fact-scope"
    }
  ],
  "prerequisites": [
    "ethereum-nodes-rpc"
  ],
  "sections": [
    {
      "id": "verification",
      "heading": "Ask which answer is checked",
      "sourceIds": [
        "x425-eth-eth-light"
      ],
      "paragraphs": [
        "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."
      ]
    },
    {
      "id": "example",
      "heading": "A balance proof and a price quote are different",
      "sourceIds": [
        "x425-eth-eth-light",
        "x425-eth-eth-jsonrpc"
      ],
      "paragraphs": [
        "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."
      ]
    },
    {
      "id": "tradeoffs",
      "heading": "Less local work introduces other dependencies",
      "sourceIds": [
        "x425-eth-eth-light",
        "x425-eth-eth-weak"
      ],
      "paragraphs": [
        "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."
      ]
    }
  ],
  "faq": [
    {
      "question": "Is any wallet using a remote RPC endpoint a light client?",
      "answer": "No. A wallet that accepts unverified responses is relying on that provider. A light client must perform the relevant authenticated verification.",
      "sourceIds": [
        "x425-eth-eth-light"
      ]
    },
    {
      "question": "Can a light client force a provider to return missing data?",
      "answer": "No. Verification can reject incorrect supplied data, but availability still depends on obtaining the necessary information from a reachable source.",
      "sourceIds": [
        "x425-eth-eth-light"
      ]
    }
  ],
  "claims": [
    {
      "id": "ethereum-light-clients-quick-answer",
      "articleSlug": "ethereum-light-clients",
      "statement": "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.",
      "sourceIds": [
        "source-4b82943838e3c2ce",
        "source-92ecd648d0893a8f"
      ],
      "sourceLocators": [
        {
          "sourceId": "source-4b82943838e3c2ce",
          "locator": "Light clients; sync committees; data verification"
        },
        {
          "sourceId": "source-92ecd648d0893a8f",
          "locator": "Weak subjectivity checkpoints; long-range attacks"
        }
      ],
      "scope": {
        "collection": "ethereum",
        "dataAsOf": "2026-10-02",
        "blockHeight": null
      },
      "qualification": "",
      "evidenceStatus": "documented",
      "verification": {
        "status": "verified",
        "method": "independent automated source review",
        "checkedAt": "2026-10-02T19:27:58.939Z",
        "reviewer": "Independent automated verification agent verify_bitcoin_stablecoins_100",
        "notes": [
          "Read light-client architecture, sync committees and balance-proof example. Draft correctly scopes verification to supported responses and trustworthy bootstrap, distinguishes correctness from availability, and avoids source’s stale claim that none of the named implementations are production-ready."
        ]
      }
    },
    {
      "id": "ethereum-light-clients-fact-reduced-work",
      "articleSlug": "ethereum-light-clients",
      "statement": "Reduced work: Light clients obtain selected data instead of maintaining full local execution state.",
      "sourceIds": [
        "source-4b82943838e3c2ce"
      ],
      "sourceLocators": [
        {
          "sourceId": "source-4b82943838e3c2ce",
          "locator": "Light clients; sync committees; data verification"
        }
      ],
      "scope": {
        "collection": "ethereum",
        "dataAsOf": "2026-10-02",
        "blockHeight": null
      },
      "qualification": "",
      "evidenceStatus": "documented",
      "verification": {
        "status": "verified",
        "method": "independent automated source review",
        "checkedAt": "2026-10-02T19:27:58.939Z",
        "reviewer": "Independent automated verification agent verify_bitcoin_stablecoins_100",
        "notes": [
          "Read light-client architecture, sync committees and balance-proof example. Draft correctly scopes verification to supported responses and trustworthy bootstrap, distinguishes correctness from availability, and avoids source’s stale claim that none of the named implementations are production-ready."
        ]
      }
    },
    {
      "id": "ethereum-light-clients-fact-authentication",
      "articleSlug": "ethereum-light-clients",
      "statement": "Authentication: Consensus light clients use sync-committee information to follow headers.",
      "sourceIds": [
        "source-4b82943838e3c2ce"
      ],
      "sourceLocators": [
        {
          "sourceId": "source-4b82943838e3c2ce",
          "locator": "Light clients; sync committees; data verification"
        }
      ],
      "scope": {
        "collection": "ethereum",
        "dataAsOf": "2026-10-02",
        "blockHeight": null
      },
      "qualification": "",
      "evidenceStatus": "documented",
      "verification": {
        "status": "verified",
        "method": "independent automated source review",
        "checkedAt": "2026-10-02T19:27:58.939Z",
        "reviewer": "Independent automated verification agent verify_bitcoin_stablecoins_100",
        "notes": [
          "Read light-client architecture, sync committees and balance-proof example. Draft correctly scopes verification to supported responses and trustworthy bootstrap, distinguishes correctness from availability, and avoids source’s stale claim that none of the named implementations are production-ready."
        ]
      }
    },
    {
      "id": "ethereum-light-clients-fact-scope",
      "articleSlug": "ethereum-light-clients",
      "statement": "Scope: Different implementations verify different execution-layer data.",
      "sourceIds": [
        "source-4b82943838e3c2ce"
      ],
      "sourceLocators": [
        {
          "sourceId": "source-4b82943838e3c2ce",
          "locator": "Light clients; sync committees; data verification"
        }
      ],
      "scope": {
        "collection": "ethereum",
        "dataAsOf": "2026-10-02",
        "blockHeight": null
      },
      "qualification": "",
      "evidenceStatus": "documented",
      "verification": {
        "status": "verified",
        "method": "independent automated source review",
        "checkedAt": "2026-10-02T19:27:58.939Z",
        "reviewer": "Independent automated verification agent verify_bitcoin_stablecoins_100",
        "notes": [
          "Read light-client architecture, sync committees and balance-proof example. Draft correctly scopes verification to supported responses and trustworthy bootstrap, distinguishes correctness from availability, and avoids source’s stale claim that none of the named implementations are production-ready."
        ]
      }
    }
  ],
  "sources": [
    {
      "id": "x425-eth-eth-light",
      "label": "Ethereum light clients",
      "publisher": "ethereum.org contributors",
      "url": "https://ethereum.org/en/developers/docs/nodes-and-clients/light-clients/",
      "locator": "Light clients; sync committees; data verification",
      "note": "Authenticated headers and limited-resource verification differ from full execution.",
      "version": "Documentation snapshot retrieved 2 October 2026; response hash recorded separately",
      "checkedAt": "2026-10-02T18:55:26.812Z",
      "contentSha256": "890152f7ed941a57b3bc4f61e6f2e817861cb2aa4e40bcd1f6126dc26c57394b",
      "recordId": "source-4b82943838e3c2ce"
    },
    {
      "id": "x425-eth-eth-weak",
      "label": "Proof-of-stake weak subjectivity",
      "publisher": "ethereum.org contributors",
      "url": "https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/weak-subjectivity/",
      "locator": "Weak subjectivity checkpoints; long-range attacks",
      "note": "Recent trusted checkpoints anchor a newly syncing or long-offline node.",
      "version": "Documentation snapshot retrieved 2 October 2026; response hash recorded separately",
      "checkedAt": "2026-10-02T18:55:26.785Z",
      "contentSha256": "201fe38fc2a38c29383043a7d70a147901f4db3653e71d2490e71662335396bc",
      "recordId": "source-92ecd648d0893a8f"
    },
    {
      "id": "x425-eth-eth-jsonrpc",
      "label": "Ethereum JSON-RPC API",
      "publisher": "ethereum.org contributors",
      "url": "https://ethereum.org/en/developers/docs/apis/json-rpc/",
      "locator": "eth_getBalance; eth_getTransactionReceipt; block parameter; logs",
      "note": "RPC requests explicitly identify addresses and block scope; receipts and removed log fields support verification examples.",
      "version": "Documentation snapshot retrieved 2 October 2026; response hash recorded separately",
      "checkedAt": "2026-10-02T18:55:24.990Z",
      "contentSha256": "ed13997ec4f415dff80883add0730d4e64bcc8c17b95dd4f6c27aed0241a4073",
      "recordId": "source-a5154b4118a3d15f"
    }
  ],
  "related": {
    "articles": [
      "ethereum-nodes-rpc",
      "ethereum-proof-of-stake-finality",
      "ethereum-archive-nodes",
      "ethereum-weak-subjectivity"
    ],
    "dossiers": [],
    "wallets": []
  },
  "revisionHistory": [
    {
      "date": "2026-10-02",
      "kind": "published",
      "summary": "First publication after primary-source research and separate automated verification."
    }
  ],
  "citation": "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/"
}