Charon

• Name: Charon
• URL: https://github.com/ObolNetwork/charon
• Category: Ethereum staking infrastructure / distributed validator middleware / validator-coordination client
• Tags: ethereum-ecosystem
• Summary: Charon is the concrete middleware note beneath Obol, not just another validator client. It sits between validator clients and beacon nodes, makes the cluster agree on duty data, moves partial signatures between peers, threshold-aggregates them, and broadcasts the final result back to Ethereum. That is the real control surface: duty scheduling, validator-API mediation, partial-signature transport, and aggregation policy.
• What it does:
  • Runs as an HTTP middleware layer between a validator client and a beacon node so existing validator clients can participate in a distributed validator cluster
  • Coordinates Charon peers over a P2P network to decide what duty data should be signed for a given slot before validator clients sign their local shares
  • Stores and exchanges partial signatures across cluster peers, then threshold-aggregates sufficient shares into a final beacon-valid signature
  • Exposes a validator-facing Beacon API proxy plus separate P2P and monitoring ports, making its operational boundary explicit for node operators
  • Publishes a detailed architecture and an adjacent distributed-validator specification stack covering QBFT consensus, partial-signature exchange, DKG, cluster files, validator API behavior, and duty scheduling
• Key claims:
  • The official docs describe Charon as a Go-based HTTP middleware that enables existing Ethereum validator clients to operate together as part of a distributed validator
  • The same docs say Charon clients intercept and proxy Beacon API traffic, communicate together to reach consensus on validator duties, and form a byzantine-fault-tolerant cluster that progresses with a supermajority of working and honest nodes
  • Charon’s architecture docs split the workflow into scheduler, fetcher, consensus, validator API, partial-signature exchange, signature aggregation, and broadcast phases, which is exactly why it is analytically stronger as a separate middleware entry than as a footnote under Obol
  • The public repo and architecture docs make clear that Charon batches cluster-level duties, supports multiple validator duty types, and treats the slot-scoped duty as the unit of work, which helps compare it against other validator-coordination designs rather than flattening it into generic staking software
  • Obol’s security overview links named Charon assessments by Sigma Prime and Quantstamp, which is meaningful evidence that the middleware itself is treated as a production security surface rather than a toy research client
• Whitepaper: No standalone Charon whitepaper or litepaper surfaced in this pass. The strongest primary materials were the official Charon docs, public repository, architecture docs, security overview, and Obol’s distributed-validator specifications repo; see ../whitepapers/charon-primary-sources-2026-05-12.md.
• Sources:
  • https://github.com/ObolNetwork/charon
  • https://raw.githubusercontent.com/ObolNetwork/charon/main/README.md
  • https://docs.obol.org/learn/charon/intro
  • https://raw.githubusercontent.com/ObolNetwork/charon/main/docs/architecture.md
  • https://docs.obol.org/advanced-and-troubleshooting/security/overview.md
  • https://github.com/ObolNetwork/distributed-validator-specs
  • https://raw.githubusercontent.com/ObolNetwork/distributed-validator-specs/main/README.md

Internal linkages

• Parent implementation layer beneath obol.

• Strongest external contrast: ssv-network.

• Last reviewed: 2026-05-30 UTC