Helios

• Name: Helios
• URL: https://helios.a16zcrypto.com/
• Category: Ethereum light client / trust-minimized RPC middleware / wallet-embedded verification infrastructure
• Summary: Helios is a light-client wrapper around ordinary RPC, not a replacement for it. It verifies beacon headers and execution proofs locally, then serves a local JSON-RPC so the upstream provider can still deny service but should not be able to fake supported answers. The note matters because it keeps checkpoint sourcing, proof verification, local RPC, and fallback-service trust from getting mashed into a vague trustless access story.
• What it does:
  • Runs a combined consensus-plus-execution light client in Rust that syncs from a weak-subjectivity checkpoint instead of replaying full chain history
  • Verifies beacon-chain headers using Ethereum’s light-client sync-committee mechanism, then uses those authenticated headers to check execution-layer data from an upstream RPC
  • Exposes a local JSON-RPC endpoint so wallets, apps, or users can talk to Helios as if it were a normal node while receiving verified responses for supported methods
  • Compiles into WebAssembly and is explicitly positioned as embeddable inside wallets, browser apps, and other lightweight client surfaces
  • Supports Ethereum in the core materials, with current repository docs also describing OP Stack network support (op-mainnet, base) and Linea support
  • Stores only recent checkpoint data rather than a full chain database, with the docs emphasizing small storage requirements and fast sync
• Key claims:
  • The strongest reusable insight is that Helios is not mainly trying to replace RPCs; it is trying to reframe them. The upstream execution RPC can still serve data and absorb bandwidth costs, but Helios moves correctness checks into a local verifier so the provider can deny service yet should not be able to silently manipulate supported responses.
  • The most analytically useful split is between authenticated consensus state and untrusted execution queries. The 2022 design writeup is explicit that Helios first verifies beacon headers through sync-committee signatures, then uses the authenticated state root to validate Merkle proofs for balances, storage, receipts, and other execution-layer data.
  • Weak-subjectivity checkpoint sourcing is the real trust root and therefore the real governance/control surface. The repo docs make clear that a malicious checkpoint can send the client onto the wrong chain, that old checkpoints carry theoretical attack risk, and that fallback checkpoint fetching is less secure than a trusted explicit checkpoint.
  • Helios therefore does not eliminate trusted infrastructure; it compresses trust into narrower inputs. The current docs still rely on a consensus RPC, a checkpoint, and optional fallback services, with the default consensus endpoint (lightclientdata.org) explicitly run by the Helios team and external checkpoint fallback explicitly marked insecure.
  • The local-RPC framing matters because it makes Helios legible as middleware rather than only a node binary. The project documents supported JSON-RPC methods, library embedding, and WebAssembly compilation, which means its practical distribution surface may sit inside wallets and apps more than in standalone CLI usage.
  • The repo materials also show where the current limits are. Helios depends on upstream providers exposing methods like eth_getProof, supports only a subset of JSON-RPC functionality, and ships with an explicit unaudited-use-at-your-own-risk disclaimer in the repository.
  • Helios belongs in the corpus because it sharpens a useful lower-middle layer between full nodes and blind wallet RPC trust. The key question it helps answer is where trustless access actually sits once you separate data transport, checkpoint bootstrapping, consensus verification, execution proof checking, and wallet/app embedding.
• Whitepaper: No standalone Helios whitepaper surfaced in this pass. The strongest reviewed primary materials were the official Helios site, the repository documentation, the a16z design article, and Ethereum’s light-client documentation, collected in ../whitepapers/helios-primary-sources-2026-05-15.md.
• Sources:
  • https://helios.a16zcrypto.com/
  • https://github.com/a16z/helios
  • https://raw.githubusercontent.com/a16z/helios/master/README.md
  • https://raw.githubusercontent.com/a16z/helios/master/config.md
  • https://raw.githubusercontent.com/a16z/helios/master/rpc.md
  • https://a16zcrypto.com/posts/article/building-helios-ethereum-light-client/
  • https://ethereum.org/developers/docs/nodes-and-clients/light-clients/

Internal linkages

• Browser-node contrast: openmina. OpenMina asks whether portability changes who can run a client at all; Helios keeps the full node elsewhere and verifies only what it needs.

• Lightweight-verification cousin: mithril. Useful when the question is how much trust gets compressed into checkpoints, certificates, or fallback services.

• Interop-verification analogue: blobstream-x. That note keeps the proof-serving dependency visible when authenticated commitments still arrive through operator-run delivery paths.

• Last reviewed: 2026-06-02 UTC