Unveiling Our Exciting Client Incentive Initiative!

Note: this article was revised on April 4, 2022, to incorporate a complete version of the Client Incentive Program specifics.

---

A varied assortment of clients is crucial for the Ethereum network’s vitality and decentralization. This variety guarantees that progress persists at the foundational layer of the protocol, that the network remains robust against possible assaults or flaws, and that a wide range of participants engage in discussions regarding potential modifications to the core protocol.

Although clients deliver a vital function to the network (without them, there is no network!), it has traditionally been challenging for them to reap benefits. Recently, new pathways have emerged for these groups to create sustainable enterprises, but most concentrate on mainnet-adjacent options rather than the primary Ethereum network. Furthermore, these prospects typically do not scale in direct proportion to the volume of value generated.

To guarantee that client teams possess a strong motivation to sustain the core Ethereum network in the long haul, the Ethereum Foundation has introduced a Client Incentive Program. This initiative provides client teams with ETH-based rewards which accumulate over time, provided they continue to develop software that satisfies the mainnet’s performance and security criteria.

Specifically, teams within the program will obtain a total of 144 validators (4608 ETH) each to operate on the mainnet. The scale of these grants acknowledges both the remarkable efforts accomplished over recent years and the numerous development hurdles projected well into the future. One team, whose client has become compatible with mainnet more recently than its counterparts, has been included in the initiative with a 50% share. The teams qualified for the program are, in alphabetical order:

• Erigon
• Go-ethereum (geth)
• Hyperledger Besu
• Lighthouse
• Lodestar (50% stake)
• Nethermind
• Nimbus
• Prysm
• Teku

The validator deposits are made in advance to be utilized by teams right away, while the withdrawal credentials (the ownership of the funds) will be vested over a period of years, with the first portion unlocked with the activation of Beacon Chain withdrawals. To receive this and future portions of validator withdrawal credentials, teams must persist in managing their clients, meeting performance targets on the mainnet, and generally contributing towards realizing the Ethereum community’s roadmap as it evolves over time. Following The Merge, client teams will also earn transaction fees collected by their validators. This, alongside staking rewards, will commence to furnish a consistent source of income for teams.

As the grants vest, teams are free to utilize the validators under their control as they see fit – for instance, continuing to stake and generate rewards, withdrawing and liquidating, or some combination thereof. It is also important to note that the Client Incentive Program is in addition to any grants that the EF allocates to these teams.

A comprehensive version of the program’s specifics has been provided as an appendix below.

Geth’s involvement in this initiative is distinctive, as they are a team integrated within the Ethereum Foundation. Nevertheless, the Geth crew – like the other clients mentioned earlier – will have complete authority over how to utilize these validators, earned fees, and their ETH deposits as the grants vest.

The framework of the program aligns teams with the network’s long-term wellness and guarantees they are motivated to develop secure and efficient software. It was conceived to reflect on previous accomplishments and reward teams that have already produced production-quality software. We aspire for it to establish a foundation for a robust incentivization of core contributors to Ethereum. As always, the Ecosystem Support Program is accessible, and ready, to fund initial innovative Ethereum implementation efforts, including new client teams.

We are thrilled to finally unveil this initiative publicly, and we anticipate discovering more opportunities for the community to unite and promote public goods!

---

Client Incentive Program Specifics

Considering the cumulative total of ETH intended to be allocated to client teams (approximately 42,000 ETH when factoring in validator rewards, or, as of April 4, 2022, over $145MM in value), we acknowledge the community’s desire to gain insight into how distributions will occur and how milestones will be achieved.

The comprehensive specifics of the incentive program, as communicated to client teams, are shared below.

Program Objectives & Eligibility

The program seeks to deliver long-term backing and incentives for teams to maintain dependable clients and a robust network overall.

For client teams to qualify, they should already be contributing to the overall development of Ethereum and plan to support the forthcoming shift to proof of stake. Throughout the program, teams will be required to uphold specific performance standards to remain eligible for the rewards. More on this below.

Configuration

Structure

Below are the primary steps taken by “EF” and the “Client” throughout the duration of this plan.

1. Execute deposits
2. Hand over control of existing signing keys
3. Client manages nodes/validators
4. Distribute withdrawal credentials in series

1. Execute deposits

Once a client consents to join the scheme, the EF generates NUM_VALIDATORS 32-ETH deposits.

The aggregate ETH at stake in the client incentivization initiative equals NUM_VALIDATORS * 32.

In coordination with client teams, an official commencement date for this program will be established, estimated between October 1, 2021, and the occurrence of The Merge.

2. Hand over control of existing signing keys

Following step 1, there will be NUM_VALIDATORS private keys corresponding to the public keys in the validator deposits governed by a single mnemonic. These keys need to be securely passed to the client team.

This mnemonic gets conveyed to the Client using one of the following methods:

1. Employing asymmetric encryption (e.g. PGP) through a recognized/validated public key of the recipient Client
2. Verbal communication of 25% at a time across 4 encrypted calls from various platforms
3. Via a mutually negotiated, secure method

The Client subsequently generates NUM_VALIDATORS keystores utilizing the mnemonic and confirms that each private key aligns sequentially to the batch of validator public key deposits made in their favor.

The EF will keep the mnemonic in cold storage in case active keys need to be utilized to withdraw validators from the program.

3. Client manages nodes/validators

Deposits are completed; keys are handed over. At this point, the Client governs the management of the related validators until withdrawal credential private keys are distributed. Specifically, the Client must utilize their own software as an execution engine or consensus layer and is accountable for selecting and maintaining support for a counterpart client throughout the incentivization timeline.

The performance of the Client’s validators can be analyzed simply by monitoring chain metrics, but further node performance metrics may be solicited.

4. Distribute sets of withdrawal credentials upon achieving milestones

Groups of validators will be distributed to the Client upon reaching pre-established milestones through the transfer of the underlying private keys for the validator withdrawal credentials.

Once a group of validators has been given, this signifies the conclusion of the Client’s obligation to the EF for those validators. The Client is free to decide whether to continue validating, withdraw, or exit, etc.

These keys will be PGP encrypted and transferred in batches.

Milestones

Considering the fluid nature of the continuously evolving Ethereum roadmap, simplicity is prioritized in selecting milestones.

A group of credentials gets released when withdrawals from the beacon chain become possible, with a minimum interval of one year separating the initiation of the Client Incentive Program (CIP) and the full release of the initial set of credentials.

If withdrawals from the beacon chain are enabled within or before the initial year of the CIP, the first tranche of credentials will be made available monthly, in equal portions, from the first month after withdrawals have been enabled, to the one-year anniversary of the program. For example, if withdrawals are allowed 6 months after the program begins, then 1/6th of the first tranche will be issued during months 6, 7, 8, 9, 10, 11, and 12. If not, the first wave of credentials will be released once withdrawals are activated. Subsequent waves will be released over time if the Client continues to meet performance expectations. Specifically, the milestones include:

1. Distribute INITIAL_RELEASE validators when withdrawals from the beacon chain are permitted (WITHDRAWALS_ENABLED_TIME).
2. for i, num_validators in enumerate(TIMED_RELEASES), distribute num_validators validators at the time WITHDRAWALS_ENABLED_TIME + (i + 1) * 6_months if client operation continues to showcase successful metrics.

Success metrics

Client/validator performance must continually
“`meet a series of achievement metrics to maintain involvement in this program.

The initial NUM_PERFORMANCE validators of the committed validators are monitored by the EF to evaluate metrics. The final NUM_CANARIES validators of the committed validators are available for the Client’s use for testing, experimental versions, etc. Canary validators are not anticipated to consistently fulfill the achievement metrics but remain subject to slashing regulations.

Metrics

The following are the achievement metrics that the Client must meet:

• Client validators on average do not drop below MIN_ACCEPTABLE_BALANCE balance
• Client validators have at least MIN_ATTESTATION_PERCENTAGE percentage of anticipated attestations included on-chain over any METRICS_WINDOW epoch duration
• Client validators have at least MIN_BLOCK_PERCENTAGE percentage of anticipated blocks included on-chain over any METRICS_WINDOW epoch duration

Additionally, client teams are expected to actively engage in research and development of essential network upgrades. The EF holds exclusive authority to determine if this metric has been achieved.

Above all, the EF anticipates client teams to actively strive towards ensuring a robust and healthy network. The EF acknowledges that in certain situations, these metrics may not be entirely under the Client’s control (e.g., a significant portion of the network offline for an extended duration due to problems with another client). In many such cases, the METRICS_WINDOW has been chosen to be sufficiently lengthy to accommodate problems and recovery; however, in such extraordinary cases, the EF will also consider external factors beyond the Client’s control.

Note: Within the context of this plan, validator top-ups are prohibited and should generally be avoided. Should a top-up benefit the health of the network in certain scenarios, the EF and client can discuss and adjust the metrics/milestones accordingly.

Probation

If the Client dips below the achievement metrics, the Client’s incentivization status enters probation. Throughout a probationary phase the Client has MAX_PROBATION_WINDOW epochs to restore metrics to successful standards, and during a probationary phase, the Client cannot have any validator credentials released. The duration spent in probation delays the release of any validator credentials by at least that amount of time.

If Client metrics remain in probationary status for over MAX_PROBATION_WINDOW epochs, the EF may, at their discretion, partially or wholly remove the Client from the incentivization program and partially or totally exit the Client’s validators.

Slashing

In the situation that one or more of a Client’s validators suffers slashing, such validators will be excluded from the incentive program.

If the incident is relatively isolated and swiftly resolved, the EF may, at its sole discretion, opt to reinstate a maximum of 16 of the slashed ETH per slashed validator back into the program for release at the final milestone.

If the slashing event is excessively large, negligent, or recurrent, the EF may, at their discretion, partially or fully remove the Client from the incentivization program and partially or totally exit the Client’s validators.

Note: Performance and canary validators are both subject to the slashing regulations.

Cross-Layer Dependencies

While the Client holds full responsibility for ensuring that their operations are conducted in a efficient and non-slashable manner, we acknowledge there are limits to what execution or consensus layer teams can do to address issues on the other layer. Specifically, this means we anticipate the Client to implement best practices regarding the operation of their nodes, but will not penalize them in the event of a widespread issue stemming from the other layer. Best practices for operating validators include:

• Ensuring that the Client is capable of interacting with most/all major clients, at least on canary validators;
• Ensuring that the Client’s failures are decorrelated from the remainder of the network, both by depending on diverse clients and hosting configurations;
• Ideally making sure that the Client’s counterpart nodes are distributed across >1 client to minimize client-specific issues;
• Ensuring that the Client can switch from one counterpart client to another in the event of a client-specific issue.

Terms

This plan is an optional supplementary incentivization scheme for clients. Involvement in this plan and the amount of locked funds accessible in the scheme will not influence future client grant determinations. Clients can include a minor stipend for node infrastructure in grant applications irrespective of participation.

Preconditions for participation in this plan are successful involvement in multi-client testnets and consistently demonstrating production readiness.

In general and particularly in the occurrence of exceptional and unforeseen situations concerning the client, the client team, the Ethereum roadmap, and/or the Ethereum mainnet, the EF has the exclusive authority to determine how to allocate withdrawal credentials and/or modify the stipulations of this incentive plan at any time.

Such extraordinary scenarios include, but are not limited to, the subsequent:

• Separate client teams merging into one
• Client team dividing into two
• Client team discontinuing the maintenance of a component (e.g., validator client) or the entirety of their software
• Ethereum roadmap drastically changing such that the milestones no longer represent attainable objectives
• Ethereum mainnet experiencing prolonged issues with stability, finality, or otherwise proper operation
• Ethereum mainnet undergoing a contentious hardfork