【Network Introduction】Obol Network

12 Mins read

Network Detail

Brief Introduction

The Obol Network is an ecosystem for trust minimized staking that enables people to create, test, run & co-ordinate distributed validators.

Obol Labs is a research and software development team focused on proof-of-stake infrastructure for public blockchain networks. Specific topics of focus are Internet Bonds, Distributed Validator Technology and Multi-Operator Validation. The team currently includes 10 members that are spread across the world. The core team is building the Obol Network, a protocol to foster trust minimized staking through multi-operator validation. This will enable low-trust access to Ethereum staking yield, which can be used as a core building block in a variety of Web3 products.




Collin Myers, former head of global product strategy at ConsenSys, has been working on a new project since April of last year. He is building a “trust-minimized” crypto staking protocol at his startup Obol Technologies. Myers, founder and CEO of Obol, said the project has raised $6.15 million in a seed funding round. With fresh capital at hand, Obol plans to expand its team of three members to around 12.

Core Public Products

The Distributed Validator Launchpad, a CLI tool and dApp for bootstrapping Distributed Validators;

Charon, a middleware client that enables validators to run in a fault-tolerant, distributed manner;

Obol Managers, a set of solidity smart contracts for the formation of Distributed Validators;

Obol Testnets, a set of on-going public incentivised testnets that enable any sized operator to test their deployment before serving for the mainnet Obol Network.


V1 — Trusted Distributed Validators

The first version of distributed validators will have dispute resolution out of band. Meaning you need to know and communicate with your counterparty operators if there is an issue with your shared cluster. A DV without in-band dispute resolution/incentivisation is still extremely valuable. Individuals and staking as a service provider can deploy DVs on their own to make their validators fault tolerant. Groups can run DVs together, but need to bring their own dispute resolution to the table, whether that be a smart contract of their own, a traditional legal service agreement, or simply high trust between the group. Obol V1 will utilize retroactive public goods principles to lay the foundation of its economic ecosystem. The Obol Community will responsibly allocate the collected ETH as grants to projects in the staking ecosystem for the entirety of V1.

V2 — Trustless Distributed Validators

V1 of charon serves a small by count, large by stake-weight group of individuals. The long tail of home and small stakers also deserve to have access to fault tolerant validation, but they may not know enough other operators personally to a sufficient level of trust to run a DV cluster together. Version 2 of charon will layer in an incentivisation scheme to ensure any operator not online and taking part in validation is not earning any rewards. Further incentivisation alignment can be achieved with operator bonding requirements that can be slashed for unacceptable performance. To add an un-gameable incentivisation layer to threshold validation requires complex interactive cryptography schemes, secure off-chain dispute resolution, and EVM support for proofs of the consensus layer state, as a result, this will be a longer and more complex undertaking than V1, hence the delineation between the two.


Geographic Redundancy

Existing validators have a single point of failure. Only one validator client instance can be online and signing messages at any time. If two validators with the same private key sign conflicting messages the validator will be slashed.

Key Distribution

Distributed Validator Clusters share one private key, no single node in the cluster has the full private key, and the full private key never exists in full anywhere. This makes validator key compromise more difficult for an attacker.

Fault Tolerance

Distributed Validator Clusters require only a subset of nodes to be online to produce signatures. This allows for fault-tolerant validators to be built, and allows a Distributed Validator to remain online despite hardware failure.





Obol Technologies, founded by former ConsenSys exec Collin Myers, has raised $6.15 million in a seed funding round to build a crypto staking protocol. The round was led by Ethereal Ventures, a venture fund set up by ConsenSys founder Joseph Lubin, with participation from Coinbase Ventures, Acrylic Capital, and many others. Furthermore, Lido provided a $100,000 LDO grant to Obol to continue researching and building the protocol. (Lido is currently the largest liquid staking provider on Ethereum.)



The Obol network is utilizing secret shared validator (SSV) technology, a primitive conceptualized in collaboration with researchers at the Ethereum Foundation. SSV helps split a validator key (effectively the password for operating a validator) between multiple operators. A validator is similar to a miner on a proof-of-work network, but one that stakes funds in order to process transactions on a proof-of-stake network.

Obol as a layer is focused on scaling consensus by providing permissionless access to Distributed Validators (DV’s). They believe that DV’s will and should make up a large portion of mainnet validator configurations. In preparation for the first wave of adoption the network currently utilizes a middleware implementation of Distributed Validator Technology (DVT), to enable the operation of distributed validator clusters that can preserve validators current client and remote signing configurations.

HTTP Middleware-Charon

Charon is a GoLang-based, HTTP middleware built by Obol to enable any existing Ethereum validator clients to operate together as part of a distributed validator. Charon sits as a middleware between a normal validating client and its connected beacon node, intercepting and proxying API traffic. Multiple Charon clients are configured to communicate together to come to consensus on validator duties and behave as a single unified proof-of-stake validator together. The nodes form a cluster that is byzantine-fault tolerant and continues to progress assuming a supermajority of working/honest nodes is met. The below graphic visually outlines the internal functionality of Charon:

Obol Manager Contracts

Obol develops and maintains a suite of smart contracts for use with Distributed Validators.

Withdrawal Recipients: The key to a distributed validator is understanding how a withdrawal is processed. The most common way to handle a withdrawal of a validator operated by a number of different people is to use an immutable withdrawal recipient contract, with the distribution rules hardcoded into it.

For the time being Obol uses 0x01 withdrawal credentials, and intends to upgrade to 0x03 withdrawal credentials when smart contract initiated exits are enabled.


Deposit Registry: The Deposit Registry is a way for the deposit and activation of distributed validators to be two separate processes. In the simple case for DVs, a registry of deposits is not required. However when the person depositing the ether is not the same entity as the operators producing the deposits, a coordination mechanism is needed to make sure only one 32 eth deposit is submitted per DV. A deposit registry can prevent double deposits by ordering the allocation of ether to validator deposits.

Operator Registry: If the submission of deposits to a deposit registry needs to be gated to only whitelisted addresses, a simple operator registry may serve as a way to control who can submit deposits to the deposit registry.

Validator Registry: If validators need to be managed on chain programmatically rather than manually with humans triggering exits, a validator registry can be used. Deposits getting activated get an entry into the validator registry, and validators using 0x03 exits get staged for removal from the registry. This registry can be used to coordinate many validators with similar operators and configurations.


The following is a breakdown of the intended testnet roadmap, the features that are to be completed by each testnet, and their target start date and durations.

Devnet 1

The first devnet aimed to have a number of trusted operators test out our earliest tutorial flows. The aim was for a single user to complete these tutorials alone, using docker compose to spin up 4 charon clients and 4 different validator clients (lighthouse, teku, lodestar and vouch) on a single machine, with a remote consensus client. The keys were created locally in charon, and activated with the existing launchpad.

Participants: Obol Dev Team, Client team advisors.

State: Pre-product

Network: Kiln

Completed Date: June 2022

Duration: 1 week

Goals: Users test a first tutorial flow to get the kinks out of it. Devnet 2 will be a group flow, so we need to get the solo flow right first;

Prove the distributed validator paradigm with 4 separate VC implementations together operating as one logical validator works;

Get the basics of monitoring in place, for the following testnet where accurate monitoring will be important due to charon running across a network.

Responding to a typeform, an operator will list:

The public key of the distributed validator;

Any difficulties they incurred in the cluster instantiation;

Any deployment variations they would like to see early support for (e.g. windows, cloud, dappnode etc.).

Devnet 2

The second devnet aimed to have a number of trusted operators test out our earliest tutorial flows together for the first time. The aim was for groups of 4 testers to complete a group onboarding tutorial, using docker compose to spin up 4 charon clients and 4 different validator clients (lighthouse, teku, lodestar and vouch), each on their own machine at each operators home or their place of choosing, running at least a kiln consensus client. As part of this testnet, operators avoided exposing charon to the public internet on a static IP address through the use of Obol hosted relay nodes. This devnet was also the first time charon dkg was tested with users.

The launchpad was not used, and this dkg was triggered by a manifest config file created locally by a single operator using the charon create dkg command. A core focus of this devnet was to collect network performance data. This was the first time charon was run in variable, non-virtual networks (i.e. the real internet). Focusing on effective collection of performance data in this devnet was a core focus, to enable gathering even higher signal performance data at scale during public testnets.

Participants: Obol Dev Team, Client team advisors.

State: Pre-product

Network: Kiln

Completed Date: July 2022

Duration: 2 weeks

Goals: User test a first dkg flow;

User test the complexity of exposing charon to the public internet;

Have block proposals in place;

Build up the analytics plumbing to ingest network traces from dump files or distributed tracing endpoints.

Athena Public Testnet 1

Registration Form:

With tutorials for solo and group flows having been developed and refined. The goal for public testnet 1 is to get distributed validators into the hands of the wider Proto Community for the first time. The core focus of this testnet is the onboarding experience. This is the first time Obol would need to provide comprehensive instructions for as many platforms (Unix, Mac, Windows) in as many languages as possible (need to engage language moderators on discord).

The core output from this testnet is a large number of typeform submissions, for a feedback form we have refined since devnets 1 and 2. This will be an incentivised testnet, and will form as the basis for us figuring out a sybil resistance mechanism for later incentivised testnets.

Participants: Obol Proto Community

State: Bare Minimum

Network: Görli

Target start date: August 2022

Duration: 2 week cluster setup, 4 weeks operation

Goals: Engage Obol Proto Community;

Make deploying Ethereum validator nodes accessible;

Generate a huge backlog of bugs, feature requests, platform requests and integration requests.

Bia Attack Net

At this point, Obol has tested best-effort, happy-path validation with supportive participants. The next step towards a mainnet ready client is to begin to disrupt and undermine it as much as possible.

This testnet needs a consensus implementation as a hard requirement, where it may have been optional for Athena. The intention is to create a number of testing tools to facilitate the disruption of charon, including releasing a p2p network abuser, a fuzz testing client, k6 scripts for load testing/hammering an RPC endpoints and more. The aim is to find as many memory leaks, DoS vulnerable endpoints and operations, missing signature verifications and more. This testnet may be centered around a hackathon if suitable.

Participants: Obol Proto Community, Immunefi Bug Bounty searchers

State: Client Hardening

Network: Kiln or a Merged Test Network (e.g. Görli)

Target start date: September 2022

Duration: 2–4 weeks operation, depending on how resilient the clients are

Network: Merged Test Network (e.g. Görli)

Goals: Break charon in multiple ways;

Improve DoS resistance;

Cerce Public Testnet II

After working through the vulnerabilities hopefully surfaced during the attack net, it becomes time to take the stakes up a notch. The second public testnet for Obol will be in partnership with the Gnosis Chain, and will use validators with real skin in the game.

This is intended to be the first time that Distributed Validator tokenisation comes into play. Obol intends to let candidate operators form groups, create keys that point to pre-defined Obol controlled withdrawal addresses, and submit a typeform application to our testnet team including their created deposit data and manifest lockfile and exit data. (So we can verify the validator pubkey they are submitting is a DV). Once the testnet team has verified the operators as real humans not sybil attacking the testnet that have created legitimate DV keys, their validator will be activated with Obol GNO. At the end of the testnet period, all validators will be exited, and their performance will be judged to decide the incentivisation they will receive.

Participants: Obol Proto Community, Gnosis Community, Ethereum Staking Community

State: MVP

Network: Merged Gnosis Chain

Target start date: Q4 2022

Duration: 6 weeks

Network: Merged Gnosis Chain

Goals: Broad community participation;

First Obol Incentivised Testnet;

Distributed Validator returns competitive versus single validator clients;

Run an unreasonably large percentage of an incentivised test network to see the network performance at scale if a majority of validators moved to DV architectures.

Demeter Red/Blue Net

The final planned testnet before a prospective look at mainnet deployment is a testnet that takes inspiration for the Cyber Security industry and makes use of Red Teams and Blue Teams. In Cyber Security, the Red team is on offense, and the Blue team is on defense. In Obol’s case, Operators will be grouped into clusters based on application and are assigned to either red team or blue team in secret. Once the validators are active, it will be the red team’s goal to disrupt the cluster to the best of their ability, and their rewards will be based on how much worse the cluster performs than optimal.

The blue team members will aim to keep their cluster online and signing. If they can keep their distributed validator online for the majority of time despite the red team’s best efforts, they will receive an outsized reward versus the red team reward. The aim of this testnet is to show that even with directly incentivised byzantine actors, that a distributed validator client can remain online and timely in its validation, further cementing trust in the clients mainnet readiness.

Participants: Obol Proto Community, Gnosis Community, Ethereum Staking Community, Immunefi Bug Bounty searchers

State: Mainnet ready

Network: Merged Gnosis Chain

Target start date: Q4 2022

Duration: 4 weeks

Network: Merged Gnosis Chain

Goals: Even with incentivised byzantine actors, distributed validators can reliably stay online;

Charon nodes cannot be DoS’d;

Demonstrate that fault tolerant validation is real, safe and cost competitive;

Charon is feature complete and ready for audit.

Validator (Node)


The Obol network will essentially allow staking with multiple validator operators. The longer term vision here is to prevent single operator failure, so in the future, like if one individual staking provider or two or three providers go down, the Ethereum network should still continue to finalize and it should still continue to validate.

Distributed Validator

A distributed validator is an Ethereum proof-of-stake validator that runs on more than one node/machine. This functionality is provided by Distributed Validator Technology (DVT). Distributed validator technology removes the problem of single-point failure. Should ❤3% of the participating nodes in the DVT cluster go offline, the remaining active nodes are still able to come to consensus on what to sign and produce valid signatures for their staking duties. This is known as Active/Active redundancy, a common pattern for minimizing downtime in mission critical systems.​

Distributed Validator Node

A distributed validator node is the set of clients an operator needs to configure and run to fulfill the duties of a Distributed Validator Operator. An operator may also run redundant execution and consensus clients, an execution payload relayer like mev-boost, or other monitoring or telemetry services on the same hardware to ensure optimal performance. In the above example, the stack includes geth, lighthouse, charon and lodestar.

Distributed Validator Client

A distributed validator client intercepts the validator client ↔ consensus client communication flow over the standardized REST API, and focuses on two core duties.

Coming to consensus on a candidate duty for all validators to sign;

Combining signatures from all validators into a distributed validator signature;

The only example of a distributed validator client built with a non-custodial middleware architecture to date is charon.

Distributed Validator Cluster

A distributed validator cluster is a collection of distributed validator nodes connected together to service a set of distributed validators generated during a DVK ceremony.

Distributed Validator Key Generation Ceremony

To achieve fault tolerance in a distributed validator, the individual private key shares need to be generated together. Rather than have a trusted dealer produce a private key, split it and distribute it, the preferred approach is to never construct the full private key at any point, by having each operator in the distributed validator cluster participate in what is known as a Distributed Key Generation ceremony. A distributed validator key generation ceremony is a type of DKG ceremony. A DVK ceremony produces signed validator deposit and exit data, along with all of the validator key shares and their associated metadata.

Set Up Docs

Run a cluster alone 丨Run a cluster with others


About BlockPower

Our Staking Services

👏Cosmos 👏Osmosis 👏Tezos 👏Ethereum 👏Juno 👏Celestia 👏Provenance 👏Aptos

Why Choose Us to Manage Your Assets

👏 Historical

BlockPower almost grew together with the establishment of the PoS consensus.

For instance, we have become Cosmos Genesis Validator since March 13, 2019.

👏 Experienced

BlockPower is one of the earliest participating service providers in Cosmos Network and Tezos Network. Furthermore, we have colorful experience in operating other networks like Juno, Osmosis, Aptos and so on (not only include Mainnet but also contain Devnets ). We have rich experience in emergency escalation, which reflects our instant crisis response capability.

👏 Communicated

BlockPower is actively participating in governance (like voting proposals and discussing in forums and discord channels), and what’s more, we have our own blog, disclosing information frequently.

WebsiteBlogMediumTwitterDiscord 丨Telegram

Leave a Reply

Your email address will not be published. Required fields are marked *